Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · Mon, 06 Sep 2004 11:12:19 -0700

Kay-Uwe Kasemir wrote:

Hi:
I'm surprised Jeff Hill hasn't jumped onto this thread.
He and I had talked about similar issues before.
Maybe he's getting some work done and ignoring tech-talk.
Anyway, the thing about using packed structures
in order to access memory mapped I/O or

IMHO it is always a very bad idea to do memory mapped I/O
by treating I/O registers as they were ordinary variables because
it is nonportable (see below) and to the reader it is not obvious
what statements actually perform I/O operations.
On some modern CPUs, doing (memory mapped) I/O still requires
special instructions to be used and therefore, a person porting
a driver needs to identify I/O operations and port them.
If you code e.g.,
regs.csr     = ENABLE_XMIT
regs.xt_data = data
this will only work on a machine with the correct endianness and
with no requirements on instruction execution ordering.
Contrast this with:
out_32be(&regs.csr, ENABLE_XMIT);
out_32be(&regs.xt_data, data);
Here it is obvious what you are doing and all I have to do
when porting to e.g., a little endian machine is providing the correct
macro / inline implementation.
If we had a generic API for I/O operations, porting drivers would
obviously be a lot easier...
-- Till
BTW: I have a header for helping with I/O and endianness issues
     I could contribute...

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System