Why did instruction sets since the late 1970s seemingly stop including an "execute" instruction?

Question

Many mainframe instruction set architectures (ISAs) in the 1960s included an Execute instruction, which would treat data as an instruction.

I haven't found an architecture designed after 1976 which includes such an instruction. The Wikipedia article (which I wrote) speculates that this is because the Execute instruction interferes with various CPU optimizations like pipelining, but provides no source. That predates RISC architectures.

So:

• Were there any ISA designs after 1976 that included Execute instructions?
• Is there any published discussion of the design decision to not include them?

The Wikipedia article has many footnotes, but none resolve these questions.

Answer 1

The HP-3000 first introduced in 1972 was a 16-bit stack-based architecture that included an XEQ instruction that would treat a word on the stack (between TOS and 7 words below that as selected in the instruction) as a regular instruction and execute it.

This was utilized in some calling conventions where you needed to execute a different version of the EXIT procedure return instruction based on how the function was called. The instruction EXIT n would return and pop n words off the top of the stack in the process, and the programmer would do something like (in SPL):

     TOS := %031400 + N; << Create appropriate EXIT instruction >>
     ASSEMBLE(XEQ 0);    << Return from function >>

Answer 2

TL;DR Too complicated for not much benefit.

You ask why not include an execute instruction. The reason is quite simple. Since around the time you observed the absence of this kind of instruction, the CPU's got more and more optimized in their memory access. Code access was separated from data access as the access pattern are quite different.

To execute a data word as an instruction would require to place that datum in front of the decoder requiring complicated bypass networks, busses and buffers, then the instruction must be inserted in the right place but, how many instruction have already entered the pipelines when it executed the EXEC instruction? The CPU would need to cancel all the instructions already partially executed, etc. i.e. something extremely costly. It is simpler to just write new instruction in memory and jumping to that address. It does not require supplemental plumbing besides what is already necessary for cache coherence.

For a TMS-9900 which already has its register in normal memory, it is extremely simple to add the X instruction, which will fetch the instruction contained in the given register (which is a simple memory fetch), for other CPU's it is more involved.

Answer 3

I haven't found an architecture designed after 1976 which includes such an instruction.

TL;DR: There is no use case for next to all later GP architectures.

The Long Story:

Because next to all general purpose (GP) architectures developed since then followed a rather simplified structure that holds all parameters that can/may be modified in registers (or alike structures) (*1). There is no need to create synthetic (modified) instructions if all parameters of an instruction can be created dynamic anyway.

When it comes to dynamic instruction adjustment, there are usually two main parameters that need to be adjusted: memory addresses and data length (*2).

Let's for example take a look at parameters of instructions of the eventually most widely used architecture with an execute instruction (where use was rather common), the IBM /360:

• Memory addressing could be easy made dynamic,

  as each and every memory reference was register relative (base register + offset). Using an Offset of Zero essentially meant to use 'modify' an instruction to use that registers content as address.

• Data length for string operations (character or BCD) on the other hand was fix coded into the second byte of such instructions.

  Changing that - for example to move a variable length input string or pack a variable length number was not possible. Sure, one could have used self modifying code, but while it was clear to everyone that this is a real bad idea (*3), it is as well simply impossible in a read only setup. So code executed from a ROM stack needed a way to vary the length field (*4).

  The EX instruction was created to solve this by alowing to executing an arbitrary instruction from program memory (*5) while at the same time ORing the lower 8 bits of a register with the second byte of the to be executed instruction.

  For example EXINST MVC 0(1,R4),0(r5) executed via EX R3,EXINST would essentially transfer as many bytes as R3 holds from the address pointed to by R5 to the one pointed to by R4.

---

*1 - In fact, one could even note that most post 1970 ISA are based on instructions so primitive that the only part that may need modification is are addresses which in turn are anyway held in registers, thus disabling all need for synthetic instructions.

*2 - A Third may be some constant (like the character in a CLI), but that's usually a rare case, as any constant can usually be replaced by a memory reference.

*3 - Already in the 1960s and way before any considerations about caching or performance at all. It adds countless pitfalls in usability, especially in stateless and/or multitasking situations, calling for synchronisation and so on.

*4 - No, noone in his right mind wants to write a multi instruction loop to handle strings - even less if the machine is able to do this in a single instruction, letting the microcode perform at maximum speed.

*5 - No not data memory. The Instruction to be executed is not data, but an instruction that has to follow all necessary rules for instructions, like aligned to half word, being in instruction memory, being in an executable section, addressing only reachable memory and so on.