🚀 go-pugleaf

In article <6406@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>In article <DEVEN.89Mar25023341@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes:
>>In article <6389@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>>>        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.

>>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,

>        Just write your stubs/pragmas to use something other than SysBase,
>then.  Note that most programs stash execbase in a variable SysBase.  This
>lessens reliance on accessing chip memory in a fast-mem system.  Look at the
>lattice startup code and pragmas.

That is another option.  Will #pragma's override older duplicate (but
different) declarations?  [also, is there any other valid type than
"libcall" and "syscall"?]

>>>>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.

>        Page 1-64, White 1.1 RKMs: Partial blocks may be deallocated,
>but note again that FreeMem() rounds your address down to the nearest
>even multiple of MEM_BLOCKSIZE and the size up to the nearest multiple
>before the FreeMem() request is performed.

Ah...  there's the discrepency.  You have a different manual than I.
Time to be specific [and verbose] I suppose:

Amiga ROM Kernal Reference Manual: Exec

Authors: Carl Sassenrath, Rob Peck, and Susan Deyl
Program examples by Carl Sassenrath

Published 1986, Addison-Wesley.
--------------------------------------------------------
Library of Congress Cataloging-in-Publication Data

Amiga ROM kernal reference manual.

    (Amiga technical reference series)
    Includes index.
    1. Amiga (Computer)-Programming.  2. Read-only
storage.  I..  Commodore Business Machines.
QA76.8.A177A655  1986       005.4'46          86-10887
ISBN 0-201-11099-7
--------------------------------------------------------

Now...  what is the most concise, yet unambiguous way to refer to this
version of the RKM: Exec Manual?

There is no page "1-64"...  and page "64" is the blank page between
Chapter 5, Interrupts, and Chapter 6, Memory Allocation.  Clearly it
is a different version.  I believe it is V1.1, but perhaps not.

Anyway, you can deallocate partial blocks...  fine.  Is there any
place you can look up the MEM_BLOCKSIZE at run-time, or must you
recompile when the granularity changes?  [recompiling would be a
nuisance.]

>        I said it was in the chapter....

In YOUR copy of the RKM's, perhaps...  :-)

>>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?

>        Yes, autodocs are equivalent to man pages.

Any place I can get the 1.3 Autodocs?  I don't have the money right
now to buy the developer's disk yet, or the 1.3 Includes & Autodocs
RKM...  [not that I've actually seen [or looked for] it, but...]  I
can handle making a printout of them myself, [;-)] and I prefer to
print them myself so I can have them loose-leaf, one-up.  [as I have
the Includes printed...]

I don't suppose it might be possible [or legal?] for you [or someone]
to email me [aCk] the V1.3 Autodocs, might it?  I would be most
appreciative...

>> 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?

>        A port is never "used" to send a message, only to recieve one (or
>recieve a reply).  All _Processes_ have a port (pr_MsgPort) for recieving
>(a) the inital WB startup message, and (b) replies to filesystem packets.
>_Tasks_ do not have associated ports unless the application creating it
>does so.

Presumably the question of message vs. reply port would be if you had
to use a different port to receive the reply to a message you sent to
some other port from a port you could receive (via PutMsg()) a message
on.  Hence, not the same message -- one with the port as destination,
another with it as reply port.  No need to separate them, is there?
[apart from logical design?]

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.