allbery@ncoast.UUCP (Brandon S. Allbery) (06/26/88)
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. Why, you ask? An ABI exists so that different manufacturers porting UNIX systems to a particular processor can run the same programs, simplifying things for applications developers. Now: it makes sense to do this for the plethora of 80386 machines and 680x0 machines out there -- but for a VAX? Consider that (a) DEC does not license the VAX processor for anyone else's use, and (b) DEC sells the only true commercial VAX UNIX. The hardware question is obvious. As for Unixes for a VAX, we have: BSD 4.4 (it's a bit late to retrofit 4.[23] into an ABI, which also takes mtXinu out of the picture), Mach, and (potentially) Gnu. But Mach and 4.4BSD are *research* Unixes; as a result, they can experiment with new applications interfaces, etc. and are not expected to follow a given ABI. (They *could*, but in that case they would simply take the lead from DEC, on whom they are dependent anyway because of the hardware. Effectively, DEC as source of the processor becomes a clearinghouse for OS work and defines a de facto ABI.) And I strongly doubt that Stallman would let a little thing like an ABI get into his way.... 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. -- Brandon S. Allbery | "Given its constituency, the only uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/27/88)
In article <8185@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >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. It's not at all pointless! The lack of COFF support on VAX 4BSD has caused me vast amounts of otherwise unnecessary extra work. Also, we have sometimes acquired libraries (e.g. for DBMS systems) from third- party vendors, but since they've been for native 4BSD, they haven't been usable with our applications that are developed in the System V (emulated) environment running on 4BSD, even though I went through the trouble of adapting our System V environment to use 4BSD object formats so that the library is at least linkable (that's not enough to guarantee that it works right). Based on such experience, I would say that a good object or binary standard would be of considerable practical value. Perhaps DEC tried to register a COFF- or SVID-incompatible format as part of the VAX ABI? That would be good grounds for AT&T rejecting it.
dce@mips.COM (David Elliott) (06/27/88)
In article <8185@ncoast.UUCP> allbery@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@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
amos@taux01.UUCP (Amos Shapir) (06/27/88)
VAX is the only successful architecture that has no clones. Tahoe (CCI Power 6/32) is a close imitation, but certain changes were made to make sure it was *not* compatible with a VAX - if you have a Tahoe to hack on, look at the opcodes - they are mostly the VAX's opcodes, with the hex digits reversed! I participated in the original design team of the Tahoe; if there was an ABI for the VAX at the time (1982) CCI would probably use it. But DEC's attitude made it clear that they intend to make money selling iron, and would not favor cloning - the old 'software is what makes the hardware work' approach. (Rather than the other way round, which is more common nowadays). -- Amos Shapir (My other cpu is a NS32532) National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 amos%taux01@nsc.com 34 48 E / 32 10 N
)) (06/28/88)
In article <8185@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: | .... But I contend that DEC has no need |for a VAX ABI. |An ABI exists so that different manufacturers porting UNIX systems to a |particular processor can run the same programs, simplifying things for |applications developers. Now: it makes sense to do this for the plethora |of 80386 machines and 680x0 machines out there -- but for a VAX? Consider |that (a) DEC does not license the VAX processor for anyone else's use, and |(b) DEC sells the only true commercial VAX UNIX. Generally speaking I agree. If there is only one O/S vendor for a given machine, then that O/S vendor has the defacto ABI anywho. And I agree that most of the other versions of UNIX you mention aren't "commercial". But, what about HCR's SVR3 for VAXen? They've been shipping for several months now (I think). That I would consider "commercial"... -- Chris Lewis, Spectrix Microsystems Inc, Phone: (416)-474-1955 UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Moderator of the Ferret Mailing List (ferret-list,ferret-request@spectrix)
ok@quintus.uucp (Richard A. O'Keefe) (06/28/88)
In article <8185@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >Consider that (a) DEC does not license the VAX processor for anyone else's use Does anyone know/remember what the arrangement with SysTime is/was? They were selling VAXen, at least in the UK, with some changes.
jim@cs.strath.ac.uk (Jim Reid) (06/29/88)
In article <142@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >Does anyone know/remember what the arrangement with SysTime is/was? >They were selling VAXen, at least in the UK, with some changes. Systime used to be an OEM for DEC - I think they even went as far as building systems from DEC supplied parts as well as badging DEC kit. They are no longer in the DEC market after DEC sued them for not paying royalties on copies of DEC boards. There were also other nasty allegations about breaches of US export regulations, selling machines to agreed DEC-only markets (eg education) and corner cutting with cheap and/or barely-up-to-spec components. When DEC took over Systime's maintenance business, a lot of ex-Systime customers had to fork out for upgrades to bring their machines to the correct rev. levels. Jim -- ARPA: jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk UUCP: jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim JANET: jim@uk.ac.strath.cs "JANET domain ordering is swapped around so's there'd be some use for rev(1)!"
allbery@ncoast.UUCP (Brandon S. Allbery) (07/06/88)
As quoted from <686@spectrix.UUCP> by clewis@spectrix.UUCP (Chris Lewis (It's loose again!)): +--------------- | In article <8185@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: | |that (a) DEC does not license the VAX processor for anyone else's use, and | |(b) DEC sells the only true commercial VAX UNIX. | | And I agree that most of the other versions of UNIX you mention aren't | "commercial". But, what about HCR's SVR3 for VAXen? They've been shipping | for several months now (I think). That I would consider "commercial"... +--------------- I hadn't heard of that, and hereby withdraw my argument. Thanks for the update. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
tbetz@dasys1.UUCP (Tom Betz) (07/08/88)
*n article <8221@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <686@spectrix.UUCP> by clewis@spectrix.UUCP (Chris Lewis (It's loose again!)): *+--------------- >| In article <8185@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: *| |that (a) DEC does not license the VAX processor for anyone else's use, and *| |(b) DEC sells the only true commercial VAX UNIX. *| *| And I agree that most of the other versions of UNIX you mention aren't *| "commercial". But, what about HCR's SVR3 for VAXen? They've been shipping *| for several months now (I think). That I would consider "commercial"... *+--------------- * *I hadn't heard of that, and hereby withdraw my argument. Thanks for the *update. * What about Mt. Xinu's BSD? They also support AppleNet and TOPS connectivity, and I understand they have been shipping for more than a year. -- Tom Betz UUCP: ...!cmcl2!phri!dasys1!tbetz ZCNY "When personal computers are outlawed, Yonkers, NY, USA 10701-2509 only outlaws will have personal computers."
allbery@ncoast.UUCP (Brandon S. Allbery) (07/22/88)
As quoted from <5398@dasys1.UUCP> by tbetz@dasys1.UUCP (Tom Betz): +--------------- | What about Mt. Xinu's BSD? They also support AppleNet and TOPS connectivity, | and I understand they have been shipping for more than a year. +--------------- ntXinu's BSD Unix is just a repackaging of a RESEARCH Unix in order to bring it up to commercial standards. But it's still ultimately the research Unix. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc