Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Endian wars
Message-ID: <21609@ames.arc.nasa.gov>
Date: 9 Feb 89 19:57:26 GMT
References: <6133@columbia.edu> <186@aucsv.UUCP> <21557@ames.arc.nasa.gov> <9468@cit-vax.Caltech.Edu>
Organization: NASA - Ames Research Center
Lines: 42

In article <9468@cit-vax.Caltech.Edu> wen-king@cit-vax.UUCP (Wen-King Su) writes:
>In article <21557@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:

>The little-endian format is the current dominate format - remember all
>the IBM PC's and their clones.  To evolve in the direction of a common

I did not mean to imply that DEC has decided to go Big OR Little Endian.
DEC's new machine is touted (I haven't seen an architecture
manual, so I can't vouch for the accuracy of it) to have duplicated the
stubbornly Middle Endian formats of the VAX.

Now, why SHOULD DEC build a consistent (big or little endian) data format
machine?  I don't know, consistency is the bugaboo of small minds, after
all.  

(

Quiz: Figure out, in your head, which byte (offset from the address in
memory) of a DEC F format fp number contains the least significant 
bits of the fraction (multiple choice):
a) byte 0
b) byte 1
c) byte 2
d) byte 3
e) I dunno, I never could figure it out.  But real programmers don't use f.p. 

)


>The SUN's XDR library has already provided us with a common interchange
>file format.  It probably does not address 64 bit integers.

I remember seeing a definition of XDR a couple of years ago - but in the 
context of RPC.  Is there an XDR FILE format definition?  NFS certainly
doesn't translate to/from it. 


-- 
  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117