🚀 go-pugleaf

In article <6464@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>In article <DEVEN.89Mar30052014@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes:
>>That is another option.  Will #pragma's override older duplicate (but
>>different) declarations?  [also, is there any other valid type than
>>"libcall" and "syscall"?]

>        I think not.  Doesn't matter, since they all use SysBase,
>which is set up in the c.a startup code.  All you need to do is put
>your exec.amigix.library pointer in SysBase instead of the contents
>of AbsExecBase.

Oh...  if that is the case, then that would be an acceptable option,
methinks...  I already have to replace the startup code...

Of course, the other option is not to allow Amigix processes to
*directly* call Amiga libraries, only indirectly through
Amiga-specific amigix.library function calls...

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

>        The comments should still be there.

They're not.  I checked quite carefully.  It notes that the current
granularity is 8, but you can not depend on that size in future
revisions of the operating system.  And it noted that you CAN count on
longword alignment.

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

>        Recompile.  Better yet, don't _depend_ on a given granularity.

But, you see, the dependency would be in writing a ReallocMem
function...  I do NOT want to force enough memory for the old AND new
memory blocks, so I must depend on the internal memory structure and
the granularity that Exec uses, as Exec does not provide a ReallocMem
function, and it is a pretty basic function...  Now, if C-A will add a
ReallocMem to Exec V1.4+, it won't be a problem, for nowhere else do I
expect to have any dependency on the granularity.  (Things WILL depend
on a ReallocMem, however.)

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

>        They cost $20 from CATS.

Well, I just started working again, so maybe I'll be able to spare the
money...  [little free time, now.  :-(]

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

>        Not legal (they're copyrighted).  Sorry.

I expected as much.  Worth a try.  :-)

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

>        Mind restating that in english?

I'll give it a try.

Say you've got 2 processes, each sending messages to the other.  Is
there or is there not a need to separate reply ports from message
ports [as receiving points, not reply-receiving points] or can you
have a single message port for each process, using it as the
destination port for the messages the other process sends, and as the
reply port for any messages the process spends.  That book implied
you'd need one port for the other process to send messages to, and
another to receive the reply messages for messages you send to the
other process...   What's the actuality?

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.