ABIs and the futurrrr of UNIX(tm)

[David F. Carlson]

This is a reposting as a machine ate the first try for most locales:


There has been much UNIX news recently on the subject of ABI (Application Binary
Interface) standard which AT&T along with Motorola, SUN and Intel are setting.
If I understand the problem, as it is now each UNIX vendor for any machine
they sell UNIX for is responsible for defining a binary protocol for things such
as alignment (and/or packing), traps to kernel with associated arguments, etc.
This means that each vendor of 680x0 or SPARC or 80x86 can potentially define
a proprietary binary format which renders their binaries to be only executable
on their version of UNIX.  Or in other words, there may be no big win derived
from building/buying a system from standard hardware (680x0) over any vendor's
proprietary hardware.  Thus, the key to UNIX portability is high level language,
not binary standards that other operating system / hardware vendors use to 
keep customers within the fold.  Remember not too many years ago when you told
your IBM rep that VM/370 binary standard or VAX/11 VMS binary standard were
not in your long term best interest but in theirs?  That their claims of
portability across *their* machine line would not lead to long term 
portability and target machine independence that modern software engineering
and marketing reality dictates one would like to achieve.

The trick to the UNIX portability (for SystemV only) was to take your *source*
code and compile on someone elses machine.  If properly coded, portability
within SystemV is not very difficult to achieve.  However, no vendor wants
to support thousands of variants and few vendors want distribute their 
proprietary source code to all comers.  (Public domain codings of XWindows, 
USENET Netnews, etc. illustrate that real portability in high level language
is not a LaManchian dream.  It is the proprietary nature of software that 
is the bone in the throat of software houses for source distribution.)

The AT&T ABI seems to be an attempt to allow at least partial standards for
machine binary interchange (restricted to processor families.)  What this
in effect will say is that there are preferred hardware platforms for UNIX,
the portable operating system, in that software vendors using popular ABI 
platforms will be able to sell more software that those using perhaps
technically superior but not a popular ABI would.  In turn, buyers will
bypass a technically superior solution in favor of a popular ABI option
solely because of binary interchange:  exactly why we rejected popular software
platforms to choose UNIX in the first place.

The big winners seem to be software vendors who would no longer have to pay 
for multi-vendor ports and support, and hardware vendors of popular ABI 
machines (in all likelihood Motorola, Intel and SUN.)  So SUN and AT&T
are the really big winners.  The losers are other UNIX vendors for less 
popular platforms like Amdahl, CRAY, HP, MIPS, Allient, AMD29000-based, 
NS32XXX-based, Multiflow, and even the venerable VAX.  The VAX will be 
the really big loser:  DEC is so ancy about systemV they may reject the 
whole idea.  Furthermore AT&T has announced that the VAX will no longer 
be a primary port engine:  SUN's SPARC will be.  No sooner than these ABIs 
become real standards will vendors stop supporting non-ABI architectures.  
(For example, will SUN sell XXXX source when the three major ABI's allow 
them to support the three machine types they sell by binary interface alone?
It seems unlikely.  Note that Intel and Motorola ABIs would cover 95%+ of
all UNIX sites.)

I believe what we all seek is a means of portability across machines lines
without having to support N-machines to sell a product.  Parts of this are in
place:  COFF has conversion routines for correctly ordering big-endian vs. 
little-endian data sections.  Why can't a machine independent intermediate
form be developed for UNIX solely to be translated into native binary on the
target machine by a similar utility?  This form would have to be opaque 
enough to discourage un-compiling but adaptable enough to allow for tight 
native translation on any SystemV (and eventually POSIX) machine.  Perhaps
a meta-assembler language such as the DoD CORE set as a possible portable 
target code for PCC.  Or perhaps even some intermediate PCC form that a code
generator fixes on the target.  The form should not preclude typical machine 
dependent optimizations and data packing.

There are very good reasons for wanting high-level language portability across
machines.  In particular, having hardware vendor independence and the ability
to choose a not-so-popular but technically superior hardware platform without
forfeiting hardly *anything*.  The reasons for ABI are to facilitate hardware
dependent portability.  The cost of ABIs may be setting up a "preferred" UNIX
hardware platform or platforms which, as a standard, could preclude 
consideration of a non-ABI platforms because of the manifest advantages of 
the preferred, albeit perhaps technically inferior, (ABI) platform(s).

-- 
David F. Carlson, Micropen, Inc.
...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave

"The faster I go, the behinder I get." --Lewis Carroll