Re: Big/Little Endian issues

["David B. Gustavson" <dbg@SCIzzL.com>]

At 8:48 AM -0800 4/29/98, Ashwath Nagaraj wrote:
>In a 32-bit system. if the communication between a little-endian host CPU
>and a big-endian controller CPU (i.e. memory to memory transfer) is such
>that :
>
>1. -- 5.
...
>
>then the requirement of software swapping for this data-structure is
>eliminated.
>
>In the perspective of a company where code for both the driver (running on
>the host-CPU) and an intelligent-controller are written, it would be great
>to have the hardware do the swap.
>
>Been there and done that too.. however, the only way we could figure out
>the actual data path was to transfer a known pattern, and see what arrived
>!! (Various combinations of swaps for a misaligned transfer result in the
>head or tail  being missing.)
>
>Wearing a hardware designer hat - the hardware can only "know" the
>alignment of bytes, so I would provide a mechanism to transfer byte string
>from a source memory to a destination memory. This may involve byte-lane
>swaps.
>
Exactly right!
The swaps you described are fixed path swaps of byte lanes, just a wiring
pattern on the PC board, in order to preserve the relative byte addresses
within multi-byte items.

That implements "address invariance", the simplifying organizational
principle I espouse (and which is used by IEEE Std 1596.5, sharable data
formats for use in heterogeneous multi-processor environments). That does
have the effect of making character strings transport correctly.

The swaps that cause big trouble are the ones controlled by byte swappers
that are controlled by mode bits in some control register or that
dynamically try to figure out whether to swap or not depending on some
hardware-visible criterion.
(One exception--it's OK to systematically change the swapping for address
cycles versus data cycles on multiplexed-bus interfaces. Addresses are
interpreted by hardware, so must match the hardware's expectations
everywhere. But the context for recognizing addresses is always available
to the hardware, so this works transparently with no proliferating
complications.

Dave