Curt Sampson <cjs@portal.ca> writes:


 >On Mon, 18 Aug 1997, Jonathan Stone wrote:
 >
 >> The bus_space interface should provide methods for accessing such
 >> streams efficiently, without requiring any explicit driver
 >> byteswapping of `bytestream' data like disk blocks or Ethernet
 >> packets.  I think the reasons for that are obvious.
 >
 >The reasons for this are not obvious to me. Given the number of
 >different situations that can occur, the driver is still going to
 >have to make its own decisions about whether it should swap any
 >particular set of bytes or not, since only the driver will know a)
 >whether the data is stream data or not, and b) the endianness and
 >swapping-capability of the bridges between the device and the CPU,
 >and the device itself.


My (overly loud) objection was primarily about being told to use
bus_space_{read,write}_multi_1.  I do think the performance
implications of that are obvious, and technically not supportable.

Let's assume there wil be cases where PIO drivers accessing
bytestreams via multibyte methods, and the bus/chipset/CPU combination
does requires that software bytewapping be done.

I'm claiming that drivers will be better off if the bus-space methods
can do the bytewapping internally, (e.g,. while the 2 or 4 byte
quantities are in a register) rather than having to make another pass
through a memory buffer swapping the bytes.  Doing the byteswap
outside the bus_space method means an extra pass through the I/O
buffer, and avoiding extra passes through memory a Good Thing, and
increasingly so as CPUs get further away from memory.


This is probably more true on little-endian machines than big-endian.
Little-endian CPUs have to do bytewapping for the IP suite, so they
often have insns to do it; big-endian machines often don't.  see Joe
Touch's MD5(?), uh, rant.

I'm sure we could make drivers work without a byteswapping version of
bus_space_{read,write}_multi_N, (n > 1) but we'd get better drivers
for PIO devices if we did have them.