Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: 32 bits CHIP ram Message-ID: Date: 9 Oct 90 03:27:50 GMT References: <447392@neabbs.UUCP> <1264@tardis.Tymnet.COM> <14818@cbmvax.commodore.com> <222@pdxgate.UUCP> Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 31 In-Reply-To: griffith@eecs.cs.pdx.edu's message of 3 Oct 90 07:07:00 GMT 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.