rrs@neabbs.UUCP (RONALD VAN EIJCK) (09/11/90)
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. ------------------------------------------------------------------------- | Ronald van Eijck R&R Software rrs@neabbs.uucp | | | | I want 32 bit chip ram | -------------------------------------------------------------------------
jesup@cbmvax.commodore.com (Randell Jesup) (09/28/90)
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. It already is in the A3000 (however, only the CPU sees it as 32 bits wide). There is a function call for allocating display ram for bitplanes: AllocRaster(). This should do "the right thing" in any hypothesized future chipset. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
jms@tardis.Tymnet.COM (Joe Smith) (10/02/90)
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. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."
griffith@eecs.cs.pdx.edu (Michael Griffith) (10/02/90)
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. |
valentin@cbmvax.commodore.com (Valentin Pepelea) (10/03/90)
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. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may destroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
griffith@eecs.cs.pdx.edu (Michael Griffith) (10/03/90)
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. |
deven@rpi.edu (Deven T. Corzine) (10/09/90)
On 3 Oct 90 07:07:00 GMT, griffith@eecs.cs.pdx.edu (Michael Griffith) said: Michael> Yes, but if you are not guaranteed a granularity of at least Michael> 2 bytes when you request memory from AllocMem() then many Michael> programs would break, because chip memory accessed by the Michael> custom chips must have their addresses be word orientated. Michael> Although the documentation "implies" that Allocate() and Michael> Deallocate() work on 8-bit boundaries, you are guaranteed at Michael> least longword alignment accord to the 1.2 Exec Manual (p. Michael> 66). And in fact, given the context, you can take this to Michael> apply to AllocMem() and FreeMem() as well, although I'm not Michael> sure if this is the case. AllocMem() *is* guaranteed to return longword-aligned memory. That is, you can absolutely depend on AllocMem() returning blocks which are multiples of 4 bytes, but you can't depend on the current granularity of 8 bytes, since it may change in the future. Michael> As for what is and isn't considered bad style, well, you do Michael> what you have to. If you can make it nice, good. If you Michael> can't, at least make it work. But make it work in the future too, if possible. (and it usually is.) Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th St. Apt. 2, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.