bzs@bu-cs.UUCP (Barry Shein) (06/18/86)
From: dave@uwmcsd1.UUCP (Dave Rasmussen) ... >Since they don't have compilers but are connected to my host system >via a uucp link, I'd like to be able to compile code on a friend's >3B5, mail the uuencoded binary to the remote 3B2, and do a uudecode >and have a useable program. > >My problem is that programs transfer fine on 'dump' type floppies, >which is how I transfered uudecode to the remote system. Trouble >is, uudecode mungs new uuencoded files. Are you sure 3B5 a.out's run on a 3B2, I'm not. I think we had troubles with this here at B.U. tho fortunately we had the compilers on both systems (just for starters, are you sure they use the same link libraries? same SYSV version down to the 12th digit? what about floating point emulations? I dunno, just didn't work here.) I would suggest people not guess about this, anyone in authority want to say what is *promised* or known? My answer is no, it doesn't in general work nor was it promised to (tho it seems like it should.) -Barry Shein, Boston University
cwd@cuae2.UUCP (Chris Donahue) (06/19/86)
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
barber@rabbit1.UUCP (06/24/86)
I'm not an authority, but the 3b5 run files I've tried to run
on a 3b2/300 work just fine. Haven't tried anything with floating
point however, so I can't vouch for that. The System V releases
of these programs were not necessarily in sync: some were, some
definitely weren't.
--
-------------------------------------------------------------
Steve Barber Rabbit Software Corp.
...!ihnp4!{cbmvax,cuuxb}!hutch!barber ...!psuvax1!burdvax!hutch!barber
(215) 647-0440 1 Great Valley Parkway East Malvern PA 19355