mcr@julie.UUCP (Michael Richardson) (11/02/89)
>QUESTION 2. >If you needed a chunk of memory and one of your constraints was >that it had to be completely within a 64K boundary; In other words >the upper 16 bits of the address of all of the memory in the block >must be constant, how would you go about doing it. The only >ways I can see are to either: > 1. Allocate more than you need, maybe 2X, and then figure out > whether to start at the beginning or start somewhere in the > middle. This is the best way. I asked this question last fall (although I only wanted 4k or 8k, and I wanted a lot of chunks of this size, properly aligned). You can give the two wrongly aligned chunks back to the OS by making the appropriate FreeMem() calls. This would have been essential for my application, (a Lisp interpreter --- it never got ported from the Sun it was developped on, and might not until 2630 && Mach) but I get the impression that you only need the one chunk. (Finding many 64k aligned chunks on a 1 meg machine that has run for awhile might be very difficult.) > 3. Look at and mess with the free memory list directly - Undoubtedly > a no-no. >None of these seem very good. #1 isn't so bad, since you can give memory back. I'd be curious to know if user level allocators could be defined --- either at the level of passing a pointer to a routine that accepts two arguments, (hunk and size) and returns either a reject or a base address && size, or even the ability to manage small sized blocks of memory separately from larger ones --- MEMF_ETERNAL might cause allocation from an area of memory less likely to be fragmented, while MEMF_EFEMERAL would pick the opposite end of the pool... On that subject of memory --- another type of MsgPort might be defined which would copy by value, rather than by reference. The Exec functions that deal with MsgPorts would have a switch on them. Anyone passing pointers in Messages would have to continue using the old ones. Passing MsgPorts (mn_ReplyPort) would have to be done using descriptors of some kind. -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ WORK: michael@fts1.UUCP