🚀 go-pugleaf

In article <0164.AA0164@julie> mcr@julie.UUCP (Michael Richardson) writes:
>  I currently get (4K) blocks aligned on 4K boundaries from SunOS using
>memalign (a variation on malloc). The SUN malloc likes to store the size
>of the block in the word preceeding the block, and I would waste
>4094 bytes of space every time I allocated a block. Until I write/find
>a better malloc, I kludge things and allocate 4094 bytes instead.
>(I used to just advance brk() by about 500K to make my arena, but
>realising I was going to port it, I changed that recently.)
>I use the middle 8 bits
> uuuu uuuu uuuu tttt tttt oooo oooo oooo
>   u - upper bits
>   t - page number (used to index into a table to determine object type)
>   o - page offsets
>
>  to determine the type of the page, so I need to allocate the pages
>on 2^12=4K boundaries.
>
>  I have discovered that the Manx malloc is a fake - is uses a 40K
>arena which is allocated at run time regardless of how much malloc'ing
>you intend to do. (Do any of the library functions call malloc? I'd like
>to stay away from them if possible)

	ICK!  I'd advise considering Lattice 5.0: optimizer, source debugger,
REAL malloc, etc.

>  The normal AllocMem is fine, I DO know the block size, but it wont
>guarantee a 4K boundary. I have thought about AllocMem'ing 8K, taking the
>middle 4K chunk and returning the rest, but I am not sure if this will
>work. Does AllocMem keep any information of blocks that are in use? If
>so, can I do things in a revision-independant way? Or do I have to
>walk to memory lists myself? (Worse solution.)

	You could try this:  AllocMem 8K, get a pointer to your 4K block,
then FreeMem the part before it and after it.  This is legal, though not
usually encouraged (see the memory section of the EXEC RKM, it's discussed
there).  You could also grab several at once, minimising fragmentation.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup