Subject: Re: ncr.4 & byte ordering
To: Jason Thorpe <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 01/16/1997 15:36:18
On Thu, 16 Jan 1997, Jason Thorpe wrote:
> On Thu, 16 Jan 97 15:18:12 EST
> Mike Long <email@example.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? :-)