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