🚀 go-pugleaf

In article <BwxsF6.3DF@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>I would like to see how you anti-gotos would write code of the following
>type so that either a human being could understand it, or a computer 
>could do an efficient job compiling it.

After staring at your quasi-code for a while, I'm convinced that it could be
improved on both counts.  Unfortunately, since what you've posted is both
ambiguous and noncompilable, I can't follow it well enough to just hand
you back my own version.  However, here are two suggestions you could
incorporate:

First, format your code in a standard style, using indentation to indicate
nesting.  This will by itself improve the chances of a human being
understanding it.

Second, don't use `goto's just to avoid duplicating miniscule pieces of
code.  Replace code such as:

	  switch ( x ) {
	      case 1: {
	          i += 1;
	          goto labelA;
	      }
	      case 2: {
	          j = 7;
	          goto labelB;
	      }
	      case 3: {
	          k = i << 3;
	          goto labelA;
	      }
	      case 4: {
	          x = 0;
	          goto labelB;
	      }
	      default: {
	          x = 1;
	          goto labelC;
	      }
	  }
	labelA:
	  j = 4000;
	  goto labelC;
	labelB:
	  k = 4001;
	labelC:


with:

	  switch ( x ) {
	      case 1: {
	          i += 1;
	          j = 4000;
	          break;
	      }
	      case 2: {
	          j = 7;
	          k = 4001;
	          break;
	      }
	      case 3: {
	          k = i << 3;
	          j = 4000;
	          break;
	      }
	      case 4: {
	          x = 0;
	          k = 4001;
	          break;
	      }
	      default:
	          x = 1;
	          break;
	  }

The second piece of code is easier to understand and no slower than the
first.  Depending on the compiler, it's likely faster.

Exactly how much duplication to tolerate can be an engineering decision.
However, if I hear you right and you're trying to get every possible ounce
of speed out of a single subroutine, you'd be wise to trade off an increase
in program size for an increase in the distance between branches and a
reduction in the number of `goto's.  As long as you don't bloat your code so
badly that it won't fit in the on-chip cache, you can improve both the
speed and the structure of your code this way.

Just my $10 worth.

----------------------------------------------------------------------------
Boycott redwood.  Boycott Louisiana-Pacific.  Keep the forests.  YYYYYYYYYYY
John Hauser---jhauser@cs.berkeley.edu  YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY