🚀 go-pugleaf

In article <6389@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>In article <6367@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>>>        NOT good.  Better to implement your own libraries (gets you tracking
>>>as well) that call the system libraries.  You don't want to break system
>>>stuff that calls the library entry points.
>>
>>Yeah, I was/am leary of the idea...  The only problem I see of using
>>my own libraries is you need to rely on the programmer to use them,
>>and the programmer has to be more careful, with #includes and order of
>>library linking.

>        No, the _only_ thing he has to do is open amiga.foo.library
>instead of foo.library.  Since all the offsets are the same, nothing
>else need be done, and amigix.foo.library will get all calls that
>would otherwise go to foo.library.

(The link stuff was more related to if the stub routines set errno.)

Sure, changing the library opened will work for all libraries, EXCEPT
for the exec.library...  Exec.library is accessed through ABSEXECBASE
at memory location 4, not from a return from the OpenLibrary call.  It
doesn't make sense to change that pointer (at ABSEXECBASE) as it would
likely cause big troubles, so I'm left with patching all the
exec.library functions, unless there's some other way I can have the
exception code figure out that it was called out of ROM code?  (Well,
that probably can't work; it still needs to handle the signals when
the call finishes...)

>>What system stuff would/could break by calling the library entry
>>points, and how exactly?  (WHY would they break?)

>        If make any changes to the semantics of regular system libraries, 
>other libraries that called them might well break (as well as a big
>performance drop).

I don't intend any semantic changes; merely to set a flag in a process
structure during the call.  Some performance drop (hopefully not TOO
bad) but shouldn't affect much else...  Oops, I guess I gotta make it
a counter so nested SysCalls will work correctly...

>>Also, is it legal to FreeMem a different sized block than you
>>AllocMem()'d?  If so, how can you keep it from depending on the
>>granularity of the memory allocators?

>        Check the exec memory chapter.

Didn't want to look it up yourself, huh?  :-)  Well, the Exec memory
chapter doesn't say anything clear about it, except that you can't
depend on the granularity being 8; only a multiple of 4.  Nowhere does
it say anything about whether or not you can legitimately free a
different sized memory block than you originally allocated.  So what
can I do?  I don't want to preallocate memory just so I can reallocate
it as I wish...  and I'm wary of trying to write a ReallocMem()
function, unless I could convince someone to include it in V1.4...

>>So Forbid/FreeMem/RemTask(0) would be the recommended way to do that
>>particular deallocation?

>        Sure, though you don't need to RemTask(), just return from your
>startup code, and you'll get removed by the system.

You still haven't told me much about this; I don't understand how it
works.  Sure, I get the general idea, but I need to know exactly how
it all works so I can implement it correctly.  I truly hate programs
that run fine but randomly crash the machine when they exit.  I want
everything to work smoothly, and for that, I need to know how the Exec
routines operate.  I'd prefer not to go digging around in the ROMs
with a disassembler if I can avoid it.

AddTask(task,initialPC,finalPC)...

Task I understand fine.  I take it that AddTask starts off the task by
pushing finalPC on the stack (as a return address for initialPC) along
with the initial registers (including initialPC) such that it is in
the state it would be as switched out, and so have everything
conveniently set up?  (This makes most sense to me, and the
documentation I've seen implied this is the case.)

Now, the big question is what happens with finalPC.

If you fall of the end of the world (RTS) from initialPC, you will
fall into finalPC.  Fine, no problem.  What happens if you also
perform an RTS from your finalPC routine?  Will you then fall into the
system default finalizer, where you would have ended up with had you
specified a finalPC of zero?

If so, (well, regardless) what exactly does this system default
finalizer do?  Does it ONLY do a RemTask(0) (and hence never continue
past it) or does it first attempt any sort of memory or resource
deallocation, such as freeing entries listed in tc_MemEntry?  Does it
do anything else/more?

More importantly, does RemTask() ever call the finalPC routine to
allow cleanup, or is it merely a convenience for the programmer to
specify the return address from the starting point, and as such,
affecting nothing but the initial stack frame of the task?

If RemTask DOES call finalPC, then what happens when finalPC calls
RemTask()?  Sounds like a loop, which it clearly can't be, implying
that RemTask actually does nothing with finalPC and that it only
affects the task's initial stack frame.

Does RemTask itself try to handle any sort of resource deallocation
itself, including the tc_MemEntry field, or does it call finalPC to
attempt cleanup, or does it ignore all cleanup and simply pull the
task from the system task queues?

Exactly what agency handles the deallocation of the Task structure
itself?  Is this something the system default finalizer does before
calling RemTask (and after calling Forbid, perhaps?) or does RemTask
itself, or is the program which did the original AddTask expected to
hang around to handle it?

If you supply a finalPC routine which does resource deallocation,
including that of the program code, the Task structure and the
tc_MemEntry field, (code and task structure memory freed last after a
Forbid) ending the finalPC routine with RemTask(0), does that mean
that the system default finalizer would NEVER run, the finalPC routine
will run exactly once, and nothing will be tried to be freed twice?

Basically, what it all boils down to is just what the hell is
happening when a task terminates?

>>One other thing...  will there ever be absolute references to the
>>stack segment (other than tc_SP*) or would it be legal (and safe) for
>>a program to extend its stack by reallocating it, copying it and
>>changing the few fixed pointers to it?

>        All automatic variables (including pointers to automatic variables)
>are on the stack.  You lose, sorry.

>        int Foo() { int x; scanf("%d",&x); return x; }

Yeah, I realized that it would never work real soon after I posted the
idea...  Automatic variables are often addressed stack-base-relative,
but not when their addresses are passed, etc...  Ah, well.  So much
for that idea.

About the autodocs...  Are they the "man" type pages in Appendix A of
the (1.1) RKM L&D manual?  Or am I missing it altogether?

One last thing, (for now...  :-) about Message Ports, I was scanning
that Amiga Programmer's Handbook, and it says something about every
task having a message port an associated but separate reply port.  I
don't understand.  I thought the same port was used to send AND
receive the replies to a message?  Also, why would all tasks have to
have message ports?  In short, is this true?

Deven
--
------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine ---------------------
Cogito  shadow@acm.rpi.edu          2346 15th Street            Pi-Rho America
ergo    userfxb6@rpitsmts.bitnet    Troy, NY 12180-2306         (518) 272-5847
sum...     In the immortal words of Socrates:  "I drank what?"     ...I think.