Xref: utzoo comp.arch:7783 comp.misc:4623 comp.lang.misc:2467 comp.protocols.misc:439
Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!killer!mic!d25001
From: d25001@mic.UUCP (Carrington Dixon)
Newsgroups: comp.arch,comp.misc,comp.lang.misc,comp.protocols.misc
Subject: Re: "big endian" and "little endian" - first usage for computer
Message-ID: <205@mic.UUCP>
Date: 7 Jan 89 05:50:33 GMT
References: <2766@cbnews.ATT.COM> <10147@well.UUCP> <13045@cup.portal.com> <20264@ames.arc.nasa.gov> <2695@rti.UUCP>
Reply-To: d25001@mic.UUCP (Carrington Dixon)
Organization: Micro Net
Lines: 41

In article <2695@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes:
 
>My immediate thought on seeing the VAX instruction set when it first came
>out was that by making the byte order "little endian" it allowed something
>like a Fortran compiler to take a statement like:

>	call sub (1)

>and pass a number to it (a longword - 4 bytes) which would be interpreted
>correctly whether the receiving formal parameter was a byte, a word (2 bytes),
>or a longword (4 bytes).  This is not possible in a "big endian" machine -
>you have to know how many bytes of high order 0's to write before you get to
>the low order byte.  Considering that the Fortran of the day had no way to
>declare the formal parameters for subroutines, and the importance of
>Fortran in the early days of the VAX (and the fact that the VAX was built
>with a great deal of input from the software guys), could this be the REAL
                                                     ^^^^^^^^^^^^^^^^^^^^^^
>motivation for "little endian"?
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

     If I thought that it was, my respect for DEC would take a BIG drop.
Passing a longword and receiving a word is an ERROR.  Sure, it works fine
for your example, but what if the statement were:
  
       call sub (70000)

Now both the big- and little-endian machines are receiving the "wrong"
value.   On the big-endian machine, the developer will probably find
his/her mistake during initial checkout.  On the little-endian machine
the error _may_ not be found until the module has been in production,
spewing out wrong answers for months.  I don't know about what kind of
environment you work in, but where I work this kind of error could cost my
company $k in data that had to be reprocessed.  (Not too mention egg on
our corporate face if a client were to discover the gaffe.)

     And now to lighten up....  No, this cannot be the _REAL_ motivation
for the little-endian data format, because this is INTEGER data (-::-)
snicker ... snicker ...  

Carrington Dixon
UUCP: { convex, killer }!mic!d25001