4.1 The Architecture

The Virtual Tcode Machine (VTM) consists of the following parts:

+---------------+ <----- high addresses ----> +---------------+
|               |                             |               |
|               |                             |     Stack     |
|               |       +-------------+       |      and      |
|               |   +---|     IP      |  +--->|    Dynamic    |
|               |   |   +-------------+  |    |    Storage    |
| Tcode Program |   |   |     RR      |  | +->|               |
|               |   |   +-------------+  | |  |               |
|               |   |   |     FP      |--+ |  |- - - - - - - -|
| Instructions  |   |   +-------------+    |  |               |
|               |<--+   |     SP      |----+  |               |
|               |       +-------------+       |    Static     |
|               |       |    SELF     |---+   |               |
|               |       +-------------+   |   |     Data      |
|               |          REGISTERS      +-->|               |
|               |                             |               |
+---------------+ <----- low addresses -----> +---------------+
   CODE ARRAY                                    DATA ARRAY

The Tcode machine does not have a fixed machine word size. The number of bytes per Tcode machine word depends on the host environment in which the VTM is running. However, a Tcode machine word must be at least 16 bits wide. The BPW constant (Bytes Per Word) specifies the Tcode machine size of a specific implementation. For example, in a 32-bit host environment, BPW=4. Each register of the Tcode machine has a size of one Tcode machine word.

There are two byte-addressable memory regions called the code array and the data array. The code array holds the Tcode program which is to be executed and the data array is used to hold the data used by the program. Each byte in either of the arrays is completely addressable using a single Tcode machine word.

In Tcode programs, only the non-zero bytes of each machine word are stored, but the number of bytes stored is always a power of 2 (1,2,4 bytes). Values that require more than four bytes cannot be stored in Tcode programs. Multi-byte values are stored in big endian order (0x12345678 = 0x12 0x34 0x56 0x78). See the following table for an overview.

At run time, VTMs may store machine words in any convenient format. Therefore, the result of accessing individual bytes of a machine word is undefined. When a Tcode machine word is wider than the number of bytes stored in a Tcode program, the Tcode machine must sign-extend the value after loading it. When a Tcode machine word is not as wide as a value to load, range checking must be performed: a value may only be truncated, if all bytes that would be cut off contain a pattern of either all zeroes or all ones. For example, the 32-bit value 0x00007FFF may be truncated to 0x7FFF in a 16-bit environment, because both 0x00007FFF on a 32-bit host and and 0x7FFF on a 16-bit host represent the decimal number 32767. The prefix 0xFFFF may only be removed, if the sign of the truncated value is negative, too. For example, 0xFFFF8001 may be truncated to 0x8001, because 0xFFFF8001 on a 32-bit hosts equals 0x8001 on a 16-bit host. On the other hand, 0xFFFF0000 may not be truncated, because 0xFFFF0000 represents -65536 on a 32-bit host, but removing the 0xFFFF prefix yields zero.

Note: Of course, truncating 0x00008001 to 0x8001 is dangerous, because 0x00008001 represents 32769 on a 32-bit host while 0x8001 is interpreted as -32767 on a 16-bit host. However, this ambiguity is accepted, because 0x8001 may as well be interpreted as 32769 on a 16-bit host and additional effort would be necessary to allow a destinction between these values. Of course, this means that special care must be taken when coding values in the ambiguous range from 32768 through 65535.

The Tcode machine has five special purpose registers which are outlined in the following overview.

FP, the Frame Pointer.
The frame pointer points to the stack frame (aka context) of the currently running procedure. FP is implicitly referenced by the instructions LDL, LDLV, SAVL, and INCL, which address local objects. FP is modified only by HDR, END, MHDR, and ENDM instructions. See also calling conventions.

IP, the Instruction Pointer.
This register points to the instruction which will be interpreted next. IP is interpreted as an offset into the code array. It cannot be accessed directly and it is changed by jump, call, and branch instructions.

RR, the Return Register.
This register is used to transport procedure results back to the caller. The return register is loaded by the POP instruction and saved by CLEAN. See also calling conventions.

SELF, the class context pointer.
SELF points to the instance context which is currently in effect. This is equal to the first byte of the data space of the object which is currently receiving a message. Instance contexts are static. They are established using MHDR and released using ENDM. The SELF register is used by the LDI, LDIV, and INCI instructions to compute the addresses of instance variables. See also instance contexts.

SP, the Stack Pointer.
The stack pointer points to the object most recently placed on the stack. Moving an object onto the stack implicitly decreases SP by one machine word. Removing an object increases it by one machine word. SP may be explicitly modified using the STACK instruction.

The Tcode machine instructions can be divided into the following nine groups:

• declarations
• context manipulation
• stack manipulation
• arithmetics
• predicates
• loading and storing
• flow control
• external linkage
• source level debugging

Declarations, external linkage, and debug instructions will be processed only once (therefore, they may be resolved in a preprocessing step). This means that an instruction like

STR 5 H e l l o

will not create a new string literal each time it is interpreted, but only at the first time. (One might also think of this behaviour as creating the same object each time a declaration executed).

Arithmetic instructions and predicates expect their arguments on the runtime stack and place their results on the stack, too. Since there are no general purpose registers, most operations are performed on stack elements.