Some languages allow the provision of a label for a block, and a LEAVE
statement that takes a label as an argument. In such languages this
construct performs the same function as your GOTO, but in a way that can
be better understood by the optimizer.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
On 2012-04-23 10:44, John Gilmore wrote:
Edward Jaffe's already cited point, that
<begin extract>
The behavior of well-defined coding structures like IF/THEN/ELSE, DO,
SELECT, CASE, etc. are extremely well understood--both by programmers
and by code optimizers no matter which language is being employed.
</end extract>
is fundamentally important. Optimizers distinguish many special
cases of each of these figures, generating slightly but significantly
different code for each of them.
A routine that is comprised chiefly of instances of these figures is
thus easy to optimize, and this is often the case even when these
figures are used less felicitously than than they should be. An
optimizer can mitigate the bad-performance effects of ugly code.
It must, however, be remembered that the code generated for, say, a DO
WHILE or a DO UNTIL contains and makes critical use of unconditional
branches. They are indeed implicit in these two figures and, of
course, in IF-THEN-ELSE too.
The question when GOTOs, i.e., unconditional branches, should be used
explicitly is thus the interesting one.
I myself use them where 1) I judge that they confer a significant
performance benefit and 2) they can be used in a regular/orderly way.
IN looking through code that I have written recently for instances
of them I discovered something that I had not really been aware of.
I use them most often to unwind recursions and for catastrophic
error-handling.
If, say, in traversing a binary-search tree recursively in some key
sequence I find what I
want, I use a 'stack-cleaning long branch' to return to the point at
which I began the traversal. This 'out-of-block GOTO' is not strictly
necessary; but the alternative, a sequence of several stack-unwinding
returns, is ugly and slow.
To summarize now, there are, I think, situations in which explicit
GOTOs are appropriate, in which their use can confer significant,
readily measurable performance benefits.
Unfortunately, these situations are also highly problematic. To use
GOTOs effectively in them one needs to know more about run-time
dynamics than most programmers now know or are, I fear, ever again
likely to be taught.
John Gilmore, Ashland, MA 01721 - USA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
