NOT Educating FORTRAN programmers to use C

[Sean Fagan]

In article <14191 at lambda.UUCP> jlg at lambda.UUCP (Jim Giles) writes:
>The truth is, any machine which has registers to schedule,
>program control over cache management, pipelining, or vectors
>can be effected by aliasing.  The severity of the effect depends
>on the program.

And some compilers do a remarkebly good job at coping with this.  However,
yeah, you're right:  there are some constructs in C which cannot be
optimized very well, if at all.  However, let's pose this question to you:
when was the last time you tried to write an OS in FORTRAN?  There are, of
course, dozens written in C, but very few written in FORTRAN.  In that
respect, C is a *much* more powerful language than FORTRAN.

>> The standard allows str*() to be built-in.
>Most ANSI standards allow additional features to be implemented in
>a conforming processor.  I don't consider these extensions to be
>an inherent part of the language.  

So, you don't consider PRINT, READ, WRITE, COS, SIN, etc., to be parts of
FORTRAN?  Well, uhm, gosh, if they're *not*, then C compilers tend to
generate better code, from my experience.

FORTRAN has some advantages, optimization-wise, over C:  no pointers, hence
no aliasing, and, well, I guess that's the major one.  The language is much
older than C, so most of the compilers are more "mature" than C compilers.

However, C has at least one advantage, optimization-wise, over FORTRAN (at
least, as I understand FORTRAN, and as I understand how things have been
implemented):  a C "module" does not consist of one routine per file.  This
lets inline functions, global optimization and analysis, etc., be used,
which you can't do easily in FORTRAN.  (N.B.:  I could be wrong.  However,
all instances of optimizing FORTRAN compilers I've seen [CDC Cyber and Cray
machines {this has been a Seymour-plug}], would treat each routine as it's
own file, and I've been under the impression that this was required.)

-- 
Sean Eric Fagan  | "If a compiler emits correct code purely by divine guidance
seanf at sco.COM    |  and has no memory at all, it can still be a C compiler."
(408) 458-1422   |           -- Chris Torek (chris at cs.umd.edu)
-----------------+ Any opinions expressed are my own, not my employers'.