On Mon, 07 Aug 2006 10:00:34 +0900, "Toru Nishimura" wrote:
> > But, IIRC, that range of offsets is less for the half-word operations,
> > and gcc is likely to use 32bit operations to read 16bit values (masking
> > the high bits).  
> 
> Making 32bit access for 16bit quantity is as equally bad as having two
> consecutive 8bit access for memory mapped I/O since it'd confuse byte
> lane selector and device latch.  ARM tends to be a replacement of 8/16bit
> MCU and HW designers may not well understand about endian-ness and
> 32bit nature of RISC discipline.  It reminds Alpha processor instruction
> set has to be extended to cope with field demands for "legacy devices".

ARM has had 16-bit memory access instructions since v4 of the architecture 
was introduced, circa 1994.  There's a vanishingly small number of 
machines out there now that don't have such instructions (and a small 
number of machines out there where, although fitted with a v4 CPU, only 
have a v3 capable memory system attached).  Unfortunately, some of those 
machines were quite popular with the early developers of the NetBSD port 
(I have a couple lying around here, for example); persuading these 
developers to throw those machines away, so that we can make the base 
architecture v4 (or even higher) is quite hard.  But the problem has been 
substantially finessed by building individual kernels with the correct CPU 
flags.

R.