🚀 go-pugleaf

In article <1992Dec21.221221.10027@sifon.cc.mcgill.ca>  
brit@wagner.Physics.McGill.CA (Dave Britton) writes:
> I have had a fair amount of trouble with the absoft compiler, including
> finding one bug that they blame on the 68040 chip. On the other hand
> I have had no problems with f2c (available free on ftp sites) AND
> programs tend to run quicker if I use f2c rather than the absoft
> compiler. 
> The absoft compiler is certainly fine for simple fortran but if
> (like me) you have 300 subroutines of ancient fortran using all
> sorts of dubious constructs, then forget it. For example, if you
> have a subroutine that has entry points that allow an alternative
> return code (ENTRY MYENTRY(A,*) syntax) then the subroutine itself
> must be declared MYSUBROUTINE(...,*) even if the main subroutine 
> does not use alternate returns. Similarly, absoft compiler is
> annoyingly picky about where data statements can appear ( having
> to change several hundred routines to fix this was also a pain).
> 
> Dave.

Here is another point-of-view for the absoft compiler:
I've ported over 20,000 lines of FORTRAN 77 code from the Apollo workstations  
to the NeXT with the absoft compiler. The software has FORTRAN 66 and FORTRAN  
77 statements plus Apollo specific language extensions.  The software contained  
graphics, system calls, printing, formatted and unformatted i/o, fault  
handlers, and complex data structures.  Note: my software did not jump around  
like a jack rabbit using entry statements, only goto's, so I have no knowledge  
of entry statement problems.

The only problems encountered were with FORTRAN 77 extensions, like intrinsics  
functions and i/o statements, that the Apollo used to extend the language.   
However, the absoft compiler did support a large set of the extensions so the  
changes were few.  (Digital Librarian made the changes painless.)  The code  
ported in less than a day, after having spent weeks porting system calls, fault  
handlers, and graphics.

The absoft compiler supported all the necessary compiler flags to make the NeXT  
software 100% compatible with the Apollo version.  I never had a problem with  
the FORTRAN language interpretation made by the absoft compiler.  In fact, my  
FORTRAN 77 code on the absoft compiler ports without problems to Sun's,  
Apollo's, and RS-6000's.  Problems occur only when I write with FORTRAN  
extensions.

The biggest problem was that I could not catch FPU faults.  The problem, told  
by absoft, was with NeXT OS, not absoft which I agree.  I've also been told  
that it's been fixed in NS3.0, although I have not had a chance to test it.   
Another problem was in their 040 code generation (-N40) which absoft fixed in  
their v3.2 compiler.  I never experienced the problem but switched to a safer  
code generation switch (-N53) when I heard this.  The performance of the  
software is good IMHO.

I don't have any performance comparisons between f2c and absoft but maybe  
someone would like to post their results.  I have some compute intensive finite  
difference code to make a comparison with if anyone is interested.

	- Tim -
--
Tim Pugh
College of Oceanic and Atmospheric Sciences
Oregon State University
tpugh@oce.orst.edu