file xfer problems (3B2/3B5/3B15 obj. compat.)

[Chris Donahue]

There is object code compatibility between the 3B2 families, the 3B5, and 3B15.
However, not in all cases because AT&T has released different compiler
versions.

Back in the beginning, the 3B2 was released with the first version of the C
compiler. AT&T told everyone when SVR2 came out (I am sure this is news
to some people though) - you will get source code
compatiblity always, but object code compatibility is not guaranteed beyond
SVR2. People were told that C Issue 2 a.outs would work when moving to the
next release of UNIX System V.
When C Issue 3 came out, AT&T followed through and old C Issue 1
a.outs don't work on SVR2.1 and SVR3 systems. (SVR3 was announced
for June 30 availibility this week at NCC). 
Also, when C Issue 3 came out you could no longer tag the compiler release
to the UNIX System release.

Now for the hardware floating point issues. C Issue 1 and 2 used an illegal
opcode trap to implement software floating point support. C Issue 3 uses
a function call library that will use the WE 32106 math coprocessor if
it is present, otherwise the software routine is used. C-FP+ inserts
MAU opcodes directly into the a.out's. So, C Issue 3 a.outs will run
on any 3B2, 3B5, or 3B15. However, C-FP+ a.outs only work on 3B2/310s,
3B2/400s equipped with the MAU, 3B5s equipped with the MAU, and any 3B15
(MAU standard).

The moral of the story is: applications compiled on a 3B2 or 3B5 or 3B15 will
run on the other machines if the correct compiler version was used that
matches the target machines hardware (in this case the presence or lack
of a MAU). Because - they all use the WE 32000 or WE 32100. Now, we
are talking about "applications" here. I am not referring to things like
drivers because they are more intimately related to the overal architecture
of the computer which does differ between the 3 classes of machines
mentioned here. SVR1 a.outs are out in the cold when it comes to SVR2.1
(I am pretty sure about this) and SVR3 (definitely sure about this).

Further clarifications are welcome because I tend to go through this often
with customers of AT&T and have experimented to make sure I am not speaking
with a forked tongue.

Chris Donahue
AT&T Info. Sys.
Application Engineering