🚀 go-pugleaf

In <558@oracle.UUCP> rbradbur@hqpyr1.oracle.UUCP (Robert Bradbury) writes:
# There is no excuse for this.  Vendors of large application programs [...]
# are getting very tired of vendors of hardware who can't get their act
# together to standardize on ABI's.

I'm sure there are people at MIPSCO just hopping from one foot to the other
wishing there were an ABI for their chip.  I can only guess that they thought
everybody would follow the a.out and *.o and syscall assignments that they
used in their UMIPS and SYSV products; however, various teams of gurus who
had these chips and/or machines handed to them with the directive: "port UNIX
to it and make it look as much like our other products as you can and get it
done in time for COMDEX" just did not have ABI's in mind.  I'm not happy about
it, but I do understand it.

Even if they had ABI's in mind, could they have agreed?  Would they have let
OSF or MIPSCO mediate?  Binding arbitration among competitors?  I'll believe
it when I see it.  I'd love to see it, of course, but I'd be careful about
threatening to hold my breath until it happens.

# Sequent and Pyramid have demonstrated that you *can* provide a single
# environment which supports both BSD and SV system calls.  The 88000
# group is wisely starting out up front by standardizing on an ABI.

I applaud the 88000 people.  So far the marketing (and an ABI is _marketing_,
folks!) of the 88000 has been fantastic.  It may well be the first counter-
example to what I asserted above about competitors being polite to eachother.
But the 88000 is not yet taking the world by storm, while the MIPSCO chip _is_.

Sequent and Pyramid both have great products, but since Pyramid runs a closed
architechture and since Sequent is incompatible with all other NS32000 and
80386 machines, I don't see them as luminaries of the cause of the ABI.

# MIPS & DEC are shooting themselves in the foot by not providing [...] ABI's

Wait, wait.  MIPS may be shooting themselves in the foot, I don't know.  But
as Gettys pointed out in another article in this forum, DEC's MIPS-based
machine is as compatible as possible with the rest of what DEC sells.  If you
have a VAX/Ultrix port of Oracle, chances are you'll have little trouble
making it run on the 3100.

Also, DEC has always provided as much upward binary compatibility as they
could -- many VMS 1.0 binaries (and RSX-11 binaries, for that matter) will
run on the latest VMS, and most Ultrix 1.0 (or BSD 4.2) binaries will run
on the latest Ultrix.  I'm interested in hearing from anyone who thinks
that DEC is about to change that policy.

# Yes, research people would like BSD 4.3.  A great environment for research,
# but not one that can support a high performance RDBMS due to its lack of
# robust IPC primitives.  I'll take a real O.S. that conforms to the SVID
# any day of the week.

(Groan.)

Have a look at the latest CSRG proposal for IPC if you want to see "robust".
The less said about SVID IPC, the better.  :-(.

# I'm not in management at Oracle, but I suspect my opinions are close to
# management's given the amount of money we have to spend to support products
# for vendors who can't get it organized to standardize binary interfaces.
#
# Robert Bradbury
# Oracle Corporation
# (206) 782-9474                            hplabs!oracle!rbradbur

Standard disclaimer: I don't speak for DEC, I just work here.  If any of my
words above are quoted, please include this paragraph.
--
Paul Vixie
Work:    vixie@decwrl.dec.com    decwrl!vixie    +1 415 853 6600
Play:    paul@vixie.sf.ca.us     vixie!paul      +1 415 864 7013