Path: utzoo!attcan!uunet!decwrl!ogicse!pdxgate!eecs!griffith
From: griffith@eecs.cs.pdx.edu (Michael Griffith)
Newsgroups: comp.sys.amiga.tech
Subject: Re: 32 bits CHIP ram
Keywords: Allocating memory on 4 or 8 byte boundaries
Message-ID: <203@pdxgate.UUCP>
Date: 2 Oct 90 15:22:19 GMT
References: <447392@neabbs.UUCP> <1264@tardis.Tymnet.COM>
Sender: news@pdxgate.UUCP
Lines: 26

jms@tardis.Tymnet.COM (Joe Smith) writes:

>In article <447392@neabbs.UUCP> rrs@neabbs.UUCP (RONALD VAN EIJCK) writes:
>>We all hope Chip ram will be 32 bits wide some day. So my suggestion is
>>that we all start to change the allignment of data in chip memory to 32 bits
>>so there will be no problems if commodore wants to change this.

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

In fact, Commodore has guaranteed that memory allocation alignment will be at
least long word (32-bit) in future revisions, thus making AllocMem a safe bet.
If for some strange reason you aren't using AllocMem ... ? Then you probably
don't have an OS and can do it yourself by adding 7 and masking off the last
3 bits. Your compiler should at least optionally provide for long word
alignment of data structures. Mostly this should be used for alignment of
sections that will have hunk information telling the OS to place them in Chip
RAM. Unless the OS can somehow do this automatically for Chip hunks, but I'm
guessing that isn't the case since that would probably cost a lot of overhead.


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