home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / arch / 12139 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  4.5 KB
  1. Path: sparky!uunet!olivea!sgigate!odin!mips!vermont.mti.sgi.com!jackc
  2. From: jackc@vermont.mti.sgi.com (Jack Choquette)
  3. Newsgroups: comp.arch
  4. Subject: A theory for Big & Little Endian's origin
  5. Message-ID: <1iig7aINNtc@spim.mti.sgi.com>
  6. Date: 8 Jan 93 00:00:42 GMT
  7. Organization: Silicon Graphics, Inc.
  8. Lines: 123
  9. NNTP-Posting-Host: vermont.mti.sgi.com
  10.  
  11.  
  12. To me it seems like different endianess came about because of the way
  13. humans like to see things listed out.  When humans make a list, they
  14. like to make and read it top to bottom:
  15.         0  ******
  16.         1  ******
  17.         2  ******
  18.          etc.
  19.  
  20.  
  21. For reasons explained in previous posts, humans (who read left to right)
  22. like to read the most significant digit first.  So they place the most
  23. significant digit on the left:
  24.         1,0562
  25.  
  26. When you number the digits, you could number them in the same order
  27. that you read them:
  28.         digit #        0  1  2  3  4
  29.         digit value    1, 0  5  6  2
  30.  
  31. This has the problem that as numbers get bigger, their digit numbers 
  32. change.  
  33.         digit #        0  1  2  3  4  5
  34.         digit value    7  3, 1  9  3  1
  35.  
  36. Also when you are comparing numbers of different sizes, their
  37. respective digit # doesn't correspond to the digits value.  In the
  38. two examples above, digit #0 in 1 thousand for one but it's 
  39. 70 thousand for the other.
  40.  
  41. So it makes more sense, mathematically at least, to reverse number
  42. numbers and zero fill the number that are not there.
  43.         digit #        5  4  3  2  1  0
  44.         digit value    0  1, 0  5  6  2
  45.         digit value    7  1, 0  5  6  2
  46.  
  47. Now we come to representing numbers in computers.  Being mathematically
  48. inclined, computer engineers represent numbers by putting the least
  49. significant bit in the lowest numbered (and addressible) spot.  Being
  50. human, when they print out the number they print out the most significant
  51. bit first:
  52.         digit #/address        7  6  5  4  3  2  1  0
  53.         digit value (bin)    0  1  0  0  1  1  1  0   =   78 dec
  54.  
  55. As computer engineers build computers, they want to be able to address
  56. chunks of bits instead of individual bits.  They choose a chunk size of
  57. 8 bits.  Why 8, because it is the only power of 2 number that gives you
  58. enough bits to represent the entire alphabet.
  59.  
  60. Now they want to list out the contents of their memory.  Being human,
  61. they do it top to bottom, in ascending order so you can read the 
  62. characters and text stored there:
  63.          Location    Bit Value  Ascii
  64.         0    01001110     H      {I know these are not the correct}
  65.         1    10100010     E      {  ascii values}
  66.         2    00010111     L
  67.         3    00010111     L
  68.         4    11110111     0
  69. So text and programs are stored in order of ascending memory locations.
  70.  
  71. But what happens when you want to specify a number that is 16bits wide
  72. and store it at location 1?  Obviously you divide up the number into
  73. two 8bit chunks and store it in location 1, and the location
  74. following, location 2.
  75.  
  76. Where does the most significant 8bits (byte) go?  If you're human, you
  77. feel the most significant byte should go first, so you put it in
  78. location 1
  79.          Location    Value
  80.         1    11111111
  81.         2    00000000
  82.  
  83.     Number:  11111111   00000000
  84.     Bit #     76543210   76543210
  85.     Byte #        1          2
  86.  
  87. However, if you're mathematically inclined, you want the numbering of the
  88. bytes to be in reverse order for the same reason the numbering of the
  89. bits is in reverse order:
  90.          Location    Value
  91.         1    00000000
  92.         2    11111111
  93.  
  94.     Number:  11111111   00000000
  95.     Bit #     76543210   76543210
  96.     Byte #        2          1
  97.  
  98. In the first case you get Big Endian, in the second you get Little
  99. Endian.
  100.  
  101.  
  102. I think it's interesting to note that within a byte, the order is
  103. always Little Endian.  This is because when computers where developed,
  104. the designers wanted bit numbers listed left to right but numbered
  105. left to right:
  106.         digit #/address        7  6  5  4  3  2  1  0
  107.         digit value (bin)    0  1  0  0  1  1  1  0   =   78 dec
  108.  
  109. So in effect Big Endian is inconsistent when dealing with binary
  110. numbers.  However it has the advantage of being seemless when memory
  111. values are printed out.  When memory is printed out, the bytes are
  112. printed out lowest to highest (because that's the way text and
  113. programs are stored) but the bits within a byte are printed highest to
  114. lowest:
  115.  
  116.    Printout:
  117.     01001110 10100010
  118.  
  119.    Translates to 
  120.     Number:  01001110   10100010
  121.     Bit #     76543210   76543210
  122.     Byte #        1          2
  123.  
  124. In order to be consistent numerically, Big Endian bytes should be
  125. stored and printed in ascending bit values.
  126.  
  127. The flip side is that Little Endian text and programs should be stored
  128. and printed out in descending memory locations so that text and
  129. programs are stored with the same ordering as binary numbers.
  130.  
  131.  
  132.  
  133. /jack
  134.