[op: [0..255]] -- 1 byte

{ADD, BNDCK, DIS, DUP, EXCH, EXDIS, J1, LCn, MDIV, MUL, RDIV, RETN, RETT, SFC, SFCI, SJ, SUB, UDIV, UMUL}

For OI instructions the operand (if any) is implicit in the opcode.

[op: [0..255], lit: [0..255]] -- 2 bytes

{ADDB, ARL, AS, ASL, CST, EP, IN, J2, JB, LEUR, LIB, LIFUR, OUT, PSB, RB, RET, RSB, SEUR, SIFUR, SUBB, WB, WSB}

For OB instructions the operand is given by AlphaZ or AlphaS.

[op: [0..255], lit: [0..65535]] -- 3 bytes

{ADDDB, FSDB, J3, JDB, LFC, LGF, LIDB, SHL, SHR}

For ODB instructions the operand is given by AlphaBetaZ or AlphaBetaS.

[op: [0..255], addr: Word] -- 5 bytes

{DFC, J5, LIQB}

For OQB instructions the operand is AlphaBetaGammaDelta.

[op: [0..255], dist: [-128..127], lit: [0..255]] -- 3 bytes

{JEBB, JEBBJ, JNEBB, JNEBBJ}

For JBB instructions the new PC is the byte address given by PC+AlphaS. BetaZ is used for comparison with the top of stack.

[op: [0..15], reg: [0..15]] -- 1 byte

{LRn, SRn}

For LR instructions the operand is Locals[reg], which is either pushed to or popped from the stack.

[op: [0..15], reg: [0..15], disp: [0..255]] -- 2 bytes

{LRIn, SRIn}

For these instructions, the operand is (Locals[reg]+AlphaZ)^, which is either pushed to or popped from the stack.

[op: [0..255], disp: [0..255], reg1,reg2: [0..15]] -- 3 bytes

{RAI, RRI, WAI, WRI}

For all instructions, reg1 (BetaL) indicates a local register. For RRI and WRI, reg2 (BetaR) indicates a local register as well. For RAI and WAI, reg2 indicates an auxilliary register.

[op: [0..255], c,a: [0..15], aOpt,cOpt,bOpt,aux: BOOL, b: [0..15]] -- 3 bytes

{RADD, RAND, RBC, RFU, ROR, RRX, RSUB, RUADD, RUSUB, RVADD, RVSUB, RXOR}

For these instructions the effect is roughly Rc←Ra op Rb. SE is used to indicate the effect of the instruction on S. SE𡤀 at the start of the instruction, and S←S+SE at the end of the instruction.

Ra: IF NOT aOpt

Rb: IF NOT bOpt

Rc: IF NOT cOpt

[op: [0..255], dist: [-128..127], sdd,sd,opt,aux: BOOL, reg: [0..15]] -- 3 bytes

{RJEB, RJEBJ, RJGB, RJGBJ, RJGEB, RJGEBJ, RJLB, RJLBJ, RJLEB, RJLEBJ, RJNEB,RJNEBJ}

For these instructions the effect is to jump to the byte PC given by PC+AlphaS if the indicated comparision of Ra with Rb is true. Beta is decoded as much as possible in the same way that Beta is decoded for the RR format instructions. The comparision is always made involving either [S] or [S-1] with a register determined by the decoding of Beta. SE is used as in the RR format description.

IF sdd THEN SE←SE-1

Ra: IF sd THEN Stack[S-1] ELSE Stack[S]

Rb: IF NOT opt

The simple case of calling a procedure first pushes any arguments expected by the procedure, then calls the procedure via DFC or LFC. The first instruction is normally an EP instruction, which sets L to the base of the arguments. Therefore, the arguments become the initial local variables without moving those arguments.

The return PC and the return L are pushed onto the IFU stack by the call. If there is insufficient room to do this, an IFU stack overflow trap is taken after the call has transferred control.

If the procedure needs access to a global frame, then it is the responsibility of the procedure to setup a register with the pointer to the global frame. Current plans are to use the LGF instruction to load the global frame pointer from the global frame table into a local register. The LIQB instruction could be used to setup the global frame pointer in the case where there are few procedures for the frame, but space considerations will normally make it more desirable to use the 3-byte LGF instead of the 5-byte LIQB, since that will save 2 bytes per procedure.

The simple case of returning from a procedure uses the RET opcode, which specifies how much to adjust the stack before returning. If the IFU stack is not empty, then the return PC and L are taken from the IFU stack, and the most recent entry in the IFU stack is discarded. If the IFU stack is empty when a RET is performed, the results are undefined. S is adjusted according to the alpha byte. For cases where the stack should not be adjusted on return the RETN opcode is used.

For various reasons covered below, procedure variables are called with one more level of indirection than simple procedures. Procedure variables are implemented as pointers to words that contain the starting address of the procedure. To call through a procedure variable, the procedure variable is pushed, then a call is made to ([S])^ using SFCI. This convention leaves an extra word on the stack, so procedure variable calls must go to a different entry point than simple procedure calls.

Nested procedures are implemented by placing the starting address in the local frame extension (the part of the local frame required to be in memory). The procedure variable for this nested procedure will be a pointer to this word. Therefore, on entry to the nested procedure, the address of the frame (plus an offset) will be on the stack, which makes computing the static link easy (a SUBB instruction).

Interface function calls are both more flexible and more involved than simple procedure calls. Interface records are referred to via positions in the global frame. Procedures exported through those interfaces have procedure variables in various slots of the interface record. To make an interface function call one simply sets up the arguments, fetches the procedure variable from the interface record, and performs a procedure variable call.

Although procedures must be specially compiled to use multiple global frames, there is no additional mechanism beyond forcing all calls to routines with multiple global frames to use the indirect procedure call. The address on top of the stack can then be used to find the global frame (probably via adding a constant).

Coroutine calls are handled by traps. The data structures to be used are not yet defined. However, co-routine calls will be roughly as expensive as process switches.

The reschedule trap occurs when the RESCHEDULE line is raised and interrupts are enabled. An attempt is made to have idle processors notice the RESCHEDULE line before non-idle processors (this is controlled by software). If the RESCHEDULE line is raised while interrupts are disabled, the reschedule trap will be deferred until interrupts are enabled again. The response to the reschedule trap is quite complex, and will not be covered in this note.

The stack overflow trap occurs when an attempt to increase the EU stack pointer by 1 (S←S+1) would result in S crossing the stack overflow limit register (and traps are enabled). The limit, which is set by software, must allow sufficient room for the trap handler. The handler for this trap should migrate the eldest frame in the EU and IFU stack registers to memory, then return via RETT.

The IFU stack overflow trap occurs when an attempt to call a procedure when the IFU stack is full (and stack overflow is enabled). Some number of IFU frames are still available after this trap occurs, so calls can be made by the trap handler. The handler for this trap is the same as for EU stack overflow.

The stack underflow trap occurs when a return instruction (RET, RETN, or RETT) tries to return to an empty IFU stack. The trap handler must arrange to migrate a frame from memory to the IFU and EU registers. This is not a true trap, since the IFU stack is left empty on entry to the handler. When the transfer takes place, maskable traps are disabled.

The ALU fault trap occurs when the ALU detects integer overflow, a bounds check (due to the BNDCK instruction) or a NIL check (due to the NILCK instruction), or Lisp NaN. The handler for ALU fault should turn this trap into the appropriate error, depending on the instruction that raised the fault.

The EU page fault trap occurs when a reference to unmapped memory is made by the EU. The faulting address is available through a special EU register (MAR). The handler should determine if the page is valid, then either cause the page to be made present, or cause a page fault error. Interrupts are disabled during the trap handler.

The IFU page fault trap occurs when a reference to unmapped memory is made by the IFU. The faulting address is available as the return PC. The handler should determine if the page is valid, then either cause the page to be made present, or cause a page fault error.