Application Binary Interfaces

[John Woods]

In article <24369 at pyramid.pyramid.com>, sas at pyrps5 (Scott Schoenthal) writes:
> My current impression (admittedly somewhat uninformed) is that the ABI
> standard (I assume this is what John [another one. -ed] is referring to) is
> a crock.  Given the recent explosion of micro-processor designs which have
> come out in the last year, the notion of an ABI seems to me to be useless.
> 
Although I don't have much of a feeling for how ABI's fit into the flaming
about OSF is the reincarnation of Elmer FUD, or whether the Death Sun is
going to develop secret extensions designed to annoy vendors, but I rather
like the notion of Application Binary Interfaces.  I grant that they don't
solve the processor type explosion, but they do solve a distinct problem:

Most of the moderately small purveyors of 680x0 UNIX boxes selected slightly
different system call numbering schemes and calling conventions, since they
received a VAX tape from AT&T (or whatever; certainly not a 680x0 tape), and
thus had to do it themselves.  Now, consider the situation of a moderately
small software house with a whizz-bang combination spreadsheet-and-CAD-system.
Is it worth their while to port it to a new potential user base of maybe a
couple of hundred customers, of out a few thousand systems a random vendor
has shipped?  Is it worth their while to do this *weekly*?  Sometimes yes,
often no.

Enter the 68020 ABI.  Now there is an agreed-upon standard that everyone
shares; perhaps no two systems have the same "native" system call interface,
but they "all" have one in common.  Crash Coredump Software, Inc., now does
not need to do 16 different ports to oh-so-slightly-different system call
interfaces, but instead needs only to do one port to the ABI interface,
gaining a large number of potential customers in one fell swoop.

The [23]86 world has less of a problem with this; a definitive UNIX port was
available by the time there was great interest in running UNIX on the 286 and
386.  Oops: there were TWO definitive UNIX ports, of course -- XENIX and
386/IX -- which is why an ABI is being developed for the 386 as well.  (I kind
of assume that there exist other 386 UNIX systems, but I haven't personally
heard of them; they'll benefit as well).

Now, of course, if one vendor (or bi-vendor consortium) exercised exclusive
control over UNIX ports, then none of this would be a problem (aside from the
680x0/x86/SPARC n-chotomy).  But then they would not have any competitors at
all (aside from people repackaging PC clones in attractive designer cases :-),
and most of us on the net would be slaving over COBOL payroll packages :-).

So, in short, Application Binary Interfaces really do benefit the customer
by making it *possible* to have access to a much wider array of third-party
software (which is the best kind of "marketing strategy").  Whether or not
key third-party software vendors agree remains to be seen.

Disclaimer of sorts:  UNOS is not UNIX internally, and has a radically
different system call interface (though similar in spirit).  Nevertheless,
when the 68020 ABI is finally hammered into shape, we expect to be able to
provide that interface to our system.  Fancy that!
-- 
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, john at frog.UUCP, ...!mit-eddie!jfw, jfw at eddie.mit.edu

No amount of "Scotch-Guard" can repel the ugly stains left by REALITY...
		- Griffy