Path: utzoo!mnetor!uunet!husc6!uwvax!rutgers!iuvax!pur-ee!uiucdcs!uiucdcsb!kenny
From: kenny@uiucdcsb.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Put your code... (was Re: gotos
Message-ID: <165600043@uiucdcsb>
Date: 26 Apr 88 00:48:00 GMT
References: <2597@ttrdc.UUCP>
Lines: 38
Nf-ID: #R:ttrdc.UUCP:2597:uiucdcsb:165600043:000:1168
Nf-From: uiucdcsb.cs.uiuc.edu!kenny    Apr 25 19:48:00 1988


[Part 5. Sets of actions.]

Knuth mentions that in many examples of simulators and interpreters,
it is advantageous to do things like:

subtract: operand = - operand; goto add;
add: accumulator = accumulator + operand; goto no_op;
jump_if_overflow: if (overflow_indicator) {
			overflow_indicator = false;
			goto jump;
			}
		else goto no_op;
no_op: ++simulated_time;

I submit that, with today's larger memories, it is preferable to
duplicate the code (It's certainly faster not to have all the
unconditional branches in the instruction stream).  The above could be
written as something more like:

#define ADD accumulator = accumulator + operand
#define ADVANCE_TIME ++simulated_time
case subtract:	operand = - operand; ADD; ADVANCE_TIME; break;
case add:	ADD; ADVANCE_TIME; break;
case jump_if_overflow:
		if (overflow_indicator) {
			overflow_indicator = false;
			JUMP;
		}
		ADVANCE_TIME; break;
case no_op:	ADVANCE_TIME; break;

Moral: If the programmer is tempted to use GOTOs for a non-looping
control structure, it is preferable to duplicate code, using macros if
necessary to keep the duplicated code grouped together in the source
file.

[End of part 5.]