Re: Linux/IA-64 byte order

Arvind Sankar (arvinds@mit.edu)
Tue, 9 Mar 1999 11:47:31 -0500


On Mon, Mar 08, 1999 at 09:46:27PM -0600, Taral wrote:
> On Mon, 08 Mar 1999, Richard Gooch wrote:
> >I'd like to start a discussion and see if we can reach some reasonable
> >consensus on whether big-endian is acceptable to the community. I
> >think this is an important issue, as a little-endian Linux/IA-64 is
> >going to make it a second choice for a significant number of
> >people. This reason for this follows (from my orginal message to
> >David):
>
> To tell you the truth, big-endian is generally preferred in many systems, due
> to the fact that groupings don't change the ordering of bytes. In other words:
>
> 12 34 56 78 9A BC DE F0
> 1234 5678 9ABC DEF0
> 12345678 9ABCDEF0
>
> Are all the same data, just shown as bytes/shorts/longs, respectively. This
> makes viewing data *much* easier, since you're not constantly byte-swapping.
>

duh? You're saying that big-endian is preferable because it is easier for
humans to read?

But consider what the poor machine does, and I can show that little-endian
is preferable.

Consider a struct in some server type thing that used to have two fields
u32 foo;
u32 reserved;

say foo is some ID number or something.

if i later decide i need more space for foo, I can just change that to
u64 foo;

Now on LE, a binary program linked against the new server will work with the
old one as well, if the old one was intelligent enough to set the reserved
field to 0. It will puke on BE.

Even an old program can work with the new server, if the server makes sure not
to use big ID numbers for old programs. It could just reserve the small ID
numbers and not return them to the new guys to have enough space. For the same
thing to work with BE, it has to use ID numbers shifted left by 32 bits for old
guys, and reserve those which are multiples of 2^32, which is ugly and not at
all natural to program.

-- arvind

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/