Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!lll-winken!aunro!alberta!mts.ucs.UAlberta.CA!Al_Dunbar From: userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) Newsgroups: comp.lang.fortran Subject: Re: NAG Fortran 90 announcement Message-ID: Date: 26 Jun 91 04:40:21 GMT References: <15634@exodus.Eng.Sun.COM> <26334@lanl.gov> Organization: MTS Univ of Alberta Lines: 67 In article , przemek@rrdstrad.nist.gov (Przemek Klosowski) writes: > >>>>>> On 24 Jun 91 16:31:36 GMT, jlg@cochiti.lanl.gov (Jim Giles) said: > >Jim> The thing that's most disappointing about NAG's implementation is that >Jim> it's a preprocessor to C. (They claim that it's a compiler because it >Jim> does "global" (throughout a whole program unit) analysis, but it still >Jim> outputs C as it's "object" code.) This means that those users who are >Jim> the most anxious to try out the 'whole array' notation will get an very >Jim> unsatisfactory comparison because of the pessimizing effect of C on >Jim> array (in C: pointers) calculations. > >I understand that Jim is known for his dislike of UNIX and C, so I suppose >that I shouldn't be surprised by his criticism. However, I have to object to >his claim that C is pessimizing the array calculations. Au contraire, it is >well known that some of the optimizations used to treat multidimensional >arrays in Fortran are much easier expressed in C---strength reduction in >index calculations, for example, is naturally expressed in C by having a >pointer to the column (row in C, actually). As far as I can tell, Fortran >could only do it by static (compile time) equivalence. I have a few problems with a Fortran "compiler" that produces "C" code (or BASIC, or ADA, or ...): 1) experience. Once used a 68000 box (WICAT) with a Fortran of this sort. List directed input of "-9.4" resulted in a value of "-8.6", or "-9" plus ".4". Some precision problems (forget the details). 2) philosophy: I believe (but cannot prove) that the extra translation step will impose non-Fortran-like limits or problems Conversely, that compile time may go up in order to produce a functionally equivalent "C" program, which still must be compiled. Something is always lost in translation, at least in natural languages. Would those Korean assembly instructions be any more intelligible if first translated through French and Latin? 3) support: whose "C" compiler would be used? Hopefully the vendors, and it would be invoked without the user needing to realize it. This means: no "C" related compiler error messages, runtime error messages, or listing messages; availability of Fortran symbols for debugging; no necessity to understand "C" to either use the compiler or generate efficient code with it; and finally, NO phone support operator telling callers that they should switch to "C", and NO $surcharge for purchasing the "C" compiler. No, I'm not "C" bashing. I wouldn't mind being proven wrong, but fail to see the advantage of doing it this way. Once it has been done, of course, it *might* be the best Fortran Compiler choice; I just don't think so. Speaking of language bashing, one of the manuals with the WICAT referred over and over to "ugly old Fortran". It would be as hard for someone with that mindset to produce a good Fortran compiler as it would be for Jim Giles to produce a good "C" compiler, whether or not he chose Fortran as the intermediate language :-) It has been said that what finally (almost) killed Fortran was not its opponents, but the recent standardization (?) exercise. Perhaps this compiler is seen as a way for Fortran's opponents to "finish it off". (another ":-)"). -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | Disclaimer: "not much better than CANADA | datclaimer" -------------------+-------------------------------------------