conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (07/27/89)
Well, it looks like we'll be biting the bullet sooner than expected, and going from SR9.7 to SR10.1. I will be porting a system that employs Dialog, 2D GMR, Pascal, and FORTRAN, with the source code managed by a DSEE library. Could the port be a simple matter of recompiling on SR10 machines with SR10 compilers? Anyone with comments, suggestions, or sympathy? BTW, I know about Open-DIALOG, but need to port this way first; we may move to it next release. -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 -------------------
krowitz@RICHTER.MIT.EDU (David Krowitz) (07/28/89)
Fortan code will probably be ok. The default compiler optimization level (ie. if you do not supply a -OPT on the command line) seems to have changed from -OPT 1 to -OPT 3. Fortran I/O files have changed. If you create a formatted file (ie. ascii output), you will now get a file with a file-type of UNSTRUCT, rather than UASC. If you create an unformatted file (ie. binary data), you will get a file with a file-type of UASC, rather than REC. The Fortran I/O system is able to handle both the old SR9.7 files and the new SR10 ones (although how it distinguishes between an SR9.7 UASC file (containing ascii text) and an SR10 UASC file (containing binary data) is beyond me). There is a bonus in this ... the SR10 unformatted files seem to have the same record format as the files created by Sun, Alliant, and other machines which use IEEE format floating point numbers. The older REC files have to be run throught the sendrec and getrec programs available from the ADUS library before you can use them with a non-Apollo system. We have been able to copy unformatted Fortran data files between our Alliant and our SR10 Apollos with no conversion and we have been able to read the files with no problems. There is only 1 caveat: if you create a direct-access unformatted file and write a record which is smaller than the record size of the direct access file, the Apollos seem to pad the record with garbage and the Alliant and Sun-3 systems seem to pad the record with zeroes. Sequential-access files and direct-access files which have every record filled can be run through /bin/diff or /com/cmf with no problems. ... I just did a quick test ... our SR9.7 nodes seem to be able to read the unformatted Fortran I/O files created on the SR10 machines. 2-D GMR was changed between SR9.7 (where it was bundled with the OS) and SR10 (where it is now a seperate product). SR9 came with GMR version 1.0, SR10.1 comes with version 2.2 They are *not* compatible. The GMR metafiles format is different and the text handling and line style calls have been changed. About a half-dozen GMR calls relating to fonts, text, and line styles have been deleted and replaced by an "environment file" mechanism. There is a good chance that this will break your program since almost everyone uses some text and/or line style stuff in their GMR applications. I have not noticed anything new with the Pascal compiler to worry about. I can't say anything about DSEE and Dialog, as we don't use them here. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
mlm@calmasd.Prime.COM (Monte Meals) (07/28/89)
In article <44a922e3.14df5@ulsoy.engin.umich.edu>, conliffe@caen.engin.umich.edu (Darryl C. Conliffe) writes: > > Well, it looks like we'll be biting the bullet sooner than > expected, and going from SR9.7 to SR10.1. > ... Could the port be a simple matter of > recompiling on SR10 machines with SR10 compilers? I believe Apollo has a rather complete porting guide listing problem areas. Some of the problems include file path names and character case. Some of the tools (like the linker) are also different and can present problems. Monte