gotos

[Chris Torek]

>>Personally, I don't care diddly-squat about how ugly the code coming out
>>of the compiler is.  I don't usually read it.  What I care about is the
>>cleanliness of the source code, which I do have to read, and the speed and
>>correctness of the object code.  Turning clean human-readable notation into
>>ugly fast code is the compiler's *JOB*.  [Henry Spencer]

In article <504 at wsccs.UUCP> terry at wsccs.UUCP (Every system needs one) writes:
>You don't agree that less of the same instructions == faster code?

I imagine he does.  What do goto statements have with fewer
instructions in the machine code?  Answer: very little.  Indeed, in a
straightforward compiler `goto's produce branch instructions, which
must be executed in addition to the inline instructions at the label to
which the branch branches.  So using `goto's often means executing
*more* instructions, not fewer.  Also note that in some architectures,
branches are quite a bit slower than `regular' instructions; that one
extra branch to merge with common code may take as much time as ten or
fifteen of the instructions at the common code point.

>How does a goto differ from a break statement when used to exit a for
>statement to the statement immediately after it... pages of code later?

`goto' statements have the `come-from' problem.  (Fortunately, and
especially with well-chosen labels, this problem is small enough in C,
given a decent editor.)  As an example, recently I was fixing various
bugs in the 4BSD Vax peephole optimiser (see comp.bugs.4bsd).  This
thing is full of `goto's; in several instances I had to verify that the
only way to reach some particular label was from one nearby `goto'.  It
is by no means obvious, given the ~400 line---and ugly multi-statement
lines at that---`bmove' routine.

Personally, I have little trouble with an occasional `goto', but I
have noticed that use of `goto's tends to coincide with other practises
that, all together, reduce readability and maintainability.

As an aside, Terry mentions that [edited somewhat]

>I happen to write code that uses
>	for( ;;) {
>instead of
>	while( 1) {
>as I need the best speed out of the hardware I can get and the 'for'
>avoids a test instruction being generated.

Any compiler that generates a `test 1' instruction for the while(1)
loop should not be discarded lightly.  It should be thrown away with
great force.  Great grief!, even PCC does not test constants!

>Certainly, the 'while' is better at self-documenting,

Is it?  I happen to prefer `for (;;)'---to me this is an idiomatic
expression for `forever'.  (Using

	#define EVER ;;
	for (EVER)

however, is tacky :-) .)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris