Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!sun!chiba!khb From: khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) Newsgroups: comp.lang.fortran Subject: Re: FORTRAN 88 Message-ID: <75238@sun.uucp> Date: 28 Oct 88 23:43:58 GMT References: <5833@vdsvax.steinmetz.ge.com> <7540@megaron.arizona.edu> <74566@sun.uucp> <1127@microsoft.UUCP> Sender: news@sun.uucp Reply-To: khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) Distribution: comp.lang.fortran Organization: Sun Microsystems, Mountain View Lines: 56 In article <1127@microsoft.UUCP> bobal@microsoft.UUCP (Bob Allison (uunet!microsoft!bobal)) writes: >> >>Most of the time spent in such a compiler is the optimizer. If you >>don't have a fancy vector processor and a complex set of related >>functional units, compilation goes very quickly. >> >Ah, but this is precisely the problem: on a small scalar machine, an >optimization phase is just as time-intensive as on a Cray, but the array >language reduces the amount of optimization necessary on a Cray (well, >a little) and greatly increases the amount of optimization necessary on >a scalar machine. No Bob it isn't even close. There is no need to do massive instruction scheduling, dependency analyses nor most of the fun things which crop up in "real machine optimizers". Also interprocedural analysis is much less interesting (since the cost of a contex switch is vastly cheaper, reg saves, breaking the pipelines, and dozens of other effects). If this were true compiles which take minutes with my Lahey compiler (or seconds on a Sun4 with our compiler) would take hours (viz. the cydra 5 compiler, pathalogical cases). >"If you don't have ... a complex sex of related functional units": this >is the same guy who couldn't understand why anyone was against MODULEs, >I believe (if not, accept my apologies; but the point is still valid). No you're right. I'm that guy. Look at any Modula II implementation; they compile very quickly, and their internal organization (in some cases) is quite clean. Most are the products of small groups, working in a very limited time. F88's modules should not be any harder to implement. > >Also, run-time performance will necessarily decrease, since I can't figure >out how to do compile-time analysis of an array statement such as: > >A = RESHAPE(ESHAPE(A),TRANSPOSE(SPREAD(B,3,I))) > >(Complete nonsense, but it makes the point that at compile time I have >no idea what the size of intermediate array expressions will be). So, while >I am in favor of the concept of array operations, I want people to realize >it will not be a freebie, and I want to try to reduce the possibility of >statements like the above popping up. a) I strongly suspect that such knowlege exits...among those who have had to cope (cdc, cray, convex, compass, etc. also among those who have implemented apl-like languages). b) for a simple scalar machine why do you really care ? dynamic memory is already required for f88 (and C, and Modula, and nearly all operating systems, and etc.). Deferring such things to run time hurts high performance machines, not "simple scalar processors". khb Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus