Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: Date: 25 Mar 89 07:33:42 GMT References: <6389@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven T. Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 154 In-reply-to: jesup@cbmvax.UUCP's message of 23 Mar 89 23:10:15 GMT 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.