Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcnc!gatech!cuae2!ihnp4!chinet!steinmetz!jesup
From: jesup@steinmetz.steinmetz.UUCP (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: byte order: be reasonable - do it my way...
Message-ID: <1121@steinmetz.steinmetz.UUCP>
Date: Tue, 20-Jan-87 17:12:18 EST
Article-I.D.: steinmet.1121
Posted: Tue Jan 20 17:12:18 1987
Date-Received: Thu, 22-Jan-87 03:39:28 EST
References: <760@orcisi.UUCP> <112@lmi-angel.UUCP> <172@ames.UUCP> <1116@steinmetz.steinmetz.UUCP>
Reply-To: jesup@kbsvax.UUCP (Randell Jesup)
Organization: General Electric CRD, Schenectady, NY
Lines: 22
Keywords: byte order, big-endian, little-endian

In article <1116@steinmetz.steinmetz.UUCP> davidsen@kbsvax.UUCP (william E Davidsen) writes:
>That's one of the things I don't like about the 680?0 series, I would
>expect an integer with a value of 0x12345678 to be in memory as either
>12345678, or 87654321, or 78563412 even, but not 34127856. I consider
>that "middle-endian".

I'm not sure how you're dumping the memory, but I find it hard to
understand how you could get anything back but 12345678.  If a long-word
of 0x12345678 is stored at location 0, location 0 will contain 0x12,
location 1 will contain 0x34, location 2 will contain 0x56, and location
3 will contain 0x78.  The only way I can see for you to get anything but is
to dump it with a little-endian dump program.

The only cases where I can see little-endian having any advantage is machines
that have (or are descendants of machines that have) differing internal
and external word sizes.  Any machine that can read and write a register's
worth of data at a time gets no performance improvement from little-
endedness.

	Randell Jesup
	jesup@steinmetz.uucp (seismo!rochester!steinmetz!jesup)
	jesup@ge-crd.arpa