Re: Fortran 77 parser

In article <WqydnbkxrqhIqGTanZ2dnUVZ_gGdnZ2d@xxxxxxxxxxxxx>,
Walter Spector <w6ws_xthisoutx@xxxxxxxxxxxxx> wrote:

Ron Shepard wrote:
... For example, Cray
compilers also supported a few dozen oddball intrinsic functions
that no other vendor supported. The more your code relied on those
intrinsic functions, the more your code was locked in to using Cray
compilers and Cray hardware.

There were a 'few', maybe. But a 'few dozen'? The CVMGx
functions let you vectorize loops with conditional code in it,
before the compiler was smart enough to do it on its own.
(And the F90 MERGE intrinsic is very comparable to the CVMG
stuff.)

Didn't Cray roll its own bit operators rather than using the MILSTD
ones? And they supported several pack and unpack routines of
various kinds (different integer widths, and there were floating
point versions too I think, although I tried to avoid using them).

Beyond that, there were things like LAPACK and FFT
libraries... None of that was a 'lock in'.

I don't think I used LAPACK for much until the mid 90's, but before
that Cray had its own math library (SCILIB I think it was called,
and there was also the Boeing library which was popular on Crays).
I was using EISPAK and LINPACK before LAPACK at an attempt for
portability, but I don't remember Cray including those routines, I
remember that they had their own routines to do the same things.
And instead of supporting the BLAS at the compiler level (which I
think every vendor should have been doing for the past 30 years),
they had their own low-level routines (MXM, MXMA, etc.).

As I said previously, this was not unusual at the time, every vendor
did this to try to lock in their customers and make it more
difficult to write efficient portable code. Now, everyone knows to
use DGEMM() for fast matrix-matrix products, but that was not the
case in the 80's (and ignoring the fact that it was SGEMM that you
would want on the Cray anyway). But in the 80's if you wanted a fast
matrix-matrix product, every vendor had their own way of doing it.

Even today, most compilers do not use the fast DGEMM() code for the
intrinsic MATMUL() function, even when the compiler vendors
distribute the BLAS library along with the compiler, but that is a
second-order tangent to this thread.

Crays main interest was that folks write clean DO loops that the
compiler could then auto-vectorize. A good idea on any machine.
(Similar idioms allow the compiler to safely unroll and software
pipeline loops on scalar processors.) There was really very little
non-Standard syntax needed to achieve this goal. Given a good
compiler, of course.

Well, "clean" code and a bunch of compiler directives. And, of
course, those compiler directives were nonstandard too, the vendors
never seemed to agree on the exact syntax or the exact semantics. I
still have those compiler directives in my codes now, even though it
has been 15 years since I've used a Cray-1, XMP, or YMP machine.

Other vendors in the late 70's and 80's
did this too, of course, with language features and library
routines, it was standard practice.

Other vendors were *far* worse than Cray.

I agree they all did it, but I don't know that Cray did it any less.
By the time you include the compiler extensions, the library
routines, the compiler directives, the blas and linpack D/S
conversions, the standard-but-nonportable REAL declarations into
your code, and using the right D/E exponents in all of the floating
point constants, it would take you quite some effort to move
anything nontrivial to a different machine.

There is always COCO... Dan Nagles extended version (which
has some additional text substitution capabilities) works
rather well.

I don't think COCO is supported by a single fortran vendor that I
use right now.

Doesn't matter. Dans code is publicly available and written in
Standard Fortran-95 (+ the command line argument calls from F2003.)
It compiles on just about anything modern with nearly zero lines
of code changes.

I don't disagree, but that still misses the points that the fortran
committee has refused to standardize what has really been the de
facto standard preprocessor for the past 25 years, the one that is
supported (in its nonstandard form) by every fortran vendor that I
know of, and that none of those vendors support the new COCO
preprocessor (e.g. automatically invoke COCO on the source code, and
allow you to run the debugger based on your original source code).
Through most of the 80's I maintained my own preprocessor too
(before COCO), written in fortran, so I know that such a thing is
possible, but maintaining your own personal set of tools only solves
part of the problem with writing and maintaining portable code
within the entire programming community.

$.02 -Ron Shepard
.