Xref: utzoo misc.misc:6106 comp.misc:6071
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: misc.misc,comp.misc
Subject: Re: The "evil" GOTO (Was: 25 Years of BASIC)
Message-ID: <915@twwells.uucp>
Date: 11 May 89 03:42:11 GMT
References: <905@twwells.uucp> <13301@lanl.gov>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 64
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <13301@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
: From article <905@twwells.uucp>, by bill@twwells.uucp (T. William Wells):
: > In article <13113@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
: > :       if (cond1) {
: > :          [...A...]   /* lots of code */
: > :          goto LABEL;}
: > :       else if (cond2) {
: > : LABEL:   [...B...]   /* lots more code */
: > :       }
: > [...]
: > :                                  Solution 2) imposes a code space penalty
: > : as well as making code maintenance difficult (you must always remember to
: > : update _both_ versions of 'B').
: >
: > Only half true. Many (most?) optimizers will recognize that the two
: > code sequences are identical and put the branch where you would
: > expect.
:
: There's a limit to what an optimizer can do.  Suppose the example were
: a long sequence of "else if"s and that SEVERAL distinct branches all ended
: with sequence B.  Or, suppose the long sequence of "else if"s contain
: some branches that end with sequence B and others that end with C where
: B and C are disjoint.  Duplicating the code can waste a _lot_ of space
: and really make maintenance a nightmare!

What these optimizers do is to start from a point which several code
sequences end at and work backwards on all branches, munching
instructions so long as they are identical. So those are not really
problems. My own experience is that, while it is theoretically
possible to waste a lot space in this way, in practice it doesn't
happen.

The place where I've been most tempted to use a goto is, however,
very similar; had I succumbed, I'd have written code like:

	switch (n) {
	case 1:
		A;
		goto label;
	case 2:
		B;
label:
		C;
	}

So far, I've always found an acceptable way to avoid doing this.

: > Be aware that a *single* goto in a function can cause many optimizers
: > to do nothing for the function. The reason for this is that many of
: > the better optimization techniques depend on the program having a
: > particular control structure and transforming an arbitrary program
: > into one that is acceptable is a hairy task.
:
: This is _REALLY_ irritating though.  The example above obeys all the
: "rules" of a well structured control construct: it has only one entry;

Oh, I agree. That doesn't mean that these optimizers are smart enough
to recognize that it is so. The problem is that the code to do this
generally is hairy; however, writing code that handles enough of the
special cases is a real chore and there is no guarantee that one
really has done enough. Or so the reasoning goes.

---
Bill                            { uunet | novavax } !twwells!bill