Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site tty3b.UUCP
Path: utzoo!linus!decvax!tektronix!uw-beaver!cornell!vax135!houxm!ihnp4!mgnetp!ltuxa!tty3b!jhl
From: jhl@tty3b.UUCP ("Jonathon Luers" 97320)
Newsgroups: net.micro.68k,net.arch,net.lang
Subject: Re: IEN 137: On Holy Wars and a Plea for Peace
Message-ID: <494@tty3b.UUCP>
Date: Mon, 10-Sep-84 12:45:58 EDT
Article-I.D.: tty3b.494
Posted: Mon Sep 10 12:45:58 1984
Date-Received: Sun, 16-Sep-84 11:22:16 EDT
References: loral.444 <491@turtlevax.UUCP> <1185@rti-sel.UUCP> <1136@hcrvax.UUCP> <1665@sun.uucp> <1675@sun.uucp>
Organization: Teletype Corp., Skokie, Ill
Lines: 56

Re: Big- vs. little-endians

In the article reprinted by sun!gnu, "On Holy Wars and a Plea for
Peace," Danny Cohen claims that only the Big-endians have produced
a fully consistent machine (memory-order wise); however, I would
submit that even such a Blefuscuian machine as the 68000 cannot
deny an inherent Lilliputian trait: its registers are little-endian!

It is agreed that the 68000 stores the most significant bit of any
length integer at the lower address in main memory:

	| C0 | C1 | C0 | C1 |
	|   W0    |   W1    |
	|     long 0        |
	|SMxxxxxxx|yyyyyyyyL|
	 "J"  "O"  "H"  "N"

But when a long word is put into a register and you try to access
the first half of it (W0), you get instead the Lilliputian first
half, W1:

	 "J"  "O"  "H"  "N"
	|SMxxxxxxx|yyyyyyyyL|   (D0.L)
		  |SMyyyyyyL|   (D0.W)
		       |SMyL|   (D0.B)
			"N"

In other words:

A 68000 register (e.g. D0) can be viewed as a little memory, of
which only the zeroth element can be accessed: L0, W0, or C0 (referred
to as D0.L, D0.W, D0.B respectively).  This is then a little-endian
memory, since C0 is the same as the little (least significant) end
of W0, and W0 is the little end of L0.  This is of course very practical
compared to the Big-endian alternative, since a 16-bit integer can
be converted to a 32-bit one with the same value by simply extending
the sign bit for 16 bits to the left, rather than by shifting all 16 bits
to the right.  Nevertheless, the little-endians seem to have successfully
planted a mole in the Big-endian camp!


On another issue touched on in Cohen's article, how many readers are
"top-endians" or "bottom-endians" when it comes to representing
memory vertically?  I personally favor the top-endian approach,
putting location 0 at the top of the page and letting addresses
increase downward, since this is consistent with code listings and
memory dumps.  (I guess that makes me a "computer scientist" rather
than an "engineer" - *sigh*)  I'm rather surprised, though, at the
number of published documents (e.g. certain DEC manuals) which have
bottom-endian memory maps or even toggle back and forth.

Thanks to sun!gnu for reposting an entertaining article.

Jon Luers
AT&T Teletype Corp.
ihnp4!tty3b!jhl