Subject: Re: ncr.4 & byte ordering
To: None <skippy@macro.stanford.edu>
From: Mike Long <mike.long@analog.com>
List: current-users
Date: 01/16/1997 15:18:12
>Date: Thu, 16 Jan 1997 12:01:47 -0800 (PST)
>From: Bill Studenmund <skippy@macro.stanford.edu>

>Would it make sense to define byte-swapping routines that define
>conditional byteswapping routines for little-endian words, similar to
>"network" byte order stuff. Maybe "dos" byte order, though there might be
>a better name. Maybe "isa" byte order?

We don't want a name that's x86- or PC-centric.  It would probably be
best just to use big- and little-endian, since those are the two
alternatives underlying all else.

>Such things would be useful in the above PCI drivers, msdosfs stuff, and
>isa drivers in general. By standardizing the names, each code segment
>wouldn't have to define its own names & routines. I'd hope all the *BSD's
>(and Linux?) could agree on the names?

I'd like that, but I have to say "dream on."  We haven't even cleared
up which byte order IP_HDRINCL should use yet.

>So we'd have something like htois(), htoil(), itohs(), itohl(), or
>htods(), htodl(), dtohs(), and dtohl(). Or some other letter, depending on
>the name chosen. Oh, "litle-endian" order would probably be bad as then
>we'd have names like htoll() which look like someone want's money before
>continuing. :-)

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.
-- 
Mike Long <mike.long@analog.com>     <URL:http://www.shore.net/~mikel>
VLSI Design Engineer         finger mikel@shore.net for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA       (eq (opinion 'ADI) (opinion 'mike)) -> nil