Xref: utzoo comp.arch:7961 comp.misc:4774 comp.lang.misc:2581 comp.protocols.misc:462
Path: utzoo!attcan!uunet!munnari!vuwcomp!wnv!gpwd!gpwrdcs
From: gpwrdcs@gp.govt.nz (Don Stokes, Govt Print, Wellington)
Newsgroups: comp.arch,comp.misc,comp.lang.misc,comp.protocols.misc
Subject: Re: "big endian" and "little endian" - first usage for computer
Message-ID: <212@gp.govt.nz>
Date: 20 Jan 89 05:30:41 GMT
References: <2766@cbnews.ATT.COM> <10147@well.UUCP> <13045@cup.portal.com> <20264@ames.arc.nasa.gov>
Organization: Government Printing Office, Wellington, New Zealand
Lines: 21

In article <20264@ames.arc.nasa.gov>, 
  lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>                             VAXes, of course, are not consistent little-
> endian or big-endian, but then, we are not supposed to have to read dumps
> anymore anyway, remember ?  :-)
> 
VAXes are definitely little-endian as far as integers go ... and reading 
dumps is not a problem ... VMS DUMP puts the hex part of the dump in reverse
order, so all the bytes are in the right order, and numeric values can be 
easily distinguished.  It is just a matter of learning to read from right to
left...

The important part about little endian vs big endian (which can cause problems)
is overlaying of disimilar data types.  If I overlay a byte onto a word on a 
VAX (or any other little-endian processor), put in a word value < 256, and do a
byte read from the same address, I will get a correct response.  If I do the
same thing with a big-endian processor, I will get zero. 

Of course you don't usually overlay floating point numbers ... so the order of
the bytes in a floating-point number is (usually) irrelevant ...

Don Stokes
Systems Programmer
Government Printing Office, Wellington, New Zealand.