Path: utzoo!attcan!uunet!tektronix!tekcrl!tekchips!stevev
From: stevev@tekchips.CRL.TEK.COM (Steve Vegdahl)
Newsgroups: comp.arch
Subject: Re: Endian wars
Summary: ... depends on your string representation
Message-ID: <3505@tekcrl.CRL.TEK.COM>
Date: 23 Jan 89 20:11:20 GMT
References: <6133@columbia.edu>
Sender: ftp@tekcrl.CRL.TEK.COM
Lines: 30

In article <6133@columbia.edu>, eppstein@garfield (David Eppstein) writes:
> Big endian lets you use integer comparison instructions to do string
> compares a word at a time.  Little endian means you are stuck with a
> byte at a time.

This depends on how strings are represented.  If you take the view that
"C does things the right way, the only way", then I would be inclined
to agree that making the "wrong" endian choice would slow down string
comparison *if* your compiler is smart enough to figure out the optimization,
*or* if the string-comparison algorithm is coded in a non-portable way
(namely, an endian-ness assumption).

But consider a representation of strings where the characters are laid out
"backwards" in memory; a pointer to a string would contain the address of
the strings highest-addressed byte, which is the first character of the
string.  Now, big endian and little endian find their roles reversed WRT the
above optimization.

> The arguments about how people expect to read things seem pretty bogus
> to me.  One of the things computers are very good at doing is format
> conversion.

I agree.  I also believe that people (other than language implementors)
should not be concerned with the details of how a string is represented
in memory.  He should only be reading high-level-language code.

		Steve Vegdahl
		Computer Research Lab
		Tektronix Labs
		Beaverton, Oregon