Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!oakhill!steve From: steve@oakhill.UUCP (steve) Newsgroups: comp.lang.fortran Subject: Re: DO loops, anyone? Summary: to market, to market, to buy a fat compiler. Message-ID: <1913@devsys.oakhill.UUCP> Date: 17 Mar 89 15:12:36 GMT References: <28506@sgi.SGI.COM> <1320@uw-entropy.ms.washington.edu> Organization: Motorola Inc. Austin, Tx Lines: 122 In article <1320@uw-entropy.ms.washington.edu>, charlie@mica.stat.washington.edu (Charlie Geyer) writes: > > In article <1317@uw-entropy.ms.washington.edu>, I wrote: > > A simpler solution would have compilers do run-time error checking and > not jump into inactive loops. The beauty of this solution is that it > does not not slow down structured code -- no checking necessary. > > Unstructured code would take a performance hit. Serves it right :-) > > It's not failure to end every loop with its own CONTINUE that is the > problem. It is (surprise!) GOTO's are harmful. > > In article <1905@devsys.oakhill.UUCP> steve@oakhill.UUCP (steve) replies: > > > As I stated in my previous post. There is NO problem with the code as > > posted. It is not ambiguous. The problem is that the compiler, in > > order to prevent any posssible ambiguity, generates bad code. The > > true ambiguity results in the following three elements used together. > > > > 1) Two or more do loops ending on the same line. > > 2) One or more of the external do loops (not the inner most) > > jumping to the terminating statement. > > 3) The terminating statement being executable (not a CONTINUE). > > The code as posted (we are still talking about the original posting aren't > we?) is, as several other people have pointed out, wrong. It DOES have a > problem. It jumps into the range of an inactive DO loop. This is > forbidden. It is not the job of a compiler to guess what conforming > program the programmer thought he was writing. It would be nice for > compilers to produce code that catches this error, at least as an option. > There are two problems in this code. 1) It is illegal 2) People want to do it. The ANSI standard, as much as they and we would perfer otherwise, do not live in the real world. They have ordained this code as illegal. But the real world wants to do this. Thus the compiler writers support this. Unfortunately there are some complicated issues of ambiguity to be resolved. Usually at this point we would ask the committe to resolve it. They say, "we did, it is illegal", and we are back to square one. At this point the compiler writer must decide how to support this extension (which was the point of my post). Thus compiler writers put this feature in, otherwise their compilers sit on the shelf. (Believe me, I wrote this code in a FORTRAN compiler. It would error out on jumping into blocks. The customer response. "Gee, could you put in an option which would allow us to do this". Thus the compiler now has a command line option to allow jumping into blocks. I give you 20-1 the command file they compile with has this option set, and the option to turn off non-ansi code warnings). Having put this feature in, they then want to be competive. They take short cuts. Instead of generating the true code (which has an extra variable and several extra pieces of logic), they generate code that is smaller and faster that will work in 99.5% of the cases. So you see. The problem is that the real world is subverting this problem with a double whammy. First the market wants a feature the standard says is illegal. And in the demand for fast effienct generated code, the market causes the compiler maker to take short cuts he can't without badly increasing the size and slowness of the compiler. > > Admittedly the practice of ending do loops on the same line is not > > sound programming. But it is historic programming, and is still used > > today. As for the performance hit you talk about, well that's part of > > the problem here. > > So make it an option that can be turned off. Read above. But to leave this feature out means you won't be able to sell compilers. > In article <18178@vax5.CIT.CORNELL.EDU> btcx@vax5.cit.cornell.edu > (Brian T > Carcich) replies: > [ real meaning of Dykstra's GOTO declaration deleted ] > > O. K., but that would have made a much weaker punchline. If you want to > be pedantic, unstructured use of GOTO's is harmful, and jumping in and out > of DO loops is about as unstructured as you can get. Is that o.k.? Unfortunately you can't save the unwashed masses from themselves. Not only can you not prevent them from doing this. If you forbid it, they cry and want it. If you want to sell compilers, this is something that must be supported. > Believe me. I don't write FORTRAN by choice. Lately I've taken to > writing some of my FORTRAN in C (thereby incurring who knows what > portability problems). But you just can't ever get completely > away from FORTRAN. It's everywhere. Writing in FORTRAN is nothing to be ashamed of. If you write carefully, you can do just as complex things in FORTRAN portably as you can in any other languge. Admittedly you do have to know how do you do your own recursion and handle you own pointers, but any programmer with his salt should know how to do this in his sleep. I hold a patent in AI. The system I wrote was in FORTRAN (for constraints I won't get into). When presenting a paper on it I would always get the question (from the a**hole that seems to always sit in the forth row) "What language did you use, C or LISP". When I replied FORTRAN, there were scoffs in the audience. I would unabashedly point out that the langauge in no way took away from the concept, and while other people had their AI systems still on the drawing board in LISP or C, mine was completed working and part of a marketed system. enough from this mooncalf - Steven ---------------------------------------------------------------------------- To flame someone for bad spelling or grammer is a discouragement to net discussion in a timely fashion. ---------------------------------------------------------------------------- These opinions aren't necessarily Motorola's or Remora's - but I'd like to think we share some common views. ---------------------------------------------------------------------------- Steven R Weintraub cs.utexas.edu!oakhill!devsys!steve Motorola Inc. Austin, Texas (512) 440-3023 (office) (512) 453-6953 (home) ----------------------------------------------------------------------------