The customers have a large application already running under many UNIX
platforms. The source to be ported is System V running on an AT&T 3B1. They
have compiled very large object libraries which they would also like to port as
object code rather than re-compile. The processor in the 3B1 is a 68010 and
the customers were under the impression that object code for the 68010 would
run under the 68020.
They tried compiling some of their own code and linking to an object library
transferred from the 3B1, but the attempt failed. The attempt to transfer some
standard C object code without non-standard library calls also failed. When
they compiled the same C source code under A/UX, they noticed that the size of
the object code was much larger under A/UX.
The following discusses the issues involved:
In theory, one could have 68010 object codes run under 68020, because 68020
machine instructions set is a super set of 68010. But with different
architectures and/or operating systems (like the AT&T 3B1 and Macintosh II
A/UX), you can't move object code to another CPU even though both are running
System V (The current release A/UX is based on System V Release 2). Some
factors that might affect the upward compatibility between 3B1's Sys V and A/UX
are:
- The data structure of systems calls might be different.
- The method of subroutine parameters parsing might be different.
- The stack addressing manipulation might be different.
- The internal registers usage might be different.
- The specific hard memory management unit (PMMU in Macintosh II A/UX
might have a different approach to memory management.
The reason that the same C source code compiled under A/UX resulted in larger
object code (assuming it is absolute executable code) than that which the 3B1
produced is that the 3B1 System V might run with shared library and A/UX does
not have shared library. (A/UX 3.0 has shared libraries)
A/UX supports 4.2BSD-style signals and 4.2BSD-style networking system calls.
It also supports the STREAMS feature which is normally available only with
System V.3. Therefore, the library routines will not be identical with other
System V software.
These are the reasons why directly porting 3B1 68010 object code to A/UX does
not work without under A/UX without re-compiling.