🚀 go-pugleaf

valentin@cbmvax.commodore.com (Valentin Pepelea) writes:

>In article <1264@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes:
>>
>>For dynamically allocated memory objects, there is no need to change anything.
>>The AllocMem() function is documented as returning a pointer to memory that
>>is allocated on an 8-byte boundary.  So, we have better than 32-bit alignment
>>already; we have 64-bit alignment.

>Correction, the AllocMem() function is not documented to allocate memory on an
>8-byte boundary, although it does happen to do just that. The documentation
>that implies that memory is allocated on 8-byte boundaries is the one
>explaining how Allocate() and Deallocate() work, along with the MemHeader and
>MemChunk structures.

>Writing code that is dependent on an allocation granularity of 8 bytes, rather
>than something larger like 256 bytes, is considered bad style.

Yes, but if you are not guaranteed a granularity of at least 2 bytes when you
request memory from AllocMem() then many programs would break, because chip
memory accessed by the custom chips must have their addresses be word
orientated. Although the documentation "implies" that Allocate() and
Deallocate() work on 8-bit boundaries, you are guaranteed at least longword
alignment accord to the 1.2 Exec Manual (p. 66). And in fact, given the
context, you can take this to apply to AllocMem() and FreeMem() as well,
although I'm not sure if this is the case.

As for what is and isn't considered bad style, well, you do what you have
to. If you can make it nice, good. If you can't, at least make it work.


| Michael Griffith                     | If I had an opinion it certainly   |
| griffith@eecs.ee.pdx.edu             | wouldn't be the same one as        |
| ...!tektronix!psueea!eecs!griffith   | Portland State University anyways. |