Why DEC doesn't need an ABI

[David Elliott]

In article <8185 at ncoast.UUCP> allbery at ncoast.UUCP (Brandon S. Allbery) writes:
>I believe we're all aware that DEC was denied an ABI for the VAX processor
>line.  DEC was rather annoyed about it.  But I contend that DEC has no need
>for a VAX ABI.

One of the reasons that Mips applied for an ABI is that there are multiple
versions of our operating system out there.  SGI and Mips are not binary
compatible, but would like to be.  By having an ABI, we allow our OEM
customers to develop their own operating systems, while forcing them to
remain binary-compatible ("forcing", that is, if they wish to be part of
our ABI).

DEC has the same problem with the various Unixes out there.  With an ABI,
they can say "all shrink-wrapped software stamped 'VAX ABI' will work
on any OS stamped 'VAX ABI'".

>Thus, for DEC to register an ABI would be pointless, and if so doing would
>create work for AT&T that would have no effect on portability then AT&T has
>no reason to accept a VAX ABI.

This is not quite correct.  My impression is that AT&T is saying
"anyone that fits into the open architecture category they've defined
can have an ABI, but we may not be able to devote manpower to helping
you get

In addition, a great reason for DEC, or anyone else for that matter, to
have an ABI is to benefit from getting pre-release software information
instead of having to wait until the next release is out on a 3B2, 386,
Sun, or other ABI'ed platform.

Another good reason is to be able to get in on the design effort
early.  Anyone with an alliance with AT&T, even if it's just via the
name "ABI", has much more of a chance to ask AT&T to consider a feature.

A final good reason is the Unix name.  If you have an ABI with AT&T,
you can call your product Unix; not Ultrix, not UTek, not ROS, not AIX,
not AUX, not UMIPS -- Unix.

-- 
David Elliott		dce at mips.com  or  {ames,prls,pyramid,decwrl}!mips!dce