Xref: utzoo comp.sys.dec:919 comp.arch:7855 Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!vsi1!daver!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.sys.dec,comp.arch Subject: Re: DECstation 3100 info. (really, ABIs and all that) Message-ID: <11282@winchester.mips.COM> Date: 16 Jan 89 06:06:21 GMT References: <979@isieng.UUCP> <85330@sun.uucp> <558@oracle.UUCP> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 118 In article <558@oracle.UUCP> rbradbur@oracle.UUCP (Robert Bradbury) writes: >In article vixie@decwrl.dec.com (Paul A Vixie) writes: >>Well, waitaminute. There is no ABI for MIPSCO as yet; binaries from an Ardent >>are not going to run on a MIPSCO M1000. Heck, binaries from a SysV MIPSCO box >>don't run on a UMIPS 4.3 MIPSCO box. >Sequent and Pyramid have demonstrated that you *can* provide a single >environment which supports both BSD and SV system calls. The 88000 >group is wisely starting out up front by standardizing on an ABI. >The reason UNIX has taken so long to succeed in the market place >is because there was no application software. The reason that there >was no application software is because application vendors cannot >afford the machines, development time, support staff, etc. to support >14 different flavors of UNIX for each hardware platform out there. >(Quick test: how many vendors are there of UNIX 68000 boxes?) >MIPS & DEC are shooting themselves in the foot by not providing a standard >ABI's for the large software vendors. We will not port software for a >machine unless it is clear that there is sufficient demand out there to >justify our investment. By subdividing the MIPSCO marketplace MIPS & DEC >are that much less likely to be able to generate sufficient sales for vendors >to justify supporting those os/hardware combinations. And of course the lack >of application vendor support on those platforms increases the probability that >customers will chose to go with other machines (like 88000 based boxes) where >there is a standard ABI and software vendors know months or years in advance >that they will be able to justify porting their software to that environment. To inject some reality into this discussion, I observe the following: 1) All MIPS-built machines are big-endian, as are essentially all Rxxxx-based systems. The first MIPS-built systems shipped in 1986. 2) All of the newer MIPS machines are System-V-based (with a whole lot of BSD features, and shortly to have enough to make even BSD-fans (of which we have plenty of at MIPS) happy. The reason for the merge, of course, was EXACTLY the issue of application software; although we are still supporting our BSD customers, of course, we'll be encouraging them to convert upon the next release. I.e., this ABI issue has little to do with BSD versus SYS V. 3) MIPSco does not REQUIRE our customers to do anything in particular. However, you will find that quite a few binaries interchange amongst machines [the Ardent ones are different, given the different FP hardware, but they are working on being able to handle the "standard" binaries.] Synthesis Software Solutions, Inc, works pretty hard on this issue, and we work with our customers to allow necessary extensions to co-exist with the enough compatibilty that most reasonable applications have a chance of being binary-compatible. 4) Across most MIPS-based machines, regardless of who builds them, (and definitely including the DECstation 3100) the same compilers, linker, assembler, calling conventions, object formats, etc, are used. As software developers know, fighting compiler problems/differences is often a worse problem than fighting UNIX differences, because people have often learned to parameterize UNIX variant differences, whereas it's nontrivial to work-around compiler problems, especially with good optimizers, whose bugs can be terrifyingly subtle. [Those of you who know may may have noticed the gray hairs I gained around 1986....] 5) It might have been nice to have gotten the VAXstation 3100 to appear with a big-endian, SYSV-based model. DEC had some perfectly reasonable reasons for going the other way, leading to having 2 ABIs for MIPS-based systems. Given that we (and our customers) were already committed in one direction, we weren't going to change. Given a chip that can go both ways, and compiler support that was also that way, do you REALLY think that we (MIPSco), knowing DEC was going little-endian, should have told them "Well, DEC, since you're going to go little-endian, and really weird, going to port Ultrix, we don't want you as a customer, so go away"??? I don't think this is shooting ourselves in the foot; everybody involved had good reasons to do what they did; maybe, in 1985, we'd have gone little-endian instead, if we expected to end up with DEC as a customer; for some bizarre reason, our business plan didn't count on that....:-) 6) EACH of these 2 ABIs is perfectly capable of gaining sufficient numbers to be interesting to 3rd-party vendors: a) Synthesis' numbers have gotten consdirable interest from 3rd-party folks, without counting DEC. b) I have no data on DEC's ability to attract 3rd-party SW to the 3100. I suspect it may be adequate... :-) About 20,000 MIPS chipsets have been shipped thru 1988, not counting whatever our chip partners have started shipping (as MIPSco phases out of that side of the business ). Now, that's NOTHING compared with the number of 68Ks or 386s, but it's ramping fast, and it is VERY significant in the RISC world, especially because most of those chips are in systems not built directly by MIPS, but by a large variety of other companies. (To answer rbradbur@oracle's comments) I'd note that the 88K is going to have to start showing up in real systems, in significant numbers, and pretty soon, or it isn't going to catch even 50% of the MIPS numbers for a long time.... Note that a lot of the ABI idea was derived from the mess that happened with 68Ks, where {compilers, linkers, assemblers, object code format, math libraries, and even FP-hardware} were different, whereas they're the same across multi-endian MIPS-based machines. 7) Given the commonality of software (remember, these 2 ABI's use a great deal of common software), many programs will port quite easily back and forth, because people won't be fighting surprises in the tools. Weirdly enough, it may even be easier to port from other systems. Anecdotal evidence is not evidence; nevertheless, just to pick a random example, I know of one significant package that ran on Sun-3s (and whose vendor, of course, I'm not allowed to name). It got ported to MIPS boxes about a year ago, and hadn't been gotten working on Sun-4s until about 6 months later, despite serious efforts to do so, starting months before the MIPS-port. I do not believe this is necessarily representative, for several reasons; nevertheless, it does show that one must be extremely careful in waving "source-compatibility" and ABI magic wands over everything and claiming that it's done... Summary: I wish there weren't Big & Little-endian, but they were here before I was in this business. I wish DEC had gone Big-Endian, but they had good reasons not to, and I'm pleased to have them as a customer. Even though the ends are different, I have reason to believe software will move especially easily back and forth, and as an old UNIXer, I'm happy about being able to move software around more machines. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086