Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!gem.mps.ohio-state.edu!apple!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: integer alignment problems on RT Keywords: RT 6150 032 ROMP alignment Message-ID: <28697@winchester.mips.COM> Date: 3 Oct 89 19:57:19 GMT References: <162@eliza.edvvie.at> <754@crdos1.crd.ge.COM> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 34 In article <754@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <162@eliza.edvvie.at>, johnny@edvvie.at (Johann Schweigl) writes: > >| This leads me to the final questions: >| - is it acceptable that the CPU changes the adress you delivered without any >| warning and does something you wouldn't expect > That's up to you to decide. If I were writing portable code to do this >(and I have) I would use a simple output routine for machines which >force allignment. > >| - how do other CPU's behave (eg. 88000, 68000, SPARC, MIPS) Those RISCs all trap on unaligned accesses, as does HP PA. MIPS has 4 instructions for doing unaligned 32-bit load/stores; HP PA has an unaligned store bytes operation. With relatively few exceptions, CPUs either: a) Trap on unaligned (most RISCs; S/360) OR b) Complete the access, crossing boundaries as needed. Many CISCs; S/370 & later. Some combinations exist. For example, 68000s would trap a 16-bit (word) reference on an odd boundary, but not trap a 32-bit (longword) reference on a (word, but not longword) boundary, which occasionally caused performance pain for 68020s, which would allow accesses to longwords on any boundary, but were of course slower when accessing them unaligned. Some 68K C compilers packed structures so that longs often showed up on non-long boundaries. -- -john mashey DISCLAIMER:UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086