Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!samsung!caen!uflorida!travis!hcx2.ssd.csd.harris.com!bill From: bill@hcx2.ssd.csd.harris.com (Bill Leonard) Newsgroups: comp.lang.fortran Subject: Re: F90 compiler from NAG Message-ID: <3794@travis.csd.harris.com> Date: 27 Jun 91 22:18:00 GMT References: <1991Jun24.211203.16291@cunixf.cc.columbia.edu> Sender: news@travis.csd.harris.com Reply-To: bill@hcx2.ssd.csd.harris.com (Bill Leonard) Distribution: comp Organization: Harris Computer Systems Division, Fort Lauderdale, FL Lines: 58 In article <1991Jun24.211203.16291@cunixf.cc.columbia.edu>, shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: > By your criterion, any "compiler" which first produces some intermediate > code -- perhaps shared by several language-specific front ends -- would be > not a compiler but a translator. This includes Convex's Fortran and C > products, I believe. But, you may object, the entire process taken together, > including what is unequivocally a "compilation" of the intermediate code into > assembler or machine language is certainly compilation; well, then, > the entire process of running the NAG "whatever-it-is", then doing > "whatever-you-call-it" to the resulting C program is also compilation. > And come to think about it, is a process which takes Fortran and produces > assembler a "compiler", by this definition? I guess not. These semantic games are not really very productive. The issue, I think, is the quality of the translation of the original FORTRAN source to the ultimate executable machine code. The distinction between "compiler" and "translator" is usually made to convey a general sense of this quality. You will almost certainly lose some of the original meaning when translating one high-level language to another, because they almost always have different semantics. As others have pointed out, one can translate FORTRAN into a very "low-level" C code, thereby minimizing the loss of original meaning. However, there is no doubt in my mind, having worked for years on highly-optimizing compilers for both languages, that translating FORTRAN to C is bound to be worse. (Someone, I forget who, pointed out that the C compiler may get better. True, but then a FORTRAN compiler using the same technology would still be ahead of the game.) Besides, I have seen no hard facts on whether the NAG translator uses such "low-level C" techniques or not. I believe that NAG's biggest weakness will be in debugging. I cannot imagine any way to translate FORTRAN COMMON and EQUIVALENCE constructs into C without using structures. Such a translation will "hide" the FORTRAN COMMON variables inside a C struct variable. Will the debugger know this? Probably not. Will the user know this? Well, he'll have to learn, but it won't be the same as debugging FORTRAN from a real FORTRAN compiler. > Why can't it be both a translator and a compiler? Well, we could call everything just "bread", but that would get awfully confusing! :-) > Except that one USUALLY thinks of a translator (as in APL or BASIC) as > something that executes lines one by one, without an intermediate > "compilation" stage. Now you're confusing "translator" with "interpreter". -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com --------------------------------------------------------------------------- "Chronologically gifted" -- new government term for "old". Does this make babies "chronologically deprived"? ---------------------------------------------------------------------------