Should I convert FORTRAN code to C?

[Jerry Berkman]

In article <20008 at beta.UUCP> jlg at beta.UUCP (Jim Giles) writes:
>In article <2742 at utastro.UUCP>, rlr at utastro.UUCP (Randy Ricklefs) writes:
>> We will soon start porting software from a number of different sources to a
>> micro-processor-based UNIX system.  Most of the code is in various dialects
>> of FORTRAN.  The question that arises is whether to convert all this stuff
>> to a more modern language, particularly c.

>> 3) Is c a suitable replacement for FORTRAN in terms of mathematical capabil-
>> 	ities and portablility?


C is missing many useful intrinsics.  I have trouble taking a language
seriously for numeric computation if the language doesn't even know about
absolute values, e.g.:   x = abs(x);  or signed numbers,  e.g.  x = +5;
Both statements are illegal in C.  And what about:
	i = j**k
In C this becomes:
	i = pow( (double)j, (double)k);
For that matter, how do you translate  y = x**6 from FORTRAN to C?
Most FORTRAN compilers will optimize this using only 3 multiplies.
If you translate it to C as y = x*x*x*x*x*x, then there is a chance the
compiler will do as well as FORTRAN,  but I wouldn't bet on it.  And
if you use the translation y = pow(X,5.0), you have an out-of-line procedure
call plus an expensive evaluation.

Actually, C does not have a concept of intrinsic at all.  In the FORTRAN
statement:
	x = sqrt(y)
you are guaranteed by the standard that the square root intrinsic is
invoked (unless there is an external statement).  By contrast, the
C statement:
	x = sqrt(y);
does not guarantee anything of the kind.  A user defined function could
be called, or "sqrt" could be a define.  For sqrt(), this is not usually
a problem.  But I'd be a lot less sure of other names like acos or sinh.
For that matter, since sqrt() is a FORTRAN intrinsics, I get an error
message from any decent FORTRAN compiler for sqrt(integer).  None from C
of course (running lint is a hassle).

Also, I like the semantics of sqrt() under FORTRAN better:  on all
FORTRAN systems I have used, if y = -1., the result is a fatal error.
In C, it depends on what the library does.  I have used C libraries
which returned sqrt(abs(y)), others which return 0, and 4.3 BSD on a
VAX returns the reserved operand.

>On UNIX and UNIX-like systems, the Fortran support library is written
>almost entirely in C.

The 4.3 BSD math libraries for the VAX are written mostly in assembler.
That the 4.3 BSD VAX FORTRAN I/O library is written in C using standard
I/O may be why it is so slow.  The VAX math library is about as fast
as the VAX VMS math library while the BSD I/O library is up to 3 or 4
times as slow as the VAX VMS I/O library.

Much of the Cray UNICOS math and I/O support libraries are written in
assembler.

	- Jerry Berkman
	  Central Computing Services, U.C. Berkeley
	  jerry at violet.berkeley.edu