Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!rex!ames!skipper!elxsi!maine From: maine@elxsi.dfrf.nasa.gov (Richard Maine) Newsgroups: comp.lang.fortran Subject: Re: Array Notation Message-ID: Date: 4 Jan 91 18:56:11 GMT References: <1991Jan04.154747.18673@convex.com> Sender: news@skipper.dfrf.nasa.gov Organization: NASA Dryden, Edwards, Cal. Lines: 69 In-reply-to: bleikamp@convex.com's message of 4 Jan 91 15:47:47 GMT On 4 Jan 91 15:47:47 GMT, bleikamp@convex.com (Richard Bleikamp) said: Richard> Nntp-Posting-Host: mozart.convex.com Richard> The draft standard requires the entire right side of an Richard> assignment statement to be evaluated before any values of the Richard> left side target are updated. This requires a temporary only Richard> when there is some overlap. Unfortunately, only Richard> vectorizing/parallelizing compilers do enough dependency Richard> anaylsis to get this right all the time. So a scalar machine Richard> compiler will often introduce unnecessary temps (at least Richard> until they add dependency analysis). F77 character assignments have a simillar problem with temps, avoided in the F77 standard by the simple expedient of making overlap illegal. Of course, some compilers allow it as an extension, and other compilers don't diagnose the problem but don't do it "right" either. I've run into several program bugs caused by people who didn't know about the restriction and assumed that expressions like character a*16 a(2:) = a will do the intuitively "obvious" thing instead of what it really does in many cases. Richard> The moral of these examples is ARRAY NOTATION is NOT a direct Richard> replacement for DO loops. They are not always Richard> interchangeable. Array notation is sometimes a convenient Richard> shorthand for simple array operations, but will not Richard> inherently allow compilers to generate better code. I'd agree with this statement. Though I've occasionally seen people suggest that array notation might or might not produce better code for parallel machines, this doesn't seem the main point. To me, the above quoted phrase "a sometimes convenient shorthand" is much more to the point. Array notation is to make code more concise, clearer, easier to maintain, and less buggy. Of course it doesn't guarantee any of these characteristics, but it can be used to aid them. I'll take a 30% slower program that actually works instead of a fast buggy one that gives wrong results any day. (For instance the F77 program bugs in character string overlap that I cited above would have worked correctly in F90). But then I'm funny that way. I swear there are people that would rather have the fast wrong results. (Unfortunately, that is sometimes literally true, rather than just a sarcastic comment :-(). If it takes DO loops instead of array syntax to make a time-critical section of code faster, then I'll certainly use the DO loops there. If it takes assembly language to make a time-critical section of code fast enough, I'll use assembly language. I've not found that necessary for several years though, whether because compilers have gotten enough better or because machines have gotten enough faster is not clear. The whole purpose of compilers is to make writing code (particularly good, maintainable, bug-free, etc. code) easier for the user. If speed were the number 1 priority, we'd all be coding in assembly. Array notation has been high on the wish list of very many Fortran users for decades. I've certainly heard the request many times, and its almost never been because the user wanted his code to run faster, but because he (or she - sorry) wanted it to be easier to write. Indeed the complaint "Why doesn't F8x/F90 just add array notation and forget all this other stuff?" has been heard regularly. (I don't happen to agree with that position, but I've certainly heard it). -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.64.6]