Language oriented instructions sets: makes compilation simpler, helps portability and the level abstraction introduced simplifies the task of native code generation (if required) or allows direct interpretation.
A prototypical byte code interpreter might look like this:
switch code[pc++] {
case instruction0:
...
case instruction1:
...
...
case instruction255:
...
}
Of course, byte-code interpretation has a cost, typically put at about
a factor of 10 over native code, although it can be as low as 2. An
initial reaction to designing a byte-code instruction set might be to
make each one simple, so that its execution be quick. Perhaps
surprisingly, this is not a good strategy, since the more intructions
that are executed, the higher the proportion of time spent in the
interpreter and the lower the proportion spent doing work for the
program being interpreted. In consequence, it is better to make each
instructions do as much work as possible, ie. a complex instruction
set, which is contrary to the trend in hardware. However, this is not
necessarily easy and there has been some interesting work on the
static and dynamic behaviour of simple instruction sets to
synthesize more complex ones.
Designed for Pascal. Implemented as a micro-code on the ICL PERQ. Variants/extensions for Modula and Oberon. Special instructions for range checking (CHK) and for non-local variable access (LDA). Stack model, suitable for byte-code interpretation. Also interesting are ORD, SQI, SQR. See handout.
Conceived for Lisp-shows its age-small set of relatively general instructions (note freedom of operand forms). Register model, unsuitable for interpretation because the overhead of operand decoding is too high. See handout.
The only fast way to execute Prolog. Uses four stacks: heap, stack (locals), trail and push-down list or PDL (saved bindings).
Actaully a finite state machine for interpreting programs (primarily functional, but not necessarily). Control can be any kind of instruction sequence as long as you define the transition tuples to go with it (see Henderson, Functional Programming). See handout. Devised by Landin-earliest example of a VM-[Landin, 1964]. This version is based on the description appearing in Field and Harrison. Note this is an applicative order machine, ie. call by value; it can be modified to support call by need.
The state of the SECD machine is stored in four stacks: store, environment, control and dump. The entire machine can be described in terms of the movement of data between these stacks. The main data structure is the closure, which is a 3-tuple of identifier, expression and environment (set of bindings). The execution cycle is described in detail in the handout.
In the example, we are computing (twice succ) 0, where twice = lambda f . lambda x . f(f x) and succ = lambda x . + x 1, therefore the result should be 2. In consequence, the input expression is (comb (comb twice succ) 0).
An object-oriented language, which was byte-coded from the start (micro-code on Alto, Dorado, and later on 68K etc.) Byte code is OO. For full details see [Goldberg \& Robson, 1985]. Byte codes come in four classes:
CISC and RISC. RISC philosophy. Co-processors. Hardware trends. Multiprocessor architectures: shared (Unix boxes) versus distributed memory (transputers and i860). Multiple instruction multiple data. Single instruction multiple data (vector and array processors). Superscalar/pipeline architectures.