hirchert@uxe.cso.uiuc.edu (10/21/88)
Steve Rowan quite correctly points out that doing a lexer/parser is only a very small part of a compiler. Since no one who was at the Paris WG5 meeting has explicitly confirmed whether that was all that was demonstrated or whether the demo also included some semantic analysis (and, if so, how much), it is difficult to say whether that demo "proved" anything about the implemetability of Fortran 8x. Steve then proceeded to present the following numbers, derived from the size of the Convex Ada compiler: 5K lines - lexing/parsing 95K lines - semantic analysis 80K lines - vectorization and code generation 20K lines - dependent compilation library management I had a little problem with these: The local ambiguities, proliferation of derived types and operations, and multiple symbol tables of Ada appear to me to make its semantic analysis much harder than that of Fortran 8x. I would put the complexity of Fortran 8x more on a par with Modula 2 or an extended Pascal. On the other hand, I think Steve is right on track with his concerns about the cost of optimizing/vectorizing the array language. If most of the opponents of the Fortran 8x draft were expressing concerns about the amount of effort to generate efficient code for the array language, I could take their concerns about complexity more seriously. Instead, I see most of those opponents supporting the array language and a number of vendors already implementing it. Finally, 20K for dependent compilation library management also looks high to me. Fortran 8x's dependent compilation feature was intended to be more like a precompiled INCLUDE than the kind of grand feature in Ada. If there are aspects of it that would force this kind code inflation, then they should be repaired, but lets not throw out the baby with the bathwater. In short, I expect Fortran 8x to be significantly more work to compile than FORTRAN 77, but not as much work as Steve suggests. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
bill@hcx2.SSD.HARRIS.COM (10/23/88)
Kurt Hirchert (hirchert@uxe.cso.uiuc.edu) writes: > On the other hand, I think Steve is right on track with his concerns > about the cost of optimizing/vectorizing the array language. If most of > the opponents of the Fortran 8x draft were expressing concerns about the > amount of effort to generate efficient code for the array language, I > could take their concerns about complexity more seriously. Instead, I > see most of those opponents supporting the array language and a number of > vendors already implementing it. Well I, for one, have been expressing concerns about the array language. I think it will cause scalar machines particularly to run like molasses in Alaska. So why, you ask, am I supporting the array language? I am supporting the CONCEPT of the array language, but I have real problems with some of the details. I think there are so many users who are running, or would like to run, the same code on both supercomputers and scalar machines (even PCs!), that some kind of array language is a must for portability. I would like, however, to see it scaled back somewhat from the 8x draft. The reason that I, and I suspect others, have not harped on the array language is because we recognize its importance. The fact, though, that the array language adds significant complexity makes us all the more reluctant to accept much else. Its like a young couple buying their first house: they recognize they _need_ a house, but it doesn't have to have gold-plated fixtures. We simply can't afford the effort required for the 8x array language AND all the other stuff too. Dependent compilation has gotten a lot of attention here, so I'll put in my two-cents worth. The fact is, the 8x draft doesn't nail down nearly enough of the requirements of MODULE/USE to know how to implement it. For instance, the standard does not say what the behavior should be if a program USEs a MODULE, then the MODULE is modified and recompiled. The obvious response is, it should be an error to do this. But you can't give an error if MODULE/USE is implemented as a fancy INCLUDE. Exactly, you say! So how come INCLUDE is better, you shout? The difference is that the user _knows_ that INCLUDE is just that, an included file, but MODULEs get compiled! INCLUDE files never get compiled, so there is no expectation from the user that such recompilation will fix all the references, or at least tell him he screwed up. The opposite is true for MODULEs; the user expects that the compiler will remember that the MODULE was recompiled, and tell him if something else needs to be recompiled. Also, remember that by the time 8x is out, lots of people will have had experience with Ada, and that will color their expectations. But it's worse yet: MODULEs can contain procedures! So a USE of the MODULE can't be implemented as a simple INCLUDE: the compiler needs to selectively include information from the MODULE. This is certainly more complex than just INCLUDE.
hirchert@uxe.cso.uiuc.edu (10/24/88)
Steve Rowan(rowan@mozart.uucp) writes: >1. FORTRAN 8x contains every feature of Ada except tasking. Nonsense! It doesn't have locally ambiguous expressions, Ada-style generics, Ada-style derived types and operations, representation specifications, or exception handling (including the detection of a wide range of exceptional conditions by default - adding to the optimization burden), just to name a few. In fact, if I go back and look at the literature that describes the problems in recognizing Ada, I find none of those features in Fortran 8x. If I look at the features that vendors omitted from their early incomplete releases of Ada (presumably because they were hard features to do), I again find features that are not present in Fortran 8x. (Now, not being perfect, I'm certain that I may have missed some feature in Fortran 8x that is analogous to a feature of Ada that caused at least one vendor difficulty. My point remains that a large part of the features of Ada that cause implementation difficulty are _not_ part of Fortran 8x) [Steve then went on to point out complications in Fortran 8x that are not in Ada. I do not challenge that list. I would point out a. Many of those "problems" are already solved in FORTRAN 77 processors. b. Many of those "problems" are lexical or syntactic, and as Steve has pointed out in earlier postings, the lexer/parser isn't where the major part of the work is.] Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
tsh@mace.cc.purdue.edu (Greg Kamer) (10/24/88)
> > On the other hand, I think Steve is right on track with his concerns > > about the cost of optimizing/vectorizing the array language. If most of > > the opponents of the Fortran 8x draft were expressing concerns about the > > amount of effort to generate efficient code for the array language, I > > could take their concerns about complexity more seriously. Instead, I > > see most of those opponents supporting the array language and a number of > > vendors already implementing it. > Well I, for one, have been expressing concerns about the array language. > I think it will cause scalar machines particularly to run like molasses > in Alaska. Why? I am afraid this doesn't make any sense to me at all. Our vector code has been ported to a LOT of scaler machines, and the only degradation seen was that expected from the lack of vector hardware and differences in scaler processing speed. Please give an example- I'm afraid that after working with a vector machine for 5 years I can't think of any. > So why, you ask, am I supporting the array language? I am > supporting the CONCEPT of the array language, but I have real problems > with some of the details. I think there are so many users who are > running, or would like to run, the same code on both supercomputers > and scalar machines (even PCs!), that some kind of array language is > a must for portability. I would like, however, to see it scaled > back somewhat from the 8x draft. > The reason that I, and I suspect others, have not harped on the array > language is because we recognize its importance. The fact, though, > that the array language adds significant complexity makes us all the > more reluctant to accept much else. Its like a young couple buying > their first house: they recognize they _need_ a house, but it doesn't > have to have gold-plated fixtures. We simply can't afford the effort > required for the 8x array language AND all the other stuff too. The good news is that there is SOME vector syntax as part of the standard- the bad news is that it is pretty simplistic compared to the already available toys in CDC and Cray vector Fortran. The inability to easily port these programs costs us EASILY 30 to 40 thou a year in conversion and update costs. We need this stuff and we need it NOW! If you are going to take 4 or 5 years to develop a standard and another 4 or 5 to implement it, you better believe you want the gold-plated fur-lined version and not the economy model. Keep in mind that the cost of writing compilers is miniscule compared to the cost of using an inadequate one. If Fortran 88 follows that same cycle as Fortran 66 and Fortran 77 in terms of standard development / implementation / dissemination / acceptance I think we can realistically expect to see such a compiler in about 1993 on those machines where people are willing to pay the $$$ for writing good compilers, and we might see it in widespread use by maybe 1996 to 1998. I am not willing to wait until the next CENTURY to see the non-vector Fortran 88 extensions. When a compiler writer points out a feature of Fortran 88 that will be impossible to implement, and if enough compiler writers agree, it ought to be deleted or modified. Otherwise, the "excessive" amounts of time some people claim it will take to implement the new standard need to be measured against the REALLY excessive waste of human time that will result from using a "simple" compiler for the next 15 years. ... > Exactly, you say! So how come INCLUDE is better, you shout? The > difference is that the user _knows_ that INCLUDE is just that, an included > file, but MODULEs get compiled! INCLUDE files never get compiled, so there > is no expectation from the user that such recompilation will fix all the > references, or at least tell him he screwed up. The opposite is true for > MODULEs; the user expects that the compiler will remember that the MODULE > was recompiled, and tell him if something else needs to be recompiled. > Also, remember that by the time 8x is out, lots of people will have had > experience with Ada, and that will color their expectations. I've written about this one before. MODULE is much more useful than INCLUDE if you are writing your code on a front-end machine and submitting it to a remote host. For such a setup, INCLUDE's have to be done with a front-end preprocessor before submitting the mainframe. With MODULE's you can simply prepend all of your MODULE's to the front of the code and send it off. Put simply, making INCLUDE part of the Fortran 88 standard does me absolutely no good at all- MODULES will allow me to get rid of the preprocessor I currently have to use. -- Greg Kamer - Purdue Macromolecular Crystallography tsh@mace.cc.purdue.edu (internet - read every day) xtsh@purccvm.bitnet (bitnet - read very rarely)
ok@quintus.uucp (Richard A. O'Keefe) (10/25/88)
In article <909@mace.cc.purdue.edu> tsh@mace.cc.purdue.edu (Greg Kamer) writes: >I've written about this one before. MODULE is much more useful than >INCLUDE if you are writing your code on a front-end machine and >submitting it to a remote host. For such a setup, INCLUDE's >have to be done with a front-end preprocessor before submitting the >mainframe. With MODULE's you can simply prepend all of your MODULE's >to the front of the code and send it off. Could you clarify this a bit? It sounds as though you are saying that all the MODULEs used in a program have to be part of the same compilation source on the mainframe; that you can't have some MODULEs sitting there that you just use. Is that so? If it isn't so, how is having a module already sitting on the mainframe and having the compiler use it any easier than having an INCLUDE file already sitting on the mainframe and having the compiler on the mainframe include it? (Remember COBOL's "COPY" statement, anyone? It can be done.)