Execution (computing)

Execution in computer and software engineering is the process by which a computer or a virtual machine carries out the instructions of a computer program. The instructions in the program trigger sequences of simple actions on the executing machine. Those actions produce effects according to the semantics of the instructions in the program.
Programs for a computer may execute in a batch process without human interaction, or a user may type commands in an interactive session of an interpreter. In this case the "commands" are simply programs, whose execution is chained together.
The term run is used almost synonymously. A related meaning of both "to run" and "to execute" refers to the specific action of a user starting (or launching or invoking) a program, as in "Please run the ... application."

Context of execution

The context in which execution takes place is crucial. Very few programs execute on a bare machine. Programs usually contain implicit and explicit assumptions about resources available at the time of execution. Most programs execute with the support of an operating system and run-time libraries specific to the source language that provide crucial services not supplied directly by the computer itself. This supportive environment, for instance, usually decouples a program from direct manipulation of the computer peripherals, providing more general, abstract services instead.

Interpreter

A system that executes a program is called an interpreter of the program. Loosely speaking, an interpreter actually does what the program says to do. This contrasts with to a language translator that converts a program from one language to another. The most common language translators are compilers. Translators typically convert their source language to a language that is simpler and faster to execute. The ideal is that the ratio of executions to translations of a program will be large; that is, a program need only be compiled once and can be run any number of times. This can provide a large benefit for translation versus direct interpretation of the source language. One trade-off is that development time is increased, because the programmer must re-compile the entire project (in most cases) to test every small change. As computers and compilers become faster, this fact becomes less of an obstacle. Also, the speed of the end product is typically more important to the user than the development time.
Translators usually produce an abstract result that is not completely ready to execute. Frequently, The the operating system will convert the translator's object code into the final executable form just before execution of the program begins. This usually involves modifying the code to bind it to real hardware addresses and establishing address links between the program and support code in libraries. In some cases this code is further transformed the first time it is executed, for instance by just-in-time compilers, into a more efficient form that persists for some period, usually at least during the current execution run.

Micro-execution

The machine language documented as the programming target for most computers is, in almost all cases today except, perhaps, for very simple processors, actually interpreted by a microprogram running inside the processor on the real hardware. There have been numerous attempts to design RISC computers that avoid micro-execution, but the distinction between complex and reduced instruction sets has tended to blur over time. A large factor in this "blurring" is that modern microcode processors reduce the speed difference between RISC and microcode by making extensive use of pipelining (an "assembly-line" approach in which instructions are interpreted at the same time others are executed.) The main distinction between this sort of micro-interpreter and an acknowledged software interpreter is that the microcode usually does not change. In the past microcode usually changed only slowly. The execution hardware today is sometimes implemented in field-reprogrammable logic, and execution schemes that modify the hardware dynamically to match the current requirements exist and may become increasingly common.