Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!ames!sdcsvax!ucsdhub!jack!man!nu3b2!rwhite
From: rwhite@nu3b2.UUCP (Robert C. White Jr.)
Newsgroups: comp.lang.c
Subject: Re: goto's in C: an opinion...
Message-ID: <1129@nu3b2.UUCP>
Date: Wed, 29-Jul-87 15:14:33 EDT
Article-I.D.: nu3b2.1129
Posted: Wed Jul 29 15:14:33 1987
Date-Received: Fri, 31-Jul-87 06:23:34 EDT
References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP> <765@haddock.ISC.COM> <1191@killer.UUCP>
Organization: National University, San Diego
Lines: 84
Summary: do ... while (expr);

In article <1191@killer.UUCP>, jfh@killer.UUCP (The Beach Bum) writes:
> 
> Every high level construct can be faked with just if's and goto's.
	[Lots of examples of end-tested loops and such]
> 

	The whole point is not that people should "fake" high level
constructs with goto(s) and if(s).  If you think a moment, you will
realize that vary few [any?] computers have a machine level "while"
construct that can span multiple instructions.  When push comes to
shove ALL high leve constructs are reduced to tests and branches
(if(s) and goto(s))  But it is silly bordering on foolish to maintain
that using if and goto to build a loop will net more efficient code.
	Optimizing compilers can only optimize if they can group
code statments and analize the possible execution paths.  By spotting
obviously (needlessley) repetitive code and moving it outside the/a
loop in question:

i.e.
int	func(x);
int	*x;
{
.
.
.
	while (test-which-does-not-use-x-as-value) {
		y = x+4;
		x+4 = z;
		[loop-body-which-does-not-modify-x]
		}
.
.
.
}

	In this example the x+4 would be moved out of the loop to
increase efficency.  If I did this loop with gotos, the compiler
would not know where "out of the loop" was, so the calculation would
be kept in every instance.  Also an if thends to generate:
test
jump forward on false to X
true instructions
jump forward towards exit to Y
label X
false instructions
label Y

If you seround this with the loop branching, and the add the branch out
as the "true instructions" for a negated test [just ignore the "else"
branch sequence] you end up branching twice for each condition.  the
extra branch instructions will flush any instruction prefech queus and
generally slow the system down an extra time.

	Between the extra branching and the loss of optomizing the code
generated by goto programming is almost always slower than the loops.
inline testing for a nonzero value [C boolean tests] are usually 
inline zero-extra-branch tests which can slip into the stream in such a
way that no prefetch queues are disrupted and no extra branches take
place.  To use test-break logic you must branch excessively around
the false contidtions.

on an 80x86 machine or 80x88 machine a bolean test is:
mov ax,0
test ax,[address of value]
je instruction-after-loop  ; /* jump if equal, out of loop

As long as the boolean is true, the jump is ignored.  After optomizing
multiple tests, only the last two are repeated.  This is VERY efficent
code.  if you use the test and break form the end I garentee at least one
executed branch per test.

Claiming a boolean test in a while loop's conditional expression
will slow code is stupid.  Get you your DDT [Dynamic Debugging Tool]
of choice and examine the code.

Using GOTO is a BOG.

Robert.

[I know I can't spell, if you don't like my words, but all you answer
is the spelling it goes to >/dev/null, ALL other critiques taken
seriously.]

nu3b2!rwhite