johnl@esegue.segue.boston.ma.us (John R. Levine) (01/12/90)
In article <9308@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >The MMU is certainly a difference when it comes to implementing UNIX on a >680x0 system. But that's an OS concern, it shouldn't have anything to do >with an ABI standard. ... You'd hope so, but you'd be disappointed. Different MMUs have all made the code, data, and stack be addressed at different locations. Writing an ABI in which, for example, you don't know whether the data will start at the next 2K boundary after the text or the next 1MB boundary after the text is possible but difficult and messy; it forces you to do a lot of relocation at exec() time which Unix has not traditionally done. Since the advent of the 68030, its on-board MMU is the obvious place to standardize, but there's a lot of old 68000 crud out there already. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl "Now, we are all jelly doughnuts."
daveh@cbmvax.commodore.com (Dave Haynie) (01/13/90)
in article <1990Jan12.042336.6123@esegue.segue.boston.ma.us>, johnl@esegue.segue.boston.ma.us (John R. Levine) says: > In article <9308@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>The MMU is certainly a difference when it comes to implementing UNIX on a >>680x0 system. But that's an OS concern, it shouldn't have anything to do >>with an ABI standard. ... > Writing an ABI in which, for example, you don't know whether the data will start > at the next 2K boundary after the text or the next 1MB boundary after the text is > possible but difficult and messy; it forces you to do a lot of relocation at > exec() time which Unix has not traditionally done. 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. > Since the advent of the 68030, its on-board MMU is the obvious place to > standardize, but there's a lot of old 68000 crud out there already. You would certainly hope to support Sun-2s, Sun-3s, Apollo DN660s, whatever, as well as the newer 68030 compatible boxes. This sure seems to me a might simpler than supporting an ABI that gives you '286 compatibility under a segmented UNIX but still the proper memory paging under the '386 UNIX. I guess in either case, it points out that designing the ABI right is a primary concern. And may also be a good clue as to why the ABI for things without any installed base or other architectural hair, like 88000 machines, was done by AT&T before 680x0 or 80x86. > John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 > johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl > "Now, we are all jelly doughnuts." -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
pkr@maddog.sgi.com (Phil Ronzone) (01/16/90)
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---------------
peter@ficc.uu.net (Peter da Silva) (01/17/90)
> 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. Sure it is. Nobody says that the different segments of the program have to be relocated at a fixed distance. You can have as many chunks of code in the load module as you can stand, and load them anywhere, once you have relocation working. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
pkr@maddog.sgi.com (Phil Ronzone) (01/18/90)
In article <7S31O_3xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >> 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. > >Sure it is. Nobody says that the different segments of the program have >to be relocated at a fixed distance. You can have as many chunks of code >in the load module as you can stand, and load them anywhere, once you have >relocation working. You deleted the first line which said this was a cased of a shared text module. In a shared text module, the loader/linker MUST know the segment round-up size, because after the exec() the text seg is going to be read only. If your data is in there, it's going to be hard to write it ... ------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---------------