Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!lognet2!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: byte order: be reasonable - do it my way...
Message-ID: <11939@sun.uucp>
Date: Thu, 22-Jan-87 21:27:37 EST
Article-I.D.: sun.11939
Posted: Thu Jan 22 21:27:37 1987
Date-Received: Fri, 23-Jan-87 21:36:03 EST
References: <760@orcisi.UUCP> <112@lmi-angel.UUCP> <172@ames.UUCP> <203@ames.UUCP>
Sender: news@sun.uucp
Lines: 77
Keywords: byte order, big-endian, little-endian

>            I have to disagree with this.  When the IEEE floating point
>            standard was first proposed, everyone said that that it would
>            never fly.  Well, it has been almost ten years, but in fact
>            almost all new workstations and minicomputers are using it.

Note the word "new" here.  I said that the chances of getting any
current vendor to change their byte order based on some standard are
somewhere between zip and nil, and I stand by that claim.  If IEEE
chooses a standard byte order, the chances that Motorola, IBM, Intel,
National Semiconductor, DEC, or whoever will declare a flag day and
that the 68000, 370, 8086, NS32000, VAX, etc. families will instantly
change their byte order are, again, somewhere between zip and nil.
Neither the 370 nor the VAX have adopted the IEEE standard, so it
doesn't give any encouragement that *existing* machines will somehow
adopt an IEEE byte order.

We won't even discuss: the chances that a committee that will,
presumably, have Intel, DEC, and National Semiconductor on it will
choose a big-endian byte order; the chances that a committee that
will, presumably, have Motorola on it will choose a little-endian
byte order; or the chances that a committee that will, presumably,
have IBM on it will choose *any* byte order (they have one major
big-endian line, and one little-endian line, and there is no way in
hell that they're going to blow either of those lines out of the
water).

>            If bit-byte-word order can be resolved, in ten years everyone
>            will be using it.

Give me a break.  *Everyone*?  If we choose a big-endian byte order,
in ten years all the IBM PCs out there will become big-endian?  If we
choose a little-endian byte order, in ten years all the 370s out
there will become little-endian?

(I remind you that the ASCII character set has been adopted as a
standard, and there are still machines that use - and will continue
to use - EBCDIC internally.  It's been more than 10 years since ASCII
was adopted.)

>	     And, in the meantime, software could be written knowing what
>	     the standard order will be.

And that software will not run on a very large percentage of the
machines out there.

You don't seem to realize that the format of integral data,
addresses, instructions, etc. are several orders of magnitude more
central that the format of floating-point numbers.  DEC has adopted
floating-point formats in the VAX (G and H), but they still support
the old formats.  In theory, if they felt so motivated they could
probably add IEEE formats as well.  It's nowhere near that simple for
byte order; if DEC were to adopt a big-endian byte order for the VAX,
they'd have to add big-endian versions of most of their instructions
to the VAX instruction set, or add a mode bit to select the byte
order.  If they did the latter, they'd have to have software that
could deal with data files, etc. with either byte order, and two
versions of library routines, and two versions of system calls, etc.,
etc., etc..

>            In any case, with networked environments becoming the norm,
>            lots of sites are going to want to be able to move binary
>            data between machines.  Don't expect that this issue will
>            go away.

Sigh.  Have you ever heard of X.400, or Sun XDR, or...?  I'm *quite*
aware that there is an issue of moving binary data *between*
machines.  This does not, however, mandate a standard byte order for
representing data internally on machines!  Yes, having to convert
data into some standard external form when passing it between
machines is a nuisance; however, the inconvenience involved in making
this conversion is much smaller than the inconvenience involved in
changing something as fundamental as the byte order in an
architecture that has a large existing software and data base.

I certainly don't expect that this issue will go away, for one simple
reason - it'll be a cold day in Hell before all the machines out
there have the same byte order!