> > > == Jason's words,
> >   == mine
>     == Chris's words
> > > For some busses, the only sane way to treat them is their "native" byte
> > > order.  I.e. ISA, EISA, and PCI should all be considered "little endian".
> > > It's my opinion that the bus_space_* functions _should_ perform the
> > > necessary byte swapping, and the components on boards should always
> > > be configured for the byte order they'd be configured if the processor
> > > were little-endian.
> > 
> > What about the case (which I think exists for the Atari's) where
> > interveening hardware does the byte swapping? Also, what about PCI
> > Powermacs? I'm not sure if the hardware there does swapping, but all of
> > the docs I've seen for the MacIO stuff (Mac IO ports off the PCI bus)
> > haven't spoken about enianisms, and Apple runs the CPU as big-endian.
> 
> Jason said "necessary" byte swapping.  In the case where a bus
> interface does byte swapping, the code doesn't need to do the byte
> swapping itself.
> 
> I seem to recall that there are multiple ISA bridges for the Amiga,
> some of which do byte swapping and some of which do not.
> 
> 
> > > Of course, this makes using the 16-bit or 32-bit methods for octet streams
> > > a bit difficult...
> > 
> > Since having the swapping DOES make sense for a lot (most maybe?) of cases,
> > maybe it should be some sort of option? Maybe set when the space is
> > mapped?
> 
> Thereby adding complexity to ... lots of things, most importantly the
> code which implements the basic read-write path.

But wouldn't we need that complexity to be able to support choosing,
at run time, between a byte-swaping and a non-byte-swapping bridge
chip?

> The 16-bit and 32-bit methods _should not_ be used for streams of
> bytes.  They are meant to access multi-byte data items, and accessing
> groups of single byte data items with them is _incorrect_.
> 
> If you want to access multiple data items "efficiently" (regardless of
> their size) {read,write}_multi_* are the interfaces to use, and should
> be used with the correct data item size.

Here's the example I have in mind. I'll admit that, since I don't own
a PowerMac yet, I haven't tested it out. I do NOT know if Apple's
PCI interface does byte swapping.

On the serial support in the MacIO chip (funny that Bill would look at
that first :-) , there is a fifo. Apple's docs claim it's an 8-byte
fifo. But if you just write characters to its address, you only have
a 2-byte fifo (I worked w/ someone who did).

The Apple docs also seem to indicate the address's a 32-bit register.
So my bet is that it is a two-word register, where each word can be up
to 4 characters. Since the thing can run off DMA, I assume everything's
set up so that a u_int32 read from RAM & written to the register just
does the right thing.

My concern is that if Apple's PCI chip doesn't byte swap, the above
described interface would want to add byte swapping. In my little
example above, byte swapping would be wrong (since we'd be adding
something MacOS & the other OS's don't).

I guess my real concern is that if we have an interface which insists
that we treat a peripheral as LE when it really was designed to be
BE, and we're on a BE system, then we are adding two byte-swaps for
nothing. That just seems gross.

If we have to be able to deal with pridges which do and which don't
byte swap (i.e. we have to make run-time choices anyway), can't
we make such decisions a bit more fine-graned?

Thoughts? Even ones like, "Bill needs to read this reference manual
I'm mailing him?" :-)

Take care,

Bill