On Thu, 16 Jan 1997, Jason Thorpe wrote:

> On Thu, 16 Jan 97 15:18:12 EST 
>  Mike Long <mike.long@analog.com> wrote:
> 
>  > I like htole16(), htole32(), letoh16(), and letoh32() for the
>  > little-endian vs. host routines.  Likewise, htobe16(), htobe32(),
>  > betoh16(), and betoh32() for a corresponding set of big-endian
>  > vs. host routines.  Such a naming scheme would leave room for 64-bit
>  > versions, if required.  ntohl() et. al. can be aliases for the latter
>  > set, so we can restrict their use to the network code where they
>  > belong.
> 
> Say, I like this idea.  A bus's natural order is known by drivers
> on that bus... and bus-indepependent driver cores could simply
> use a "sc_busorder" member in their softc, set to BIG_ENDIAN or
> LITTLE_ENDIAN (used to select, e.g. letoh16() or betoh16()).

I like the idea of the drivers knowing best, rather than the bus knowing.
Partly because I'm confused about wheter or not a bus really has an
endianism in the same way a CPU does.

In a CPU, you can take a 4-byte integer stored in memory and cast it to a
4-byte int. That's what ntoh & friends are for.

But when you talk about a multi-byte bus, don't you also have the ordering
question of address ordering bytes in a transfer? Say on a 16-bit bus, are
all CPU's consitant about whether d15-d8 is the "even" byte (assuming that
d15 is the MSbit)?

Also, does PCI have an enforced endianism? I'm looking at getting a PCI
PowerMac, and part of the hardware will be the MacOS hardware, which was
built for use by PPC's which Apple typically runs big-endian. Now say I
buy a PCI card originally for a PC, for which NetBSD has a driver. If
there's not a forced endianism, then don't we run the risk of having both
big- and little-endian hardware on the same bus at the same time? 

Or is my ignorance of PCI specs glaring? :-)

Thanks!
Take care,

Bill