Todd Vierling <tv@pobox.com> writes:
> If this is possible, it should be turned on unconditionally.  SPARC has
> alignment faults, and if the "rolling" is how ARM actually does unaligned
> access, it should have alignment faults too.

Probably not desirable.

For instance, last i saw, in many cases, for C like:

	u_int16_t *wp = ...
	x = *wp;

the compiler will generate:

	load 32 bits into reg
	reg & 0xffff

rather than a half-word instruction.  (similar things for byte
instructions.)

May seem stupid, but not all ARM chips support half-word instructions,
and in that case, the 'roll' behaviour is a lot better than requiring
an extra shift...


Basically, it's a part of the architecture.  Code which does the wrong
thing is broken.  You shouldn't penalize code which does the right
thing (and, as noted above, there are simple ways in which this really
is the 'right thing; there are other more contrived ones, too, i'm
sure 8-) for code which is broken.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.