Index Home About Blog
From: (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: Big vs Little endian byte order.
Date: 7 Jun 1995 23:19:47 GMT

In article <>, (Craig Bergren) writes:

|>nullAmos Shapir (amos%) wrote:
|>> "Stefan Monnier" <> writes:
|>>>Hmmm I'm probably being dense, but I can pass pointers (regardless of
|>>>type of the object pointed to) on a big-endian machine just fine. And I
|>>>can just as well store a word and then read a byte out of the same
|>>>address. The only difference is that on a little endian, I'll get the
|>>>lowest 8bits whereas on a big-endian, I'll get the highest 8bits. I
|>>>fail to see the advantage of little-endian here:
|>>The difference is, if the _numeric value_ of the word is less than 128,
|>>it's contained in the least significant byte (same for short word and
|>>32768).  On big-endian machines, this byte has a different address than
|>>the full 4 (or 8) byte word.
|>So, what is your point?
|>Why is this attribute of little-endian an advantage?

Whether it is an advantage or not, there have existed real programs that
(accidentally, I think) took advantage of the difference, such that the
code worked on LE machines but not BE machines:

	int i1 = 1; short i2 = 2;
	func(&i1);  func(&i2);
	func(p) short *p; {...}

If the values in i1 are "small", this "works" on an LE machine.  It's been
a long time, but I've seen (more complex) code where this came up,
I think where there were arrays of integers, and the address of one wsa
being passed to a function that expected a pointer to a short ... and got away
with it.   This issue arose back in the {PDP-11,VAX} ==> {3B, MC68K} days,
where such code surprised people doing the ports to BE machines.

-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
DDD:    415-390-3090	FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

Index Home About Blog