home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!auspex-gw!wally
- From: wally@Auspex.COM (Wally Bass)
- Newsgroups: comp.arch
- Subject: Re: A theory for Big & Little Endian's origin
- Message-ID: <16294@auspex-gw.auspex.com>
- Date: 8 Jan 93 20:02:07 GMT
- References: <1iig7aINNtc@spim.mti.sgi.com> <1993Jan8.120225.8330@infodev.cam.ac.uk> <willmore.726511292@help.cc.iastate.edu>
- Sender: news@auspex-gw.auspex.com
- Organization: Auspex Systems, Santa Clara
- Lines: 37
- Nntp-Posting-Host: auspex.auspex.com
-
- In article <willmore.726511292@help.cc.iastate.edu> willmore@iastate.edu (David Willmore) writes:
- >The other way fixes the load problem. Say you want to read an 8
- >bit value starting at address 0. The first byte read goes in the
- >low order part of the register, the rest is cleared. To load a
- >16 bit value, address 0 is placed in the low byte of the register
- >and the next byte at address 1 is placed in the next higher byte
- >of the register. That way, a 32 bit or more number can be at a
- >fixed location and you can optionally load 8 bits, 16 bits, or the
- >full 32 bits without having to adjust your address register.
-
- Actually, I think that it's not the 'load' problem so much as it is
- the 'add' problem. When you are going to do an add on a machine with
- 1 byte adder, you want the low order bytes of both operands first,
- and the high order bytes last, because that is the direction in
- which the carry propagates.
-
- Noting that a great many of the operands to the adder are literals
- in the the instruction stream (i.e., both literal constants and
- memory address offsets), on a machine with a narrow data path,
- one would like to arrange things such that, at least for constants
- in instructions, normal instruction prefetching encounters
- low order bytes first. Once you chose that format in the I-stream,
- doing it for other data follows for all kinds of reasons.
-
- Given that Intel x86 started as narrow data flow stuff, it's
- not surprising that it ended up with low-byte-first.
-
- For architectures which weren't so biased by a narrow data flow in
- their earlier years, high byte first makes more sense, if only to
- allow arithmetic values in dumps to be read more easily. (This
- indeed, may vary according to the native language in use, but the only
- languages which enter into the question are the native languages
- of the early developers who first established the conventions, and
- I think these were primarily of European/USA origin.)
-
- Wally Bass
-
-