🚀 go-pugleaf

In article <558@oracle.UUCP> rbradbur@oracle.UUCP (Robert Bradbury) writes:
>In article <VIXIE.89Jan14123901@bacchus.pa.dec.com> 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: <generic disclaimer, I speak for me only, etc>
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