Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!apple!amdcad!rpw3 From: rpw3@amdcad.AMD.COM (Rob Warnock) Newsgroups: comp.arch Subject: Re: ABIs for new chips (was Re: DECstation 3100 info.) Message-ID: <24131@amdcad.AMD.COM> Date: 20 Jan 89 08:34:07 GMT References: <558@oracle.UUCP> <10887@tekecs.TEK.COM> Reply-To: rpw3@amdcad.UUCP (Rob Warnock) Organization: [Consultant] San Mateo, CA Lines: 31 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