Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!bionet!arisia!sgi!shinobu!odin!maddog!pkr
From: pkr@maddog.sgi.com (Phil Ronzone)
Newsgroups: comp.arch
Subject: Re: 68000 prehistory, was IBM PC prehistory
Message-ID: <2825@odin.SGI.COM>
Date: 15 Jan 90 21:08:58 GMT
References: <1990Jan12.042336.6123@esegue.segue.boston.ma.us> <9324@cbmvax.commodore.com>
Sender: news@odin.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 24

In article <9324@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>I really don't know what the AT&T ABI does.  But relocation, even if
>necessary, is a trivial thing to support in an object format.  The Amiga OS
>stores all objects in a quickly relocatable format, this works just fine. 
>It may not be traditional UNIX, but neither is binary compatibility between
>vendorrs at any level a traditional feature of UNIX. 

Relocation is NOT the issue. Segment address spacing is. If your
loader has been told that the distance (roundup) from data to bss is
64K, and you've been marked shared text, and you'd like to load
on a machine with a 128K segment boundary, all the relocation in the
world is not going to help you.

As for binary compatibility, it is more common that you know.

For example, NCR Towers executables will run on A/UX systems and even
on SUN-2's.



------Me and my dyslexic keyboard----------------------------------------------
Phil Ronzone   Manager Secure UNIX           pkr@sgi.COM   {decwrl,sun}!sgi!pkr
Silicon Graphics, Inc.               "I never vote, it only encourages 'em ..."
-----In honor of Minas, no spell checker was run on this posting---------------