ted@usceast.UUCP (Ted Nolan) (10/26/84)
<goto GRAD_SCHOOL; /* do not collect $200*/>
If anyone really feels strongly enough about a special syntax for breaking out
of multiple loops, why not write a preprocessor to do it for you, as ratfor
imposes structure on FORTRAN? Then you and your organization have your coveted
code cleanliness and can still export portable code after the preprocessing
(or you could export the preprocessor with the code). One of the nice things
about gotos is that you can map any control structure into them. I don't
think this is something that should be part of the "real" language.
Ted Nolan ..usceast!ted
--
-------------------------------------------------------------------------------
Ted Nolan ...decvax!mcnc!ncsu!ncrcae!usceast!ted
6536 Brookside Circle ...akgua!usceast!ted
Columbia, SC 29206
("Deep space is my dwelling place, the stars my destination")
-------------------------------------------------------------------------------geoff@desint.UUCP (Geoff Kuenning) (10/27/84)
In article <2122@usceast.UUCP> ted@usceast.UUCP (Ted Nolan) writes: >If anyone really feels strongly enough about a special syntax for breaking out >of multiple loops, why not write a preprocessor to do it for you, as ratfor >imposes structure on FORTRAN? Then you and your organization have your coveted >code cleanliness and can still export portable code after the preprocessing >(or you could export the preprocessor with the code). One of the nice things >about gotos is that you can map any control structure into them. I don't >think this is something that should be part of the "real" language. And one of the worst things about goto's, as I pointed out once before in this discussion but seems to have been forgotten, is that you *CAN'T* do certain kind of very valuable optimizations when goto's are present. In practice, this means that most compiler writers choose not to do these optimizations if the language, or at least the routine being compiled, contains and goto's at all. A pretty high price to pay for a feature even the let's-keep-C-C types recognize as being of limited usefulness. (Indeed, I can recall only one article that came out in support of goto's for any purpose except breaking out of loops). Go back and read Dijkstra's 1967 letter; it's not long. It has two objections to goto's, and gives equal weight to both. One is the readability/maintainability issue, which is the only one that has been discussed in the current controversy. The other is the fact that goto's severely hurt our ability to write optimizing compilers, and thus our ability to break away from the expense and drudgery of writing assembly language. So tell me, folks: do *you* have a global data flow analysis algorithm that works in the presence of unrestricted goto's? -- Geoff Kuenning First Systems Corporation ...!ihnp4!trwrb!desint!geoff
joe@petsd.UUCP (Joe Orost) (10/29/84)
<> >So tell me, folks: do *you* have a global data flow analysis algorithm that >works in the presence of unrestricted goto's? >-- > Geoff Kuenning > First Systems Corporation > ...!ihnp4!trwrb!desint!geoff Yes, we have had one since 1978 in our FORTRAN VII O compiler. Any decent global optimizer works on the program after all loops, block ifs, etc. have been changed into GOTOs. We even remove loop invarients from GOTO loops. regards, joe -- Full-Name: Joseph M. Orost UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!joe US Mail: MS 313; Perkin-Elmer; 106 Apple St; Tinton Falls, NJ 07724 Phone: (201) 870-5844
henry@utzoo.UUCP (Henry Spencer) (10/29/84)
> So tell me, folks: do *you* have a global data flow analysis algorithm that > works in the presence of unrestricted goto's? I seem to recall that several such have been published. They don't do as well when there are goto's as when there aren't, but they do work either way. In any event, it is not at all difficult to recognize when a goto is in fact just a loop exit, so this is irrelevant to the main discussion. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/30/84)
> So tell me, folks: do *you* have a global data flow analysis algorithm that > works in the presence of unrestricted goto's? I would like to see any global data flow analysis algorithm that would substantially improving the code generated from my (goto-free) C code. I doubt very much that there is one. I like to do my own high-level algorithmic optimization, thank you.
geoff@desint.UUCP (Geoff Kuenning) (11/02/84)
In article <370@petsd.UUCP> Joe Orost writes: >>So tell me, folks: do *you* have a global data flow analysis algorithm that >>works in the presence of unrestricted goto's? >>-- >> Geoff Kuenning > >Yes, we have had one since 1978 in our FORTRAN VII O compiler. Any decent >global optimizer works on the program after all loops, block ifs, etc. have >been changed into GOTOs. We even remove loop invarients from GOTO loops. Um, oops. I must be getting senile. As Peter Honeyman also pointed out, what Dijkstra was actually saying was that the unrestricted USE of GOTO's made programs less optimizable. For example, the sequence call destroyregisters (a, b) goto 200 C Top of Loop 100 continue ... (a) 200 continue ... (b) if (loopmore) goto 100 cannot make any assumptions about the contents of temporary registers in code section (b). (I decided to use Fortran since I'm obviously senile. The proof is in the fact that I wrote Fortran using lowercase.) This is a much less serious problem. Having egg on my face and having been shown that carefully-used goto's are as optimizable as the funny break, I hereby withdraw all my objections and come out in support of using goto's for this purpose. I think I'll go punch some cards, just for old times' sake... -- Geoff Kuenning First Systems Corporation ...!ihnp4!trwrb!desint!geoff
honey@down.FUN (11/05/84)
/***** down:net.lang.c / desint!geoff / 11:02 pm Nov 4, 1984*/ ... Um, oops. I must be getting senile. As Peter Honeyman also pointed out, what Dijkstra was actually saying was that the unrestricted USE of GOTO's made programs less optimizable. ... /* ---------- */ i never said any such thing! (the *only* circumstances under which i cite dijkstra are those that require generalization from a single example.) i *did* say that even programs that use goto's are (almost always) reducible (er, flow-graph-wise -- ref. knuth, brenda baker) -- this observation seems to have gotten twisted around in the translation. peter