home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / arch / 12168 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  2.4 KB

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