ABIs and the futurrrr of UNIX(tm)

[964[jak]-Robert Halloran]

In article <431 at micropen> dave at micropen (David F. Carlson) writes:
>There has been much UNIX news recently on the subject of ABI (Application Binary
>Interface) standard which AT&T along with Motorola, SUN and Intel are setting.
>If I understand the problem, as it is now each UNIX vendor for any machine
>they sell UNIX for is responsible for defining a binary protocol for things such
>as alignment (and/or packing), traps to kernel with associated arguments, etc.

>I believe what we all seek is a means of portability across machines lines
>without having to support N-machines to sell a product.  Parts of this are in
>place:  COFF has conversion routines for correctly ordering big-endian vs. 
>little-endian data sections.  Why can't a machine independent intermediate
>form be developed for UNIX solely to be translated into native binary on the
>target machine by a similar utility?  This form would have to be opaque 
>enough to discourage un-compiling but adaptable enough to allow for tight 
>native translation on any SystemV (and eventually POSIX) machine.  Perhaps
>a meta-assembler language such as the DoD CORE set as a possible portable 
>target code for PCC.  Or perhaps even some intermediate PCC form that a code
>generator fixes on the target.  The form should not preclude typical machine 
>dependent optimizations and data packing.

It was my understanding that the idea of an ABI was that applications
for a SPECIFIC processor family, i.e. SPARC, '386, 68030, etc. would
be binary-compatible, to avoid the current problem where '286 Xenix
binaries won't run on a '286 system running Microport, a 68xxx binary
for the NCR Tower doesn't run on the <fill in some other 68K-based
Unix box>.  I'm using these only as examples; the idea is that application
vendors would only have to write ONE version for a given type of CPU
and have that run on any Unix box that uses that CPU.  I do NOT believe
that the idea is to have some 'intermediate-code' standard to be interpreted
on the various processor families.

(Any company names mentioned up above are purely for illustration;
 no flames about beating up on brand X, please.)

						Bob Halloran
=========================================================================
UUCP: {ATT-ACC, rutgers}!mtune!rkh		DDD: (201)251-7514 
Internet: rkh at mtune.ATT.COM			       evenings ET
USPS: 19 Culver Ct, Old Bridge NJ 08857
Disclaimer: These opinions are solely MINE; any correlation with AT&T
	policies or positions is coincidental and unintentional.
Quote: "There were incidents & accidents, there were hints & allegations"
		-- Paul Simon
=========================================================================