Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: net.lang.c
Subject: Re: Byte order
Message-ID: <2522@utcsri.UUCP>
Date: Thu, 10-Apr-86 02:50:55 EST
Article-I.D.: utcsri.2522
Posted: Thu Apr 10 02:50:55 1986
Date-Received: Thu, 10-Apr-86 04:24:15 EST
References: <> <7046@cca.UUCP> <1223@ulysses.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 102
Keywords: byte ordering
Summary: please don't

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

>In summary, big-endian was a mistake, but there is no use fighting it.

bleah... bleah... bleah...

I have only been reading this net.group since Jan86, but I can't
believe this issue hasn't been discussed. My opinion: There ain't
no bad one and good one, just different ones...

Adding/subtracting multi-precision integers:
	Little-end is better because you start at the little end.

Comparing multi-prec. numbers:
	Big-end is better because you start at the big end.

Working with different-sized multi-prec numbers.
	Little-end is better because both numbers start at "1's".
	In Big-End, the first bytes have different weights, so you can't
	even compare them directly.
	LittleEnd also allows, say, an int to be copied to a char by reading
	the byte at the *same* address as the int.

Testing multi-prec ints for >=0/<0
	Big-end wins. just test the first byte.

Testing mult-prec ints for odd/even.
	Little-end wins. just test the first byte. :-)

Working with character strings:
	Big-end is better because lexical comparison ( first char most
	significant ) is equivalent to numerical comparison of mult-prec ints.

Transmitting serial async data:
	Little-end (bitwise) is essential if 7-bit/8-bit formats are
	to be used, ( and abused :-)), since that way the
	LSB location is independent of the # of bits. Only the
	8th bit is in doubt. This also affects CRC calculation:
	if you write software to find a CRC for data
	which is to be serially transmitted,( async or otherwise )
	you should know whether it is to be sent little-end or big-end,
	or burst error detection will suffer. I don't know which is
	easier or if there is a difference.

Human readability:
	Big-end is supposedly better 'cause that's how we write'. I feel
	that this is completely irrelavent and is rather like saying that all
	floating-point calculations should be done in ASCII. Software
	to convert back and forth from ascii to binary is not affected much
	by the order. And if God had wanted humans to spend a lot of time
	reading hex dumps, he would have given us 16 fingers :-). So saying
	'Well little-endian looks funny on a dump' makes no sense.

Bit numbering within bytes:
	Little-end wins, LSB = bit 0 means that bit n = 2^n regardless of
	word width. This argument ( like the parallel one at the byte & word
	level) doesn't carry much weight by itself - practical situations
	like I have given re adding and comparing are more significant.
	However, numbering the LSB 0 is ( almost) universal.
	Ahhh... say the big-endians, look at two consecutive bytes:

	bit #'s:	7 6 5 4 3 2 1 0    7 6 5 4 3 2 1 0
			MSB	    LSB    MSB         LSB
	seen as an int:	............LSB	   MSB............ (little-end int)
	bit #'s:	7 6 5 4 3 2 1 0    151413121110 9 8

	The int bit #'s are out of sequence, says the bigendian. That's
	because the big-endian ( like the little-endian) has written
	the bytes down with the MSB on the left. Just like a human. If you
	write them down the other way, the LSB of the int is on the left,
	and the bottom line reads 0,1,2...14,15. How nice. Remember, in
	many computers, there is nothing joining the msb of one byte to
	the lsb of the next, or vice-versa, except the byte order of ints
	and longer types.
	Some machines ( e.g. some of the 680XX? ) can 'peel' arbitrary
	string of bits from memory. This should be consistent - i.e.
	peeling off 16 bits that happen to align with two bytes should
	give the same result as just reading those two bytes as an int.

I could come up with more, but it's late, and you don't want to read
them.  In fact, I'm a little-end fan, but only just - it doesn't bother
me a bit programming 6809 or 68K in assembler. The point is, whatever
is done, it must be CONSISTENT. Thus I don't like the 1,0,2,3 'hybrid'
byte ordering of longs on a PDP11*. And ( getting obsure ) the BDS-C
(CP/M 80 ) compiler implements longs in a big-end fashion while ints are
little-end - also nasty.

*not in the least bit [no pun] a result of the architecture of the PDP11, BTW.

So please no more postings saying "X is completely stupid and I wouldn't
even be seen in the same building with a machine that orders its bytes
that way". Considered arguments are, as always, welcome.

P.S. Someone said that 'Little-end is a result of the PDP-11'. I don't know,
but I find that hard to believe... except of course in the case of the VAX.
Maybe that's all that was meant. Anybody know? I do know that the following
micros are little-end: 8080,Z80,6502. E-mail please.

-- 
"If you aren't making any mistakes, you aren't doing anything".
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg