Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!cca!g-rh
From: g-rh@cca.UUCP (Richard Harter)
Newsgroups: net.lang.c
Subject: Re: Byte order (retitled)
Message-ID: <7158@cca.UUCP>
Date: Thu, 10-Apr-86 23:32:05 EST
Article-I.D.: cca.7158
Posted: Thu Apr 10 23:32:05 1986
Date-Received: Sat, 12-Apr-86 22:45:07 EST
References: <7046@cca.UUCP> <>
Reply-To: g-rh@cca.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge
Lines: 64
Summary: Some merit in little-endian

In article <> gwyn@brl.ARPA writes:
>
>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).
>
	Point well taken.  I think that most of us will agree that
	it is usually bad practice on the part of the programmers
	to have mismatched types across procedure invocations.
	However code generating programs should exploit all of the
	tricks of the trade.
>
>Many implementors of C on big-endian machines have had to cope with
>the pointer conversion problem, which is simpler on little-endians.
>
	Color me skeptical.  You may be right, but I would like to
	see more details.  In the model of pointers that it occurs
	to me to implement, big-Endian and little-endian come out
	the same.
>
>>	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.
>
	Grumble, grumble.  Sorry, this is a real practical problem.
	Let me give some context.  Suppose you are doing a high speed
	sort of character strings.  Being a clever fellow you have
	read the glossed over parts of the literature and have seen
	that a math sort is O(n) rather than O(n log n).  You also
	notice that it is cheaper to compare 4 bytes at once with
	an 32-bit integer compare than to make 4 byte compares.
	On a BE machine you make the calculations directly; on a
	LE machine you move the bytes into BE order and then do
	the compare.  Yes, Virginia, this is type punning, and all
	those other bad things your CS professor told you were
	no-no's.  But it pays off because you are exploiting the
	effective parallelism of integer address calculation.

>>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".

	Well, I won't exactly retract my words, but there is much
	to what you say.  I will contend that it was a mistake to
	introduce a second standard architecture where only one
	existed before unless the advantages of the second standard
	are clear-cut.  And this is not the case.  LE wins in some
	situations, BE wins in others.  But the disadvantages of
	two standards to deal with outweigh the advantages of either.

			Richard Harter, SMDS Inc.