Putting Instruction Sequences into Effect

An attempt is made to define the concept of execution of an instruction sequence. It is found to be a special case of directly putting into effect of an instruction sequence. Directly putting into effect of an instruction sequences comprises interpretation as well as execution. Directly putting into effect is a special case of putting into effect with other special cases classified as indirectly putting into effect.

💡 Research Summary

The paper “Putting Instruction Sequences into Effect” tackles the long‑standing problem of giving a precise, technology‑independent definition of what it means to execute an instruction sequence (ISE). The author begins by introducing a very general notion, “Putting an Instruction Sequence into Effect” (PISiE), which denotes any mechanical process that transforms a static instruction sequence into observable behavior. PISiE is deliberately broad: it includes direct execution, interpretation, compilation, just‑in‑time (JIT) compilation, and even manual manipulation of the sequence.

From this umbrella concept the author extracts a more specific subclass, “directly putting an instruction sequence into effect” (dPISiE). The defining property of dPISiE is that the process does not rely on any other instruction sequence to bring about the effect. Within dPISiE two mutually exclusive sub‑categories are distinguished:

1. Execution – the instruction sequence runs directly on hardware (or an equivalent low‑level substrate) without any intervening transformation. The hardware itself implements the semantics of the sequence; no other program is consulted.

2. Interpretation – the sequence is realized by invoking another instruction sequence (the interpreter). The interpreter itself is a program that reads the original sequence and performs the prescribed actions on its behalf. Although interpretation is still a dPISiE activity (because it is a direct mechanical process), it is not considered “execution” in the strict sense.

The paper then defines “indirect PISiE” as any method that involves a preparatory transformation, such as compilation, static analysis, or JIT. These methods break the directness condition and therefore fall outside dPISiE, even though the overall workflow (compile‑then‑run) is still a PISiE.

A central theoretical contribution is the introduction of executionality, an informal metric that quantifies how “execution‑like” a given PISiE method is. Executionality takes into account factors such as:

• Directness (absence of intermediate programs)
• Use of physical hardware versus virtual machines
• Presence of runtime code generation or JIT steps
• Degree of mechanical automation

A method with maximal executionality is identified as the genuine execution of the instruction sequence. This allows the author to compare, for example, a pure hardware run, a virtual‑machine interpreter, and a JIT‑enabled runtime on a common scale, clarifying when a technique should be called execution, interpretation, or merely a form of indirect effect.

To ground the terminology, the author compiles a comprehensive table of 36+ phrases commonly found in the literature (e.g., “run”, “test”, “compile‑and‑execute”, “sandboxed execution”, “service provision”, “debugging run”). For each phrase the paper specifies whether it belongs to PISiE, dPISiE, execution, interpretation, or is outside the scope (e.g., simulation, manual execution). This taxonomy resolves many ambiguities that arise when authors use overlapping terms without explicit definitions.

The discussion also addresses philosophical and practical constraints. The author argues that a uniform, purely formal definition of execution is impossible because execution semantics evolve with processor architectures. Instead, the notion of execution should be tied to the concrete mechanical behavior of a given architecture, and the executionality metric provides a flexible, architecture‑dependent yardstick.

Finally, the paper outlines several “requirements” that any satisfactory definition of PISiE/dPISiE should satisfy, such as:

• Every execution is an instance of dPISiE.
• Every interpretation is an instance of dPISiE but not of execution.
• Compilation followed by execution is PISiE but not dPISiE.
• Manual or simulated runs are not executions.

These requirements are presented as sanity checks for future formalizations.

In conclusion, the work offers a layered conceptual framework:

• PISiE – the most general mechanical effect.
• dPISiE – direct mechanisms, split into execution and interpretation.
• Executionality – a comparative measure to decide which dPISiE instance qualifies as “true execution”.

By formalizing these distinctions, the paper bridges the gap between theoretical computer science (where programs are often treated as abstract mathematical objects) and practical system engineering (where the nuances of hardware, virtual machines, and runtime transformations matter). The framework is poised to influence the design of instruction‑sequence languages, compilers, virtual machines, and performance‑analysis tools, providing a clear vocabulary for discussing “what it means to run a program” across diverse computing platforms.