Hi,

We're in an interesting situation where we need to support both ARM V4
and ARM V5 devices. We've encountered a bit of a toolchain issue we're
not sure how best to resolve.  Obviously, since ARM V5 is a superset
of ARM V4, the conservative thing to do is have the compiler generate
ARMV V4 instructions, since they will work on both kinds of systems.

Unfortunately, we've found a corner case where that doesn't quiet
work. Consider a device that is mmapped into user space, or a device
driver that has to access such a device.  Suppose the device has 16
bit wide registers.  The "obvious" way to access the device is by
using something like

volatile ushort ptr = /* WHATEVER THE DEVICE ADDRESS is MAPPED to */
ushort value;

*ptr = value; /* If you want to store to the device */
value = *ptr; /* If you want to read from it. */

The problem is that the compiler generates two byte operations for
such a reference, rather than one half word operation, for V4.

Existing ARM ports solve this in the kernel by using bus_space
accesses to reference the memory. This works because the bus_space
code is written in ARM assembler, and is specific to the processor, so
each port can do the right thing for its architecture.

In porting to our hardware, should that be a hard and fast rule in
device driver writing?  To allow the most general compiler options,
should we always access hardware addresses through the bus_space code?
This seems to be the path taken by all ARM ports to date.

On the other hand, ports on other architectures have overidden the
-Mcpu flag when building the kernel and so solved the problem by
generating kernel code that's specific for the processor.  That's more
or less what we've done in our first pass. This has the advantage of
making the board specific code for the kernel more efficient. Is this
an acceptable approach?

Meanwhile, how do ARM ports handle this with respect to mmapped access
to device registers?

Thanks, Bucky