andrew@frip.gwd.tek.com (Andrew Klossner) (01/18/89)
Paul Vixie ("If any of my words above are quoted, please include this
paragraph") said:
"Even if they had ABI's in mind, could they have agreed? Would
they have let OSF or MIPSCO mediate? Binding arbitration among
competitors? I'll believe it when I see it. I'd love to see
it, of course, but I'd be careful about threatening to hold my
breath until it happens.
"I applaud the 88000 people. It may well be the first
counter-example to what I asserted above about competitors
being polite to each other."
It happened with the 88k. A dozen or so competitors got together,
through membership in the "88k Consortium," and defined a "Binary
Compatibility Standard" which will become an ABI when AT&T says the
magic words. We have de-facto binary compatibility across the
architecture.
The result is a design-by-committee, with lots of compromises ... but
it's really sort of amazing that it happened at all. Motorola didn't
play a big role in the committee, either; three or four key OEMs (some
of whom have not publicly announced their role) provided the
leadership.
"So far the marketing (and an ABI is _marketing_, folks!) of
the 88000 has been fantastic."
An ABI is marketing in the same sense that a fast FPU is marketing. An
ABI is product engineering when you can buy shrink-wrapped 88k binaries
from a software vendor that don't specifically say "for the Frobozz
Magic Workstation" and install and run them. Several independent
software vendors (again, some of whom are unannounced) are preparing
88k ports.
"But the 88000 is not yet taking the world by storm, while the
MIPSCO chip _is_."
Perhaps the storm will happen when some 88k-based systems begin to
ship. (I hope!) In the meantime, I applaud the MIPS product; it's the
one to (try to) beat.
Disclaimer: I earn my salary these days from an 88k project, so I'm biased.
-=- Andrew Klossner (uunet!tektronix!hammer!frip!andrew) [UUCP]
(andrew%frip.gwd.tek.com@relay.cs.net) [ARPA]rpw3@amdcad.AMD.COM (Rob Warnock) (01/20/89)
An ABI for the Am29000 was an obvious "good thing" to AMD from the beginning,
having seen the massive incompatibilities that happened in, for example, the
68000 market.
Since it takes a while to get an AT&T-approved ABI, there is an interim
Binary Compatibility Standard which all the compiler and operating systems
vendors have agreed upon. It started with a Subroutine Calling Standard
(which was hard enough to get all the C compiler vendors to agree on,
much less Pascal, Ada, FORTRAN, and [*yecch*] COBOL, but they did), and
has evolved from there.
The BCS has assigned distinct trap numbers to various operating systems'
system calls so that, for instance, while it might not be possible to
run a "pure" System-V binary on a "pure" 4.3bsd kernel, it *is* possible
for a "dual-universe" kernel to run either a System-V or 4.3bsd binary.
(Note that I don't know of anybody doing a "dual universe" kernel for
the 29k, but it's allowed for in the BCS.)
The Am29000 BCS may not be perfect, but it's there, and the various
3rd-party vendors support it. You can link binaries from multiple
compilers into the same COFF file, for example. (And yes, AMD's
4.3bsd port uses COFF files...)
Rob Warnock
Systems Architecture Consultant
UUCP: {amdcad,fortune,sun}!redwood!rpw3
ATTmail: !rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403