Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.lang.c
Subject: Re: Byte order (retitled)
Message-ID: <2470@brl-smoke.ARPA>
Date: Tue, 8-Apr-86 14:42:23 EST
Article-I.D.: brl-smok.2470
Posted: Tue Apr  8 14:42:23 1986
Date-Received: Thu, 10-Apr-86 08:26:57 EST
References: <7046@cca.UUCP>
Reply-To: gwyn@brl.ARPA
Organization: Ballistic Research Lab (BRL)
Lines: 41

In article <7046@cca.UUCP> g-rh@cca.UUCP (Richard Harter) writes:
>	Well, no, little-endian came about because the engineers at DEC
>who designed the PDP-11 made an arbitrary decision that was not well
>thought out.  I will not essay to defend the sanity of DEC engineers,
>and cannot recommend that any one else do so (:-)).  It was a bad
>decision.

One advantage of DEC's decision was that passing numeric quantities
by reference to procedures was simplified; the procedure could use
the lower bits of the parameter without worrying about the size of
the parameter.  This made code generation (e.g. Fortran) easier and
was a real programmer convenience (I certainly exploited it myself).

When the FP11 was designed, DEC screwed up and got the 4-byte (long)
integer format wrong (since fixed in the VAX-11, which was otherwise
most careful to use PDP-11 compatible data formats).  Some Fortrans
kept the bytes in little-endian order anyway, so as not to lose
the above-mentioned advantage, and reshuffled them during FP11
operations.

Many implementors of C on big-endian machines have had to cope with
the pointer conversion problem, which is simpler on little-endians.

>	Consider the following problem.  You have an array of 4 byte
>integers.  If you sort the array numerically you get one result.  If
>you regard the bytes as characters and sort them lexicographically on
>a little endian machine you get a different result.  The reason is that
>the most signifigant byte occupies the eight least signifigant bits.
>Consistency of signifigance requires that the direction of signifigance
>be the same for both bytes and bits.

This is not a practical example.  If it were, you would have to
make the same argument for floating-point numbers, records from
a file, and so on.

>In short, little-endian was a mistake, is a mistake, and will continue
>to be a mistake.

About the only thing that is clear, apart from the better fit of
big-endian to block-oriented operations and of little-endian to
stream-oriented ones, is that this is a "religious issue".