maine@altair.dfrf.nasa.gov (Richard Maine) (06/22/91)
I've been anxiously awaiting the latest issue of the Fortran Journal ever since Walt Brainerd posted a message here saying that it included an announcement of the first full F90 compiler. (Walt, you are a tease for not giving more details in the posting, but I understand and I forgive you :-)). Yesterday it finally arrived, so I can provide a little more detail for those here that don't subscribe. I do, by the way recommend subscribing to the Fortran Journal if you are interested in following such things. Walt regularly posts the subscription address here, so I won't bother to go look it up right now. The compiler is from NAG (Numerical Analysis Group) from the UK. Though I haven't yet got my hands on it, it does appear to be a real product instead of vaporware. I was half afraid of one of these "announcements" along the line of "company xxx announces the availability of product yyy to ber available sometime in the future maybe, that is if enough people show interest to convince us to really start design of it." I contacted NAG by phone (US number 708-971-2337, a UK number was also given, but I don't have my copy of the Journal handy right now). The person I talked to said that the product was in early beta now, with production shipment anticipated in 90-120 days. It "compiles" the full language F90 into C. There are no language extensions (but since F90 includes many of the common F77 extensions or equivalent functionality, this does not seem like a severe restriction). It also includes an F90 runtime library that in turn references C runtimes. The first release is for Unix systems. I only really asked about the SPARC 2 because that's what I want to test it out on. The SPARC is one of the systems supported by the first release, but I gathered there were also others. There are more details in the Fortran Journal and available from NAG. I'll avoid quoting specific prices here (call 'em yourself), but just comment that they seemed reasonable. I don't usually bother with explicit disclaimers but since this relates to a product announcement, I suppose I better make it perfectly clear to the lawyers and other mentally impaired types... I haven't even seen the compiler, so I'm in no position to make recommendations even if I were so inclined. This posting is purely to relay information. -- -- Richard Maine maine@altair.dfrf.nasa.gov
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (06/22/91)
In article <MAINE.91Jun21102248@altair.dfrf.nasa.gov> maine@altair.dfrf.nasa.gov (Richard Maine) writes: >I've been anxiously awaiting the latest issue of the Fortran Journal >ever since Walt Brainerd posted a message here saying that it included >an announcement of the first full F90 compiler. [...] >The compiler is from NAG (Numerical Analysis Group) from the UK. [...] >It "compiles" the full language F90 into C. I was quite eager to get my hands on the latest issue of the Fortran Journal for the same reason. Am I the only one who felt a little disappointed with this "compiler"? While I don't doubt that this product has its uses, I don't think I'd call it a compiler; it's a translator. At some point, I will have to involve a real C compiler in the process; at best that makes the F90 thing a preprocessor for C. That being the case, how will it communicate to the C compiler the optimizations which are uniquely available because of the peculiarities of F90? (I am not a compiler writer. If there are no such peculiarities, I withdraw my comment. However I'm quite certain that there must be some features of the two languages which allow different optimizations.) Nevertheless, I applaud NAG for getting this F90 thing out so quickly, whatever you call it. I'm sure that a lot of real compiler writers will find such an implementation invaluable in their efforts. Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
psmith@convex.com (Presley Smith) (06/24/91)
In article <1991Jun21.214012.5405@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >In article <MAINE.91Jun21102248@altair.dfrf.nasa.gov> >maine@altair.dfrf.nasa.gov (Richard Maine) writes: >>I've been anxiously awaiting the latest issue of the Fortran Journal >>ever since Walt Brainerd posted a message here saying that it included >>an announcement of the first full F90 compiler. >[...] >>The compiler is from NAG (Numerical Analysis Group) from the UK. >[...] >>It "compiles" the full language F90 into C. > > I was quite eager to get my hands on the latest issue of the >Fortran Journal for the same reason. Am I the only one who felt a >little disappointed with this "compiler"? While I don't doubt that this >product has its uses, I don't think I'd call it a compiler; it's a >translator. There is a standard definition available from ANSI as to what is a "compiler" and what is a "translator." The best way to sort out what to call the NAG product is for someone to find a copy of that document and put those definitions on the net. I looked, but sadly cannot find my copy. Maybe someone else can and would post a response? Thanks. Presley Smith psmith@convex.com
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (06/24/91)
In article <1991Jun21.214012.5405@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:
process; at best that makes the F90 thing a preprocessor for C. That being the
case, how will it communicate to the C compiler the optimizations which
are uniquely available because of the peculiarities of F90? (I am not a
Clearly one cannot communicate certain semantics through standard C.
However, it is theoretically possible to get much of the performance
via cooperation with the C compilation system (#pragma of various
sorts).
I suspect that if it is sucessful, it will get turned into a "normal"
compiler. In the meantime it should give folks a chance to learn the
new features of the language.
--
----------------------------------------------------------------
Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043levine@liege.ics.uci.edu (David Levine) (06/24/91)
Presley Smith writes: >There is a standard definition available from ANSI as to what is a >"compiler" and what is a "translator." The best way to sort out >what to call the NAG product is for someone to find a copy of that >document and put those definitions on the net. Unfortunately, ANSI/IEEE Std 729-1983 (IEEE Standard Glossary of Software Engineering Terminology) doesn't help much: compiler. A computer program used to compile.(ISO) Contrast with assembler, interpreter. compile. To translate a higher order language program into its relocatable or absolute machine code equivalent. Contrast with assemble, interpret. translator. A program that transforms a sequence of statements in one language into an equivalent sequence of statements in another language. See also assembler, compiler, interpreter. In general, I refer to a translator as a compiler if it does more than just textual substitution. For example, modern compilers are based on an analysis/synthesis process. It sounds to me like the NAG F90 product goes this route, and so I call it a compiler. -- David L. Levine, Dept. of ICS Internet: levine@ics.uci.edu University of California, Irvine BITNET: levine@ucivmsa Irvine, CA 92717 UUCP: ucbvax!ucivax!levine
psmith@convex.com (Presley Smith) (06/24/91)
In article <28660D45.4578@ics.uci.edu> levine@liege.ics.uci.edu (David Levine) writes: >Presley Smith writes: > >>There is a standard definition available from ANSI as to what is a >>"compiler" and what is a "translator." The best way to sort out >>what to call the NAG product is for someone to find a copy of that >>document and put those definitions on the net. > >Unfortunately, ANSI/IEEE Std 729-1983 (IEEE Standard Glossary of >Software Engineering Terminology) doesn't help much: > > compiler. A computer program used to compile.(ISO) Contrast with > assembler, interpreter. > > compile. To translate a higher order language program into its > relocatable or absolute machine code equivalent. Contrast with > assemble, interpret. > > translator. A program that transforms a sequence of statements > in one language into an equivalent sequence of statements in > another language. See also assembler, compiler, interpreter. > >In general, I refer to a translator as a compiler if it does more than >just textual substitution. For example, modern compilers are based on >an analysis/synthesis process. It sounds to me like the NAG F90 product >goes this route, and so I call it a compiler. Seens to me to be a translator. - Since a "compiler" is a "computer program used to compile" - AND the definition of "compile" is to "translate a higher order language program into it's relocatable or absolute machine code equivalent"... Since the NAG product produces C code as output, NOT relocatable or absolute machine code or equivalent... Then by this standard set of definitions it's NOT a compiler... It has transformed one high order language (Fortran 90) into another high order language (C). If it produces C code as output, that would fit with the definition of a translator. It tranforms a sequence of statements in one language (Fortran 90) into an equivalent sequence of statements in another language (C). If the NAG product is a compiler, then we need to change the standard definitions. In my mind, it's a translator. FYI. Presley psmith@convex.com
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (06/25/91)
In article <1991Jun24.163115.13507@convex.com> psmith@convex.com (Presley Smith) writes: >Seens to me to be a translator. > > - Since a "compiler" is a "computer program used to compile" > > - AND the definition of "compile" is to "translate a higher order > language program into it's relocatable or absolute machine code > equivalent"... > > Since the NAG product produces C code as output, NOT relocatable or > absolute machine code or equivalent... > ... > >If it produces C code as output, that would fit with the definition >of a translator... > >If the NAG product is a compiler, then we need to change the standard >definitions. In my mind, it's a translator. 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. Why can't it be both a translator and a compiler? 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. Come to think of it, if you increase the number of intermediate stages that the code has to go through, maybe it's really even more of a compiler, and less of a translator. Philosophically and psycho-semantically yours, -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixf.cc.columbia.edu(Internet) shenkin@cunixf(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***
psmith@convex.com (Presley Smith) (06/25/91)
In article <1991Jun24.211203.16291@cunixf.cc.columbia.edu> shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: >In article <1991Jun24.163115.13507@convex.com> psmith@convex.com (Presley Smith) writes: >>Seens to me to be a translator. >> >> - Since a "compiler" is a "computer program used to compile" >> >> - AND the definition of "compile" is to "translate a higher order >> language program into it's relocatable or absolute machine code >> equivalent"... >> >> Since the NAG product produces C code as output, NOT relocatable or >> absolute machine code or equivalent... >> >... >> >>If it produces C code as output, that would fit with the definition >>of a translator... >> >>If the NAG product is a compiler, then we need to change the standard >>definitions. In my mind, it's a translator. > >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. The CONVEX Compiler family does NOT produce an intermediate code at any time. In fact, the CONVEX compilers directly generate object code WITHOUT generating assembly code output and then invoking the assembler as many UNIX based compilers do. If you wish to produce an assembly code output from the CONVEX compilers, you must invoke the compile with a flag to request that output. Default is direct generation of a .o file without the assembler being invoked. Direct generation of the .o file makes the compilation process about 20% faster. I guess you could consider the NAG product a compiler with the output piped into another compiler? So, how do we define that type of "system" in standard terms? I didn't say in any of my postings that I agreed with the standard definitions of "compiler" or "translator." I said in a previous posting that maybe we should update the standard definitions. By the current standard definitions for "compiler" and "translator" I still maintain that the NAG product is a "translator." FYI. Presley psmith@convex.com
maine@altair.dfrf.nasa.gov (Richard Maine) (06/26/91)
On 24 Jun 91 14:24:26 GMT, khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) said: Keith> I suspect that if it is sucessful, it will get turned into a "normal" Keith> compiler. In the meantime it should give folks a chance to learn the Keith> new features of the language. Agreed. That's what you should expect out of a first release of a "processor" (be it a compiler, translator, or whatever) for a new language. I want something that works for now so I can do more code development and make sure that my understanding of the language agrees with that of a compiler. It would be nice if it was within a factor of 2 or 3 in speed to current f77 code, but I'll survive if it isn't. Anyone who really expects a first compiler for a new language to emerge full-blown with optimizations that illustrate its clear superiority over all other languages must be on some really strange drugs. Let us see something that works and works correctly before getting excited about optimization issues. It has yet to be demonstrated to me whether the NAG "compiler" works correctly to my satisfaction or not. I certainly plan to check it out though. On the compiler vs. translator question: I've long agreed with the position that C bears more relationship to a somewhat portable form of assembly language with fancy macros than it does to a higher level language like Fortran, which is more suitable to human consumption. So why make a big deal about the distinction of a "compiler" that puts out the C assembly language instead of those other machine-dependent things. :-) (Please note the smiley face. As with most attempts at humor, some elements of "truth" lie embedded, but don't take the above paragraph too seriously. Though I'm more at home with Fortran, I do use C and other languages when they seem more appropriate, which they sometimes do. On my PC clone at home, I probably use Turbo Pascal more than all the rest of the languages combined). -- -- Richard Maine maine@altair.dfrf.nasa.gov
orville@weyrich.UUCP (Orville R. Weyrich) (06/27/91)
In article <1991Jun24.211203.16291@cunixf.cc.columbia.edu> shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: >In article <1991Jun24.163115.13507@convex.com> psmith@convex.com (Presley Smith) writes: >>Seens to me to be a translator. >> >> - Since a "compiler" is a "computer program used to compile" >> >> - AND the definition of "compile" is to "translate a higher order >> language program into it's relocatable or absolute machine code >> equivalent"... >> >> Since the NAG product produces C code as output, NOT relocatable or >> absolute machine code or equivalent... >> >... >> >>If it produces C code as output, that would fit with the definition >>of a translator... >> >>If the NAG product is a compiler, then we need to change the standard >>definitions. In my mind, it's a translator. > >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. I guess an important question becomes the following: DOES NAG PROVIDE THE 'C --> machine code' PASS? If it does, then their SYSTEM is a COMPILER. If it doesn't, then they are providing only a TRANSLATOR pass of a compilation system which the user must put together. (I think that I know the answer -- its a TRANSLATOR! :-) -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
bill@hcx2.ssd.csd.harris.com (Bill Leonard) (06/28/91)
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"? ---------------------------------------------------------------------------