cpcahil@virtech.uucp (Conor P. Cahill) (10/18/90)
I am trying to tally which fortran compilers provide a compatibility
with the fortran compiler delivered with masscomp systems (which is reputed
to provide compatibility with the AT&T compiler).
The problem area is that if we open a file with a record length of 1 the
at&t compiler then will read as much data as necessary to solve the
read argument list.
If you have the time (it only takes a couple of minutes) pleas run the
attached test & email the results to me. I will post a summary if
desired.
I have run the test on the following compilers:
HP/UX f77, NDP Fortran, and LPI Fortran
All of which failed.
Thanks in advance.
(To run the test, unshar the rest of this posting and run "runtest.sh")
#!/bin/sh
# This is a shell archive (shar 3.21)
# made 10/12/1990 18:51 UTC by cpcahil@virtech
#
# existing files WILL be overwritten
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 425 -rw-r--r-- testio.f
# 306 -rwxr-xr-x runtest.sh
#
if touch 2>&1 | fgrep '[-amc]' > /dev/null
then TOUCH=touch
else TOUCH=true
fi
# ============= testio.f ==============
echo "x - extracting testio.f (Text)"
sed 's/^X//' << 'SHAR_EOF' > testio.f &&
X CHARACTER STRING*8,FNAME*12
X FNAME='wada'
X OPEN(1,FILE=FNAME,RECL=1,ACCESS='direct',FORM='unformatted')
X NREC=1
X READ(1,REC=NREC)STRING
X IF(STRING.EQ.'!<ARCH>\n')THEN
X WRITE(6,100)FNAME,STRING
X ELSE
X WRITE(6,101)FNAME,STRING
X ENDIF
X STOP
X 100 FORMAT(' FILE=',A12,' is an archive; STRING=',A8)
X 101 FORMAT(' FILE=',A12,' is not an archive; STRING=',A8)
X END
SHAR_EOF
$TOUCH -am 1012143690 testio.f &&
chmod 0644 testio.f ||
echo "restore of testio.f failed"
set `wc -c testio.f`;Wc_c=$1
if test "$Wc_c" != "425"; then
echo original size 425, current size $Wc_c
fi
# ============= runtest.sh ==============
echo "x - extracting runtest.sh (Text)"
sed 's/^X//' << 'SHAR_EOF' > runtest.sh &&
X
X#
X# compile the program
X#
Xf77 testio.f -o testio
X
X#
X# generate data file to be read
X#
Xecho banana > junk
Xar r wada junk
X
X#
X# run the test
X#
Xresult="`./testio | grep 'is an'`"
X
Xif [ ! -z "$result" ]; then
X echo TEST was successful
Xelse
X echo TEST failed
Xfi
X
X#
X# clean up
X#
Xrm -f junk wada testio.o testio
X
SHAR_EOF
$TOUCH -am 1012145190 runtest.sh &&
chmod 0755 runtest.sh ||
echo "restore of runtest.sh failed"
set `wc -c runtest.sh`;Wc_c=$1
if test "$Wc_c" != "306"; then
echo original size 306, current size $Wc_c
fi
exit 0
--
Conor P. Cahill (703)430-9247 Virtual Technologies, Inc.,
uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160
Sterling, VA 22170 ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) (10/19/90)
It doesn't work (it's doesn't even get started) on my VMS system. Maybe you made a few too many assumptions? -- Tom O'Toole - ecf_stbo@jhuvms.bitnet - JHUVMS system programmer Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 ease!Trim!eeeaaaassse!trimtrimtrimeeeeeeaaaaassetrimease!trim!ease!trimeaase
cpcahil@virtech.uucp (Conor P. Cahill) (10/19/90)
In article <6662@jhunix.HCF.JHU.EDU> ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) writes: >It doesn't work (it's doesn't even get started) on my >VMS system. Maybe you made a few too many assumptions? I didn't make any assumptions. This tests an extension to fortran that was added by AT&T (this is from a second hand source, so I may have it wrong). The reason for the test is my client has a big simulation software package that he created on a masscomp system that makes use of this little feature. We are looking for another compiler that has the same "feature" so we can upgrade his system. Results so far: Sun Failed Cray Failed Ultrix 4.0 Failed MIPS RC6280 Failed Looks like someone is going to have to do alot of recoding. (Let this be an example of why you shouldn't use compiler-specific extensions) -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) (10/19/90)
I think you made the assumption that a computer is a box of electronic components that runs the unix operating system. -- Tom O'Toole - ecf_stbo@jhuvms.bitnet - JHUVMS system programmer Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 ease!Trim!eeeaaaassse!trimtrimtrimeeeeeeaaaaassetrimease!trim!ease!trimeaase
doug@jhunix.HCF.JHU.EDU (Douglas W O'neal) (10/19/90)
In article <1990Oct19.012745.7875@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <6662@jhunix.HCF.JHU.EDU> ereiamjh@jhunix.HCF.JHU.EDU (Tom B. O'Toole) writes: ->>It doesn't work (it's doesn't even get started) on my ->>VMS system. Maybe you made a few too many assumptions? -> ->I didn't make any assumptions. This tests an extension to fortran that was ->added by AT&T (this is from a second hand source, so I may have it wrong). -> I think that you want the code to run on a UN*X box. You have not said so, but posting a shell archive and using commands such as touch seem to indicate such. Extensions common to various platforms can be tested, but your posting *assumed* that we would run under some flavor of UN*X. -- Doug O'Neal, Distributed Systems Programmer, Johns Hopkins University doug@jhuvms.bitnet, doug@jhuvms.hcf.jhu.edu, mimsy!aplcen!jhunix!doug Like many of the features of UNIX, UUCP appears theoretically unworkable... - DEC Professional, April 1990
andyo@glasperl.masscomp (Andy Oram) (10/19/90)
I've been communicating with Conor P. Cahill through e-mail, but since people
are interested in the test for reading a stream bytes, I'll post this version
I just did (it's different from what I sent you, Conor).
I'm not tuned in to every variation in FORTRAN's and OS's, but I think that
the following are the only system-dependent things that I know the program
depends on (besides, of course, the extension you're trying to test):
1. The program assumes that direct-access, unformatted files contain
exactly the data that the program writes to them -- no extra record
delimiters, etc. On UNIX systems I think this is a fair
assumption, since the original f77 compiler was based on it. If
it's not true, the whole notion of file as byte stream breaks down
anyway.
2. A character is one byte. If anybody thinks THIS assumption is
unsafe, let them suggest another standard data type that's more
reliable.
(My background is that I wrote the latest few versions of MASSCOMP's Fortran
manual.)
CHARACTER*8 STRING
INTEGER IERR
OPEN(1,RECL=8,ACCESS='DIRECT',FORM='UNFORMATTED',STATUS='NEW')
WRITE(1,REC=1)'SPQRSPQR'
CLOSE(1)
C
OPEN(1,RECL=1,ACCESS='DIRECT',FORM='UNFORMATTED')
READ(1,REC=1,IOSTAT=IERR)STRING
IF(IERR .NE. 0)THEN
WRITE(6,1000)IERR
ELSEIF(STRING.EQ.'SPQRSPQR')THEN
WRITE(6,1001)STRING
ELSE
WRITE(6,1002)STRING
ENDIF
1000 FORMAT(1X,'ERROR: ',I5)
1001 FORMAT(1X,'OK -- GOT ',A8)
1002 FORMAT(1X,'NOT OK -- GOT ',A8)
STOP
END
-------------------------------------------------------------------------------
Andrew Oram Concurrent Computer Corporation
(I don't represent Concurrent; this message represents my own opinion)
Digital Communications Route: andyo@westford.ccur.com
{harvard,uunet,petsd}!masscomp!andyo
Analog Communications Route: (508) 392-2865
Automatic UN*X documentation utility:
cref | compress | crypt | man
-------------------------------------------------------------------------------dik@cwi.nl (Dik T. Winter) (10/20/90)
In article <6671@jhunix.HCF.JHU.EDU> doug@jhunix.HCF.JHU.EDU (Douglas W O'neal) writes: > I think that you want the code to run on a UN*X box. You have not said so, > but posting a shell archive and using commands such as touch seem to indicate > such. Extensions common to various platforms can be tested, but your posting > *assumed* that we would run under some flavor of UN*X. Not only the assumption was a UN*X box, but also some special UN*X box. Not all fortran compilers are called 'f77'; I have seen 'fortran', 'fort', 'fc', 'cft' to name but a few. However, here are the results from an Alliant FX/4 running Concentrix (and the compiler is called 'fortran'): FORTRAN ERROR on Unit 1 FORTRAN ERROR in line 5 of testio.f: E_READ_RECORDTOOSMALL Cannot read a record larger than the RECORDSIZE value specified in the OPEN statement TEST failed -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
bill@ssd.csd.harris.com (Bill Leonard) (10/23/90)
In article <1990Oct18.160412.8187@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
I am trying to tally which fortran compilers provide a compatibility
with the fortran compiler delivered with masscomp systems (which is reputed
to provide compatibility with the AT&T compiler).
The problem area is that if we open a file with a record length of 1 the
at&t compiler then will read as much data as necessary to solve the
read argument list.
If you have the time (it only takes a couple of minutes) pleas run the
attached test & email the results to me. I will post a summary if
desired.
I ran this test using the f77 compiler we got from AT&T, and it failed, so
I question whether that is an "AT&T compatibility" feature. When I run the
program by hand, it prints out an error message complaining about premature
end-of-file (my interpretation of the obscure message it really produced),
and then aborts.
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.com
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.combill@ssd.csd.harris.com (Bill Leonard) (10/23/90)
In article <1990Oct19.012745.7875@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
Looks like someone is going to have to do alot of recoding. (Let this
be an example of why you shouldn't use compiler-specific extensions)
Grrrrrr, I really get irritated when I hear this statement. First, if no
one used vendor extensions, ever, then the only way you would ever get new
language features is either with a brand-new language or by having some
committee (like X3J3) design it for you without any idea of how well it
will work or serve the intended purpose. Vendor extensions give the
marketplace (i.e., the users) a chance to decide what features they like
and which one they don't.
Having said that, I would certainly advise a user not to use a vendor
extension IF: a) other vendors in that segment of the market do not offer
the same or at least similar extension, or b) the user does not have
sufficient "clout" to force the next vendor to implement the same
extension. It is not necessary that EVERY vendor support an extension
unless you really plan to buy systems from every one of them (which is
highly unlikely). If, for instance, your systems are primarily doing
accounting and payroll tasks, you are unlikely to buy systems from
a real-time vendor.
I've observed that certain market segments make unique demands on
programming languages, and vendors that are leaders in each segment usually
implement about the same set of extensions. In fact, the vendor that does
not implement the extensions that are popular with users in his market
quickly finds himself losing business to those that do. Therefore, you are
usually pretty safe in using those extensions.
Where you will get in trouble, though, is using an extension that is not
specific to a particular market and/or is not widely implemented. However,
if the extension is the only (convenient) way to get the job done, then you
have the uncomfortable choice of either writing non-standard code or using
some other equally onerous solution. If you happen to be a large corporate
user that buys millions of dollars worth of machines each year, probably
you can "persuade" other vendors to implement your extension; otherwise,
you have to either hope other users will like and promote it, or that you
won't have to change vendors for awhile. :-)
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.comrsb@makro.nhh.no (Roger S Bivand) (10/23/90)
A short comment on the original test program: both AT&T and BSD "ar" denote their archives with lower case "arch", so the test could never have worked. Altering the case leaves an AT&T f77 succeeding, and Mips f77 failing. Insight is available from f2c, that is the original source for AT&T f77 in essence. The converted c program compiles and runs passing the test. In the Bell Labs CS Tech Report #149 of 8/2/90 (on research.att.com), the authors state "When using a machine whose vendor provides but has gratuitously changed _libF77_ or _libI77_, one cannot safely mix objects compiled from the C produced by f2c with objects compiled with the vendor's Fortran compiler, and one must use the correct libraries with programs translated by f2c" (p. 14). A conclusion is then that by compiling via f2c and its libraries, emulation of classical AT&T f77 behaviour may be possible. For the same reason, programs targeted on machines not running Unix may also be rendered portable by using f2c as a precompiler, and the lib[IF]77 in the f2c release as the necessary libraries. There may on the other hand be a slight efficiency loss, less I feel than the "recoding thousands of lines of source" complaint. Roger Bivand Institute of Geography Norwegian School of Economics and Business Administration Bergen, Norway rsb@czech.nhh.no