Fortran 77 parser
in [Fortran]
|
Prev: Vector Algebra Module
Next: Zero-size arrays
From: James Giles on 6 Apr 2008 15:25 Ron Shepard wrote: .... > I don't think COCO is supported by a single fortran vendor that I > use right now. [...] Isn't COCO written in Fortran? So, it's supported by all Fortran bendors (whether they know it or not), provided their compiler conforms sufficiently to the standard to support all the features of the language that the COCO source uses. When I write a preprocessor it's always written in the language that it generates! That way it's always supported. -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
From: Ron Shepard on 6 Apr 2008 15:41 In article <47f9161f$1(a)news.meer.net>, lindahl(a)pbm.com (Greg Lindahl) wrote: > In article <ron-shepard-913E66.12350406042008(a)comcast.dca.giganews.com>, > Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: > > > On the other hand, the C preprocessor is supported > > by every vendor that I know of. > > Yes, but you have to use a K&R preprocessor, for which there is no > standard. Yes, you have to worry about trigraphs and // comment stuff, and that is a couple of the ways that the preprocessor behaves differently on different platforms. But that is exactly what the standardization process would do, it would define exactly how the preprocessor should act, and eliminating these things that apply only to C source code and have nothing to do with fortran seems like a good thing to do (for fortran source code). > It's kinda hard to put a non-standardized thingie into a > standard. Yet, we have seen it done successfully time and time again. In this case, it is apparently "too hard" to do, so it will never be done. Consequently, programmers will continue to use the C preprocessor, just as they have for the past 25 years or so, without the benefit of standardization (which means that we must continue to worry about C trigraphs and // character sequences in our fortran code). $.02 -Ron Shepard
From: Walter Spector on 6 Apr 2008 16:43 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.) Beyond that, there were things like LAPACK and FFT libraries... None of that was a 'lock in'. > Cray wanted you to use REAL > declarations, in part, for the same reason, it helped to lock you in > to their business model. No, it was the 'natural' way to implement Fortran for the machine. 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. > 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. >> 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. W.
From: Ron Shepard on 6 Apr 2008 19:03 In article <WqydnbkxrqhIqGTanZ2dnUVZ_gGdnZ2d(a)earthlink.com>, Walter Spector <w6ws_xthisoutx(a)earthlink.net> 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
From: Greg Lindahl on 6 Apr 2008 22:34
In article <ron-shepard-0C68EC.14410206042008(a)comcast.dca.giganews.com>, Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: >In article <47f9161f$1(a)news.meer.net>, > lindahl(a)pbm.com (Greg Lindahl) wrote: >> Yes, but you have to use a K&R preprocessor, for which there is no >> standard. > >Yes, you have to worry about trigraphs and // comment stuff, That's not the issue. The issue is that ANSI C preprocesses C, it's not a straight text matcher. So, for example, if you have an unmatched quote inside of a Fortran comment, K&R preprocessing is not confused. ANSIC C preprocessing is. That's why you have to use the --traditional-cpp flag with gcc's cpp; that turns on K&R C preprocessing mode. m4 has a similar issue, if I recall correctly. -- greg |