🚀 go-pugleaf

I always get amused by Sun folks pushing binary comptibility, when Sun
has sold at least (depending upon how you count) three or four or five
architectures (680x0, 80386 and SPARC) and has never maintained even
complete compatibility between any two series of machines, even within the
same family of processors (Sun 1, Sun 2, Sun 3, Sun 4, Sun 386i), and often
even between releases of their OS.  Maybe they've finally learned the
lesson Digital learned over a decade ago...  During the same period,
Digital has produced 6 additional implementations of the same VAX
architecture, fully binary compatible with each other, to go along with
the three which precedes Sun's existance. And with very limited
exceptions, there has been binary upward compatibility on both VMS and
Ultrix during this entire period.  Throwing stones in glass houses is
usually a mistake.

We certainly carefully considered which byte order the PMAX (DECstation
3100) should be run in; in fact, early prototypes have a jumper (never
used) which determines the byte order.

Now let us examine what various people have suggested; that we should be
selling UMIPS on a big endian MIPS machine.  I believe those same people
would be castigating us about offering two Unix versions,  incompatible
with each other, of differing byte orders, maximizing the trouble to port
to DEC hardware.  (Not to even mention the problems this would cause
us internally).  No matter what we did, it was not possible to make
everyone happy.

There are certainly good arguments to the byte order question; both sides
have cogent arguments on their sides; just look at the wasted network
bandwidth in this and other newsgroups on the topic.  And being one of the
authors of one of the more portable pieces of software in the world, I am
completely familiar with the problems of porting software, having spent
significant amounts of my time while a DEC employee making sure it would
run on RT/PC's, Suns, and other machines.

So we went with the byte order which, though us Unix bigots may not like
it, is most compatible with the most machines and software in the world,
the Intel based PC's (next to which, the hundreds of thousands of VAXes
pale, though internal to Digital it is a real issue; for example we have
DECnet at FRS, which probably woundn't have made it if the byte order were
the other way). I have already recieved mail from one major third party
software vendor who was very happy to hear the machine was the same byte
order as the PC, as it was going to aid his port from the PC to the
DECstation 3100. But as usual, there are arguments on both sides, as
another note from a different vendor in this newsgroup suggests.

And the choice certainly aids other ports and compatibility with the VAX;
for example, the entire core client X distribution compiles and runs on
the DECstation 3100 without any ifdef's in any code (you do have to fool
it into thinking it is a VAX, as at the moment there are architecture
ifdef's for mips in the imake code which really should be UMIPS ifdefs;
fixed we hope in X11R4).  The port of X to the PMAX was by far the easiest
I know of (having participated in ports to the Sun, RT/PC, and a bit to
the Apollo and CCI over the last 3 years, though a CCI running 4.3BSD
was about as trivial back in V10 days).

And I will be happy when OSFix makes real binary compatibility possible
between vendors using the same architecture/byte order; I certainly
understand the problem of the 3rd party vendors.  But at the moment, this
was the way we could give them the most REAL compatibility to help them
until this day actually arrives; it certainly doesn't exist today for
anyone's version of Unix.

So, on the issue which is one of the biggest portability sticking points,
Digital is at completely consistant; all of our current machines are
the same byte order (PC, VAX, MAX).  Ultrix on the DECstation 3100 looks
essentially identical to that on the VAX, and an amazing amount of code
recompiles and runs without change.
			Jim Gettys
			Digital Equipment Corporation
			Cambridge Research Laboratory
			Cambridge Massachusetts, 02139

<the usual disclaimers go here>