>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 ; 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" 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: <> EXECUTE vpc JMP TOP Without an EXECUTE instruction the simulator loop is TOP <> 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'.