>From owner-simulators  Mon Aug  7 18:50:34 1995
Received: from localhost (localhost [127.0.0.1]) by june.cs.washington.edu (8.6.12/7.2ju) with SMTP id SAA04301 for <simulators@cs>; Mon, 7 Aug 1995 18:50:34 -0700
Message-Id: <199508080150.SAA04301@june.cs.washington.edu>
To: simulators@cs
Subject: EXECUTE instructions
Date: Mon, 07 Aug 1995 18:50:33 PDT
From: "		    pardo@cs.washington.edu" <pardo@june.cs.washington.edu>
X-Message-Id: simulators@cs.washington.edu, message #1995-08-004
X-Unsubscribe: e-mail `majordomo@cs.washington.edu', body `unsubscribe rtcg'

[I needed to review this for RTCG; it seemed relevant to simulators.]

[Summary: the EXECUTE instruction provides a structured bridge between
 arbitrary self-modifying code and some static-code forms that are
 hard to make work on some machines.  Particular examples include
 generating indirect addressing modes for instructions that don't have
 them but without modifying the instruction segment; and implementing
 a simulator loop that executes target instructions directly but which
 doesn't need to patch the simulated instruction into the simulator
 loop.  --Pardo]

%A Fredrick P. Brooks, Jr.
%T The Execute Operations -- A Fourth Mode of Instruction Sequencing
%J Communications of the ACM (CACM)
%V 3
%N 3
%D March 1960
%P 168-170
%W Henry Baker
%X Summary: The ``execute'' instruction is another control flow
mechanism.
  RTCG interest: if the operand is allowed to be in a data area (data
memory address or data register) then ``execute'' is a
formalized/stylized way of transforming code into data.
  Digital computers have modes of sequencing instructions: normally,
an instruction passes control to its successor.  Branching passes
control to some instruction that is not (necessarily) the successor.
Interrupts (``recently'' discovered [Mersel 56]) _take_ control from
an instruction.  The `execute' instruction, Brooks claims, _lends_
control to the operand but takes it back and then uses another mode to
pass control.
  Execute existed on at least IBM Stretch, IBM 709 (developed
independently) and LEM-1 [Makhmudov 59].  (And the Ural [Simonyi,
Personal communication to Pardo].)
  Suggested applications: allows instructions in read-only storage to
use modifiable instructions in read/write storage (LEM-1).  Allows
``efficient programming techniques [that] depend upon instructions
which are developed and executed in the accumulator [and which
previously have not been] applicable to counter-sequenced computer.''
Unclear to Pardo what are these efficient techniques.  On the 709,
simplifies modification of non-indexable and non-indirect-address
operations such as those for I/O; Henry Baker says simplifies computed
GOTOs on some machines.  Provides ``one-instruction'' subroutines
which can be used as callbacks for parameter passing (like the KSR-1
`nargs' hack).  Allows simpler mixing of interpreted
pseudo-instructions with real instructions.  Simulators need to
intermix execution of monitoring code and application code; done
easily with code of the form
	TOP:	<<trace>>
		EXECUTE vpc
		JMP TOP
Without an EXECUTE instruction the simulator loop is
	TOP	<<trace>>
		MOV *vpc,SLOT
	SLOT:	.
		JMP TOP
See e.g., [Gill 51].
  There are a variety of ways to implement EXECUTE.  On the 709,
EXECUTE passes control the operand, and if the operand is a branch
instruction, control never returns to the EXECUTE.  On the Stretch,
control returns normally for nonbranch instructions and causes an
interrupt for branch instructions.  On the Ural, control normally
falls through; on a branching instruction control skips the immediate
successor.
  An EXECUTE that does execute jumps is suggested as useful for
addressing modes, where e.g., simple callbacks (`thunks') are a single
instruction and complex callbacks are a jump to a longer sequence.  If
branches are supressed, good for simulators.
  The Stretch implements EXECUTE INDIRECT AND COUNT (EIAC) in which
the operand is a virtual PC; EIAC increments the virtual PC is
incremented by the length of the operand instruction.  The virtual PC
is not updated on branches (an interrupt is signaled).
  Any EXECUTE instruction may have another EXECUTE as its operand.  On
the Stretch, an ``overly long chain (several hundred operations)''
causes an interrupt.
  Pardo analysis: The distinction between EXECUTE and call/return
seems muddy, though it's clear there are things that are easy to do
with EXECUTE (e.g., simulation) that are harder without it, enough
harder that RTCG/SMC is sometimes faster than the static code
alternative.
  [Makhmudov 59]  Radioteknika 3 (March 1959) 44-57.  In English:
Communications of the ACM, Vol. 2, No. 10, October 1959, pg 3.
  [Mersel 56]  Jules Mersel, ``Program Interruption on the
Univac Scientific Computer,'' Proceedings of the WJCC, P. 52, 1956

%A Henry G. Baker
%T Personal communication
%D July 1995
%W To pardo
%X Limiting the EXECUTE instruction so that it won't execute branches
means that it is particularly difficult to make ``mini-thunks''
[Brooks 60] general.
  On the IBM 360, EXECUTE was important for ``character move''
instructions which encoded the length of the move as a compile-time
number, and there was no variant of the instruction taking a run-time
length.  If you used the EXECUTE instruction you could specifiy a
register whose contents would be OR'ed with the bits of the
instruction being executed and therby specify the move length at
run-time.  The 370 fixed the problem by providing a variable-length
move instruction, but by then even the Cobol and PL/I compilers made
use of the EXECUTE 'hack'.