Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Help us defend against VMS!
Message-ID: <7426@brl-smoke.ARPA>
Date: 7 Mar 88 22:34:41 GMT
References: <1636@tulum.UUCP> <3168@phri.UUCP> <497@taux01.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 21
Keywords: ABI

In article <497@taux01.UUCP> yuval@taux01.UUCP (Gideon Yuval) writes:
>The new ABI standard, which is supposed to be the Unix standard for object-code
>distribution, is (a variation of) COFF for SPARC. How much hardware-indpendence
>is going to survive the changeover to ABI?

I don't think this much matters.  Few vendors of UNIX-derived systems
have been using COFF (this is particularly true of those who started
from a Berkeley base), and the only things this has mattered for are
shared libraries, debuggers, and stand-alone development, none of
which is important for application source portability.  The only
benefit of ABI would be binary portability among SPARC implementations;
I suppose AT&T and Sun envision shrink-wrapped UNIX software for sale
in the local supermarket.  Somehow I doubt that most established
computer manufacturers will want to give up their own architectures
in favor of SPARC -- or is there some mathematical proof of its
superiority?  However, I could be surprised; there have been several
instances of a manufacturer adopting an existing instruction set
architecture (IBM 370, MC68000, DEC-10, VAX-11) for its own line of
computers.  For example, we have several Alliant FX/8s, which are fast
implementations of the MC68000 instruction set (and even include
MC680x0s for general-purpose (non-vector, non-parallel) processing).