Text preview for : OISPrincOps_V2_Apr1977.pdf part of xerox OISPrincOps V2 Apr1977 xerox dolphin OISPrincOps_V2_Apr1977.pdf
Back to : OISPrincOps_V2_Apr1977.pd | Home
The OtS Processor Principles of Operation
REVIEW DRAFT - COMMENTS PLEASE
April 9, 1977
Version 2.0
This document describes the interior architecture of the OIS System Element Oigitai
Processor. It includes a description of the virtual storage system, the in'struction set,
and the input-output facilities.
r-
Table of Contents
In trod uction iki.:2""bi
Information f ormatsbyntactie conventions
Number system
Special Characters z
Terms 2
Virtual Storage
Introduction
Mesa's Use of the Virtual Memory System
Address Translation
Requests
Operations on the Map
Mapping Examples
Poi n t er Formats
Central Processor
Data Structures and Associated Registers 9
Code Segments 9
Global Frames 10
Local Frames 10
System Dispatch 10
Global Frame Table 10
Allocation Vector 10
I
The Processor Stack 11
The Machine State 12
I
L Insmction Forniat and Classes
Load /S tore Instructions 14
Load/Store Gt ohal Word 15
Load/Store Local Word 16
Load Immediate . 17
L-oad/ St o re GIo bal DoubleVJo rd 18
Load/Store Local Doubleword 18
Read/Wri te Word 19
Read/W rite Doubleword 21
Read/Wri te Indexed 23
Read/Write Indirect 24
r-
26
Id Rec?d/\Nrite String
Read/Write Field 27
f ---
i
Data Modification Instructions - 30
Jump Instructions 36
Unconditional Jumps 36
Conditionai Jumps 36
Jump Indexed ByteIWord 41
i FOR Loop Control lnstructions
Miscellaneous lnstructions
Bit Boundary Block Transfer
42
43
48
Display Bitmap Format 48
Font Format 48
BitBLT 49
BitBLT Examples 50
Extensions to BitBLT 50
i Control Transfers
Control Links 51
Procedure Descriptors 51
I Stored Program Counters
Franie At location
52
52
XFER 55
Control Transfer Instructions 57
Local Function Calls 58
Global Function Calls 58
Stack Function Cali 59
Kernel Function Call 60
Return 60
Port Out 60
Port In 61
Traps
Types of Trap 62
i Trap Processing
Rrea kpoin ts
63
64
Process Switching .
Process States 65
R cg ist ers 66
Sc lied I]le r 66
Iiitcrrtqtibie Isistructioiris 68
Errors and Error ISandting
Types o f Crrors
4 69
Error Logging 69
Software Notification o f Errors 70
Restart Register 71
r ---
L
r-
I '
f --
Input-Output
1n t roduct ion 72
Common I/O Handling 72
Controllers and Devices 72
1 0 Addresses, Priorities, and the 110 Page
1 73
In put /Output Instructions 74
Process Wakeups 74
Channel I/O Operation 75
Cont ro I Information 75
initiation 75
Data Transfer 75
Termination and Process Wakeups 76
Status Information 76
Dedicated Addresses and Functions 77
I/O Page Block 0 77
I/O Page Block 15 77
Block 0 I/O Registers 78
Block 15 I/O Registers 79
Block 1 through 14 I/O Registers 79
I/O Control1er ConTigurat ion 79 .
Appendix A: Opcode Summary, Processor Constants
Figures
1
Introduction .
This document describes the interior architecture of the 01s System Eiement
Digital Processor. It includes a description of the virtual storage system, the
instruction set, and the input-output facilities.
It is required that all System Element Digital Processors implemented for 0 s be
1
compatible with this architecture. This will allow common software systems to be
constructed which will operate on all members of the family, as well as providing
for a common input-output interface. It will also allow reimplementation of the
processor to occur when it is economically advantageous.
This document does not specify an implementation for any instance of the 0 s 1
processor; It does specify those principles which must be adhered to to
guarantee software compatibility at the instruction set level, and input-output
compatibility at the level of the devices.
This document will be modified from time to time, as implementation of the initial
instances of the OIS processor family occurs, and the Mesa language
implementation is refined. We expect to stabilize both the architecture and this
document in early 1977, so that final product development may proceed without
significant impact from them.
! il
-___I--
-
--
2
Jnformation Forms and Syntactic Conventions
Throughout this document, a number of conventions are used, which are described
in this section.
Number system
Numeric quantities are expressed in decimal unless otherwise specified. The
suffix B is used to indicate octal.
* is used to indicate multiplication, * * is used to indicate exponentiation:
5D3 = 5000 = 51"
'03
3B5 = 300000B = 3'8"5
For large multiples of a power of 2, K is used to designate 2**10, and M is used to
designated 2**20:
32K = 32'2'*10 = 2*'15 = 32768,
1M = 1'2"20 = 2"2O = 1048576
Speciai Characters
means "contents of x".
Square brackets [ ] are used to indicate indexing or to delimit the arguments of a
function:
x[3] = means the contents of lcation x+3, i.e. the third element of the vector x
hfC2) means the value returned by the function hf with argument 2.
Double commas are used to indicate the concatenation of two fields. If x is a 3-bit
field and y is a 5-bit field, then x,,y is an eight-bit field with x in its high order bits.
Terms
a; word is a sixteen bit quantity. Bit 0 is the most significant bit, bit 15 is the least
significant bit. When diagrammed, bit 0 is on the left.
A doubleword is a thirty-two bit quantity, with bits numbered from 0 to 31. In main
storage, the least significant bits (16-31) of a doubleword are stored in location n,
the most significant bits (0-15) are stored in location n + l . When a doubleword
appears on the evaluation stack, the most significant bits are on the top of the
stack, the least significant bits are in the second position.
A byte is an eight bit quantity. Bit 0 is th? most significant bit, bit 7 is the least
significant bit. When diagrammed, bit 0 is oil the left.
A field is a contiguous group ,of bits within a word or larger field. The bits are
numbered from the left starting at 0. For example, the field consisting of the least
significant byte of x is indicated with x[8:15). If the field is named, the contruct
p.f, where p is the address of the word containing the field and f is the field name,
is sometimes used to represent the value of the field.
i_ 3
I A pointer is the address (or displacement from a designated base address) of the
first location of a contiguous region of virtual memory. There are a number of
different formats for pointers which are described below.
il A p a g e is a contiguous block of 256 16-bit words, the first word of which begins
at an address which equals 0 mod 256.
L- A Procedur e is a body of code which performs a single function.
c A Code Segment is a collection of procedures which are compiled together.
A Process is a group of operations and the data on which they operate which can
(at least conceptually) execute in parallel with other processes. A process is
il defined by the contents of memory and by a state block which is loaded into the
processor registers when the process is run. All processes supported by the 0 s
processor share a common virtual address space.
1
i A Main Data S p a c e (MDS) is a contiguous region of virtual memory associated
with one or more processes. It has a maximum size of 64K words, and wili be
described in detail in subsequent sections.' By hardware convention i t always
L begins on a page boundary, hence its address is always 0 mod 256. MDS will be
used as the abbreviation for Main Data Space, mds as the designator of the
c register which points to MDS, and mds pointer as defined below.
L
1L I
4
Virtual Storage.
Introduction
All implementations of the OIS Processor will provide a virtual memory system
(VMS) which supports a linear virtual address space of 2**24 sixteen-bit words.
This will allow the detvelopment of complex software systems which are, to a large
extent, configuration-independent.
The virtual memory system has several purposes:
It provides address translation between virtual addresses generated b y a
program and real memory addresses used by the memory hardware.
It provides dynamic refocation of information so that objects need not
occupy fixed locations in main storage throughout their existence, but may
be moved between secondary storage and any unoccupied area of main
storage as required.
It provides protection for areas of the address space. Although many of
the protection mechanisms normally provided by hardware are provided in
the 01s envilronment by the Mesa compiler's type checking machinery,
some degree of protection in the hardware is desirable, primarily to detect
errors rather than to defend against hostile action.
There are four primary components of the virtual memory system: First, there
must be hardware and/or firmware to do the address translation. Second, there
must be storage for the translation information. Third, there must be a secondary
storage device which holds the majority of the information contained in the virtual
space. Finally, there is a body of software, usually associated with the operating
system, which is responsible for transferring information between main and
secondary storage.
Mesa's Use of theWrtual Memory System
The OIS processor instruction set h a s been designed for efficient execution of the
Mesa language, which will be used for all 0 s programming. A primary Mesa
1
design goal was to provide a space-efficient representation for code. As a result,
a large fraction of the memory reference instructions make use of implicit or
explicit base registers which point to frequently referenced structures. Thus, the
amount of address information required in an instruction is small. In addition,
several commonly referenced structures are constrained to begin on (256 word)
page boundaries in memory, and can thus be represented by sixteen-bit pointers
rather than full addresses.
Although the instruction set makes use of a number of formats for addresses, all
are short forms of a full 24-bit virtctal address. There is no method specified to
bypass the address translation process and directly reference a real main storage
location.
I
L 5
Address 'rranstat ion
The address translation process is identical for all memory references, i.e. for .
instructions, operands, and I/O operations.
The CPU generates a 24-bit virtual address, usually by adding one or more offsets
to an implicit or explicit base register. The generation of this effective virtual
address is described later in this document for each instruction.
The 24-bit address is then passed to the address translation hardware, which wilt
attempt to translate i t into a real storage address. If the translation is successful,
and if no access protection checks are violated, the reference is made and
execution continues. If a protection violation occurs, the memory management
software will be notified via a trap, and the offending instruction will not be
executed .
Since all operations are implemented such that they can be restarted i f a memory
fault occurs, the memory manager can simply bring the required information into
main storage and restart the offending instruction. The interface between the
translation hardware/firmware and the memory management software is thus
reduced to two traps, Page Fault and Write Protect, and the Mesa instructions
required to manipulate the map.
All implementations of the processor must provide a virtual address space of not
less than 22 bits, and there must be a mechanism (described later) to report the
maximum size of the virtual space in a particular model to the software, as well as
a provision for causing a PageFault trap on any attempt to reference locations
.[I outside the virtual space provided.
Translation between virtual addresses generated by the processor or I/O system
and real addresses used by the memory is done by a map implemented in
hardware. The map accepts a 24-bit virtual address from the requester, and
delivers a real address to the storage modules. The real address is from 18 to 20
[I bits, depending on the amount of real storage provided in the particular model.
Mapping takes place in one page (256 word) quanta, i.e. the least significant eight
bits of the virtual address bypass the mapping hardware.
In addition to the information necessary for address translation, the map also
contains three bits, Dirty, Write Protected, and Referenced, which provide the
memory management software with information about eacn page. The Dirty bit is
set by the mapping hardware when a store is done to a non-write protected page.
The Write Protect bit prohibits stores into a particular page, and reports an error if
a store is attempted. The Referenced bit is set when any access is made to a
Page.
I I
6
Requests I
The memory system is capable of accepting four types of requests: I10 fetches,
I10 stores, Processor fetches, and Processor stores. Error conditions arising from
these requests are reported to the requester in one of two ways. If the request
came from an I10 device controller, the controller is notified that an error
occurred, and the reference is not done. controller will take whatever action
is required (usually halting the data tra , and will report the error to the
processor in its next status re rror arose as a result of a Mesa
instruction or operand reference trap will be generated. The trap parameter
for all memory-related traps is t -bit virtual page number.
When a request is received by the memory system, the address is range checked
(in configurations providing less than 24 bits of virtual space), then sent to the
map. The following table shows the possible outcomes for a request based on its
type and the original state of the flag bits.
Map flag bits: Request Type / Result (W,D,Ref):
(W,D,Ref) ' Processor Processor 1/0 I/O
Fetch Store Fetch Store
0 0 0 001 0 1 1 0 0 1 0 1 1
0 0 1 00 1 0 1 1 00 1 0 1 1
0 1 0 01 1 0 1 1 0 1 1 0 1 1
0 1 1 01 1 0 1 1 01 1 0 1 1
1 0 0 10 1 1 0 0 (1) 1 0 1 1 0 0 (2)
1 0 1 10 1 1 0 1 (1) 1 0 1 1 0 1 (2)
1 1 x (3) 11 x (4) 1 1 x
(4) 1 1 x
(5) 1 1 x (5)
( 1 ) Inhibit t h e store.
Cause t h e WriteProtect trap.
( 2 ) Inhibit the store. Return violation to t h e I/O controller, which reports it in its status.
(3) This state mealns vacant, i.e. the requested virtual page is not in real memory.
( 4 ) Page is not in real memory, cause PageFault trap.
(5) Page is not in real memory. Return violation to I/O controller, which reports it in its status.
Operations on the Map
The processor will provide two operations for dealing with the map (as Mesa
instructions). In what follows, v is a 16-bit virtual page number, r is a 12-bit real
page number, and f is the 3-bit flag value:
9
Associate[r.v.f] Makes a correspondence in t h e map between real page r and virtual page
v, and sets the flag bits in t h e map entry to f .
SetFlags(v,f) Sets :tie flag bits associated with t h e map e n t r y for virtual page v to f , and
returns the old value of t h e flags. If the entry for v is not in t h e map or is not currently
associated with i: real page, the @peration r e t u r n s vacant (old flags = 6). T h e operation
consisting of readitiy the old flags and setting the new value must b e indivisible. 1 , , 'P ;A, d e i A;, \ '
i'sj p ;*Ib,: ,
t; t '
The software must not attempt to map two Gifferent pages in the virtual space into
tad&
$1;
the same real page (restriction imposed by associative implementations}.
i 7
i Mapping Examples
To bring virtual page v into main storage, the software will do:
i Obtain a free real page, say page r. .
Associate[m,r,O] -- Map r into a virtual page m known only to the memory manager. This
il `hides' the page from all software other than the memory manager during the time the page
is being read in from the disk.
Read the page from the disk into m.
i Associate[m,r,vacant] -- Remove the page from m.
Associate[v,r,new flags] --Make the page available to the requester.
i To remove a virtual page v from real page r, the software will do:
il -
OldFlags +- SetFlags[v,r,WriteProtectedl
-- If
i f 0ldFlags.dirEy then Writepage[ ...I the page was dirty, write it to the disk. Since the
page is now write protected, no stores into the page are possible during the write.
SetFlags[v,vacant] -- Release the page
The software will require one or more auxiliary tables which contain information
about the allocatioin and state of virtual and real storage. These structures need
not be known to tlhe hardware in any manner.
-- 3
8
I . ,
'@- . :
Pointer Formats %,,b,+,.-
I
All addresses generated by the processor are 24-bit virtual addresses. These ,
addresses are stored in a variety of ways, and specific terms are used to describe
each format. This section describes the various pointer formats and the terms
used for them. This information is also shown schematically in figure 1.
A 24-bit pointer is a doubleword which contains the 24-bit virtual address
in bits 8-31. Bits 0-7 are zero.
A page pointer is the most significant sixteen bits of a 24-bit~virtual
address. Page pointers are stored in a single word.
The 0 s processor supports a number of processes, each of which has
1
associated with it a Main Data Space. The MDS is a 64K word (maximum)
region of the virtual space which is pointed to by the register mds. Note
that althougih each process has only one MDS, a number of processes may
share a particular MDS. Since an MDS is constrained to begin on a page
'boundary by hardware convention, mds contains a page pointer. Since
many operations make use of 16-bit displacements which are added to mds
to form a Pull 24-bit virtual address, we will make use of the term mds
pointer to describe such a displacement. There is nothing unique about an
mds pointer - the term is used solely for brevity to indicate-that the pointer
is a 16-bit displacement relative to the page pointer content of mds.
A 32-bit pointer is a doubleword containing a page pointer in bits 0-15, and
a word displacement relative to the start of the page in bits 16-31.
The term long pointer is used when an operation will accept either a 24-bit
or a 32-bit pointer. To allow the pointer type to be determined from its
value, the convention is used that no object which may be described by a
32-bit pointer will be placed in the first 64K of the virtual space. Thus, if
bits 0-7 of a long pointer are zero, the pointer is a 24-bit pointer,
otherwise it is a 32-bit pointer.
9
Central Processor
Data Structures and Associated Registers
The Mesa languagie makes use of a number of structures with &fined formats
which are known both to the control transfer instructions (hardware) and to the
compiler. The location of a numberdof these structures relative to the beginning of
MDS or relative to the beginning of virtual memory are given by constants whose
values are given in Appendix A (in most cases, the precise values of these
constants have not been determined at present. Where this is the case,
approximate values are given and the approximation i indicated).
s These
structures are shown in figure 2, and include:
Code Segments (C Register)
A code segment contains the instructions for a group of procedures which were
compiled as a unit (a module), plus an entry vector which contains the information
necessary to find the code associated with each procedure in the module and to
I
allocate a local frame of the appropriate size for the procedure. The register C
contains a 24-bit pointer to the base of th& currently active code segment.
In most cases, the information required to find the code associated with a
procedure (the entry vector item) occupies a single word in the entry vector:
bit 0: 0
bits 1:4: Frame size index
bits 5 1 5 : C-relative byte pointer to the code for this entry
In this case, the frame size index must be such that it can be represented in four
bits, the code must lie within 2048 bytes of the base of the code segment, and the
proj%!hure must not have any defaulted parameters. If this is not the case, the
entry vector item has a different format:
bit 0: 1
bits 1:15: C-relative word pointer to t h e code for this entry
For this format, the code must lie within 32K words of the base of the code
segment, and the code must start on an even byte. The remaining information
required to run the code is contained in the word which precedes the code itself:
bits 0:3: Information for defaulting parameters (mechanism unspecified as yet).
bits 4:15: Frame size index. This number is either the frame size index or the size of the
frame (in words) if fsi>MaxAllxSlot-l (see "Frame Allocation")
Since the code pointer (the initial PC) is a byte pointer, and is held in a 16-bit
word the maximum size of a code segment is 2**16 = 65536 bytes or 32768
words. Further, since the code segment-4s pointed to by a 24-bit pointer it is
generally (by software convention) disjoint from all Main Data Spaces. The
maximum size of a frame is limited by this mechanism to 4096 words.
By software convention, code segments are read-only, and are modified only by
the Mesa debugger's breakpoint machinery.
10
Global frames (G Register)
A global frame is a designated area in MDS. It contains a 24-bit pointer to a code
segment, and contains all global variables and external linkage information required
by an instance of that code segment. The register G contains an mds pointer to
the currently active global frame.
Global frames are created each time that an instance of a module is required. This
may occur dynamically at runtime, but usually will be done only when a number of
modules are bound into a functional configuration. There may thus be more than
one global frame per code segment.
Local Frames (L Register)
A local frame is a designated area in MDS. It contains all the local state for a
procedure. It is created when a procedure is called, and destroyed (usually) when
the procedure returns control to its caller. The register L contains an mds pointer
to the currently active local frame. The local frame contains all the information
required to continue execution of a procedure whose execution was suspended
(when, for example, it calls another procedure).
System Dispatch (sd)
The system dispatch table occupies the same designated area in every MDS. The
constant sd specifies the offset (in all main data spaces) of the system dispatch
table. The system dispatch table contains control links for commonly used runtime
procedures, and is used only by the KFCB instruction and by traps.
Global Frame Table (gft)
The global frame table occupies the same designated area in every MDS. The
constant gft specifies the offset (in all main data spaces) of the global frame table.
Each entry in the global frame table is an mds pointer to a global frame (G). The
global frame table is accessed by using the GFT index portion of a standard
procedure descriptor (see "Control Links").
Allocation Vector (av)
The allocation vector occupies the same .designated area in every MDS. The
constant av specifies the offset (in all main data spaces) of the allocation vector.
The allocation vector is used primarily for dynamic allocation of local frames. A
pool of frames of the most frequently used sizes is maintained by the software.
This pool is accessed via the allocation vector av, each entry of which is the head
of a list of frames of a fixed size. The frabe size index in the entry vector of a
code segment provides an index into the allocation vector which is used to locate
a frame of the required size when a procedure is entered. The frame itself
contains this index as well, so that i t can be returned to the appropriate iist when
the procedure returns. There is a mechanism for indirection which allows the last
frame in a list to point to the list for some larger frame. size (see "Frame
Allocation"). An attempt to allocate a framg from a totally empty list results in a
trap.
- _
I
1 I I
The Processor Stack
Many of the roles normally filled by central registers or accumulators in some
machines are filled in the OIS processor by the processor stack. This stack is an
array of sixteen-bit registers accessed indirectly via a pointer register stkp.
The precise number of registers in the stack has not yet been deternined. In this
document, the parameter stkmax is used to designate this value.
The registers comprising the stack are designated stk[ 1] through stk[stkmax].
The instruction set makes use of two prmitive operations, push and pop, which
write and read 16-bit words to the stack register addressed by stkp. I the
n
instruction descriptions which follow, push[x] means:
stkp + stkp+l
stk[stkp] + x
Pop[x] means:
x f stk[stkp]
stkp + stkp-1
The stack pointer paints to the highest numbered occupied stack location (the 'top
of stack'). The stack is empty i f stkp=O, full if stkp = stkmax+l. Although the Mesa
compiler normally keeps track of the depth of the stack and will not compile
operations which underflow or overflow it, a trap is provided by the hardware to
detect an attempt to cause underflow (pop when stkp=O) or overflow (push when
stkp=stkmax+l). If this is attempted, the trap StackError is generated, and the
stack pointer is not modified.
In addition to the push and pop operations, some instructions need to be able to
modify the stack poilnter without affecting the valu2s on the stack, others need to
be able to address locations in the stack relative to the stack pointer {note that
implementation constraints are likely to preclude the latter capability. The
capability is a logical requirement, and need not be implemented in precisely this
way).
The stack is used for expression evaluation and for passing arguments to
procedures. The load instructions push words from memory onto the stack, the
store instructions pop the stack into memory. The conditional jump instructions
pop the top one or two items from stack, test them in various ways, and branch
based on the result of the test. The arithmetic operations pop their operands from
the stack, calculate i result, and push i t onto the stack.
!
Some operations leave infrequently used results 'above the stack', i.e. in stack
locations beyond the one pointed to by -6tkp. A Mesa instruction (Push) is
provided to recover these quantities, i f required. by incrementing stkp. Another
instruction (Pop) is provided. to discard the top element of the stack by
decrementing stkp.
12
The Machine State
The OIS processor supports a total of sixteen hardware-scheduled Mesa
processes. The structure of the process switching system which controls the
selection of the currently active process is desribed in a later section of this
document. Each of these hardware-scheduled processes has a main data space
of up to 64K words which contains the local storage for the process, as well as
the tables described earlier. The state for a hardware-scheduled process is
accessed via an entry in the 16 word Process State Vector. The process state
vector must begin on a page boundary. The constant psv is a page pointer to the
process state vector. Each entry in the psv is the (16-bit) psv-relative
displacement of a state block containing the state of the process. Each of the
state blocks contains the following quantities, which are sufficient to completely
specify the process:
stkp: The evaluation stack pointer (right justified in the word)
stk[ 11. stk[2], ...] stk[stkmax]: The stack itself
dest: A control link (usually a local frame pointer), which is used by the processor to
obtain all the portions of the process state which are kept in machine registers while the
process is running. The quantities which are located, either directty or indirectly, from dest
are:
G: Pointer to the current global frame (an mds pointer)
C: Piointer to the current code segment (a 24-bit pointer)
PC: The program counter (a byte displacement relative t o C)
L: A pointer to the current local frame (an mds pointer)
The precise manner in which these quantities are located from dest is described
LII under "Pro c e ss S w itchin9".
mds: A page pointer to the main data space of the process
L
il
I
i
[I
r-
13
Instruction Formats and Classes
The Mesa instruction set is divided into four principal classes:
Loads and stores
Data modification instructions
Jumps
Control transfers
instructions are from one to three bytes in length; the opcode is always the first
byte. The second and third bytes, if used, are designated a and /3 respectively. In
situations in which both a and B are used as a 16-bit quantity, the designation ~$3
is used.
Currently, the instruction set contains more than 256 opcodes. The intent is to
reserve a single opcode for an OPERATE instruction, and encode a number of
infrequently used oipcodes into the a byte of this instruction. This will yield a
total of 511 opcodes, not all of which will be used. if the processor attempts to
execute an unimplemented opcode, the trap Unimplementedlnstruction is generated.
in the description of the instructions, the format used is:
Instruction Name
Mnemonic (length in bytes):
description of the instruction's effects.
L,G,and C refer to the values of the L,G, and C registers.
The octal opcodes of all instructions are summarized in Appendix A.
The pseudo-language used to describe the effects of instructions is provided for
precision, and is not intended to suggest actual implementation, although the
sequence in which the atomic operations which comprise instructions are
executed is often important. A number of temporary values (e.g. temp,pointer,data)
are used in the descriptions.
14
Load/Store I nstructlions
These instructions transfer data between the evaluation stack and one or more
locations in main storage. Instructions are provided for accessing partial words,
full words, and doublewords.
The final effective address of all load/store instructions is a 24-bit virtual
address. It is the responsibility of the virtual storage system to translate this
virtual address into a real address, verify that the location referenced is present in
main storage, and apply the appropriate protection checks. These translation
operations are not described in detail in the descriptions of the instructions.
Many of the instructions are optimized to access the main data space using a
16-bit mds pointer rather than a full 24-bit address. This is indicated explicitly in
the instruction descriptions by including mds in the effective address calculation.
When used in this way, mds is to be interpreted as a 24-bit value consisting of the
page pointer followed by eight zeroes.
When an instruction makes use of a doubleword pointer, the value is treated as a
long pointer, i.e. either of the formats for specifying a 24-bit address in a
doubleword may be used. It is the responsibility of the hardware to interpret this
pointer properly, as described under "Pointer Formats". In the instruction
descriptions, long pointers are designated "lpointer" (= Ipointerh,,lpointerl).
r-
15
LoadIStore Global Word
The load global instructions read a word from the global frame and push it onto the
stack. The comp'iler sorts the references to global variables in a module by
frequency, and assigns the eight most frequently referenced variables to the first
eight globals in the frame. These variables are accessed using single byte
instructions. The remaining globals are referenced using a two-byte instruction in
which a indicates %heoffset into the frame, or with a single byte instruction which
uses the top element of the stack as the offset. Note that the first global variable
is in G[globalbase] (globalbase is a small constant, see Appendix A), -and the
single byte loads include this offset. The instructions which use a as the
displacement do so relative to G.
Load Globat n, n=Q-7
LGn (1):
push[ < mds+G+n+globalbase>]
Load Global Byte
LGB ( 2 ) :
push[ < mds+G+a>]
The store global instructions store the top element of the stack into the global
frame. They take the displacement from the opcode, or from a.
Store Global n, n=0-3
SGn (1):
pop[mds+G+n+globalbase]
Store Global Byte
SGB ( 2 ) :
p op[mds+G + a]
16 f
I
Load/StoFe Local Ward
The Load Local instructions read-a word from the local frame and push it onto the
stack. The compileir sorts the references to local variables in a procedure by
frequency, and assigns the eight most frequently referenced variab!es to the first
eight locals in the frame. These variables are accessed using single byte
instructions. The remaining locals are referenced using a two-byte instruction in
which a indicates the offset into the frame. Note that the first local variable is in
L[localbase] (locallblase is a small constant, see Appendix A), and the single byte
loads include this offset. The instructions which use a as the displacement do so
relative to L.
Load Local n, n=0-7
LLn (1):
push[ ]
Load Local Byte
LLB ( 2 ) :
push[ < mds+L+a > ]
Load Local 0 and 0
LLOO (1):
<
push[ mds+L+localbase+O>]
pusht01
Load Local 1 and 0
LL10 (1):
push[ ]
pushCOl
The Store Local instructions sLore the top element of the stack into the local
frame. They take the displacement from the opcode or from a.
Store Local n, n=0-7
SLn (1):
pop[ mds+L+n+localbase]
Store Local Byte
SLB ( 2 ) :
pop[mds+L+a]
17
This instruction is identical to the Store Local instructions except that the stack
pointer is not decremented, leaving the stored value on top of the stack.
Put Local n, n=0-3
PLn (1):
pop[mds+L+n+localbase]
stkp + stkp + 1
Load Immediate
These instructions push constants onto the stack.
Load Immediate n, n=0-10
Lln (1):
Load Immediate Negative One
LIN1 ( 1 ) :
pushC-13
Load Immediate Byte
LIB ( 2 ) :
Load lmrnediate Word
LIW (3):
18
Load/Store Global Doubleword
Load Double Global Byte
LDGB ( 2 ) :
push[ ]
push[ ]
Store Double Global Byte
SDGB ( 2 ) :
pop[mds+G+a+1]
pop[ mds+G+a]
Load/Store Local Doubleword
Load Double Local 0
LDLO (1):
push f < mds+L+Iocalbase +O >]
push[ < mds+L+localbase+l >]
Load Double Local Byte
LDLB ( 2 ) :
push[ < mds+L+a>]
push[]
Load Double Local Swapped 0
LDLSO (1):
push[ ]
< >
pushf md s +L+lloca Ibase +0 ]
Store Double Local 0
SDLO (11:
pop[ mds+L+localbase+l ]
pop[ mds+L+local base +O]
Store Double Local Byte
SDLB ( 2 1:
pop[mds+L+a+ 1 ]
pop[mds+L+ a]
Read/Write Word
These instructions use the top element of the stack as a pointer, add to it a
displacement from the opcode or a, and do a push or pop.
Read n, n=0-4
Rn (1):
POp [PO int er ]
push[ ]
Read Byte
RB (2):
pop[ pointer]
push[ J
Read Byte and Load Local 0
RBLLO (2):
popfpointer]
push[tmds+pointer+a]
push[ < mds+L+locaibase+O>]
Write n, n=0-2
Wn (1):
popCpointer J
pop[mds+n+pointer]
Write Byte
WB (2):
popCpointer]
pop[mds+ a+pointer]
The following two instructions are similar to Wn and WB, except that the order of
their operands on the stack is reversed so that the pointer may be recovered with
a Push instruction:
Write Swapped 0
wso (1):
PoPCclatal
popCpointer]
+ data
[j 20
iIJ
I
Write Swapped Byte
WSB (2):
! pop[datal
popCpointer]
+ data
The following two instructions are similar to Wn and WB, except that the order of
their operands on the stack is reversed and the pointer is left on the stack for a
subsequent instruction:
Put Swapped 0
PSO (1):
pop[datal
pop[POint er]
+ data
stkp + stkp + 1 *
Put Swapped Byte
PSB (2):
PoPCdatal
pop[ pointer]
+ data
stkp + stkp + 1
The following instructions interpret the top two elements of the stack as a long
pointer, add a to it, and do a push or pop.
Read Byte Long
RBL ( 2 ) :
po pr IPO i nter h]
pop[ lpointerl]
push[ t a+lpointer>]
Write Byte Long
WBL ( 2 ) :
pop[ Ipointerh)
poprlpointerl]
pop[a+ lpointer]
21
Read/ Wri te Doubleword
These instructions take a pointer from the stack and do a doubleword push or
pop. The b y t e versions use a as a displacement relative t o the pointer:
Read Double 0
RDO (1):
pop[ pointer]
push[ ]
push[ I
Read Double Byte
RDB ( 2 ) :
pop[ point er]
push[ ]
push[]
Write Double 0
WDO (1):
popCpointer]
pop[mds+pointer+l ]
pop[mds+pointer]
Write Double Byte
WDB ( 2 ) :
popCpointer]
pop[mds+pointer+a+l ]
pop[mds+pointer+a]
PSDO and PSDB take their operands from the stack in reverse order and leave the
pointer on the stack for a subsequent instruction:
Put Swapped Double 0
PSDO ( 1 ) :
pop[datal ]
pop[dataZ]
pop[pointer]
c data1
6 data2 .
stkp c stkp + 1
--
22
Put Swapped Double Byte
PSDB ( 2 ) :
pop[datal]
pop[data2]
pop[ POinter]
+ datal
+ data2
stkp +- stkp + 1
WSDO and WSDB take their operands from the st ck in r verse order, so that the
pointer may be recovered by a Push instruction:
Write Swapped Double 0
WSDO (1):
popcdatal ]
popCdata21
pop[ pointer]
datal
+-
* data2
Write Swapped Double Byte
WSDB ( 2 ) :
pop[datal]
pop[ data23
pop[pointer]
datal+-
data2
+-
The following instructions interpret the top two elements of the stack as a long
pointer, and do a doubleword read or write.
Read Double Byte Long
RDBL ( 2 ) :
pop[lpointerh]
pop[lpointert]
pusti[ < Ipointerca>I
push[I
Write Double Byte Long
WDBL (2):
pop[lpointerh]
pop [1pointer I]
pop[lpointer+a+l]
pop[lpointer+a]
7 - 7 1
- _
I
I _ _
I I I
23
ReaWWrite Indexed
These instructions consider a as a pair of numbers encoded in four bit fields. The
displacement in the first field and the item from the top of stack are added to the
local selected by the second field and a push is performed at that location.
Read Indexed by Lacal Pair
RXLP (2):
popfindex]
pointer + < mds+L+Iocalbase+ a[O:3]>
push[ ]
Write lndexed by Local Pair
WXLP (2):
pop[ index]
pointer + < mds +L+I o cat base + a[O: >
33
pop[mds+pointe~r+index+a[4 7 1 1
Read Indexed by Local Pair Long
RXLPL (2):
pop[index]
Ipointer t + < mds+L+I ocalbase + CT [0:31 >
lpointerh +
push[ < Ipointer+Endex+a[4:7] >]
Write Indexed b y Lacal Pair Long
WXLPL (2):
pop[index]
lpointerl+
lpointerh 6
J
pop[lpointer+index+a[4:7]] .
r-
I -- I
---
24
Read/Write Indirect
- 7 .
0 .
These instructions add a displacement from the opcode to stlocal variable, and do
a push or pop to that location. I
Read Indirect Local n, n= 0-3
RlLn (1):
push[ < mds++n>]
This instruction is similar to RILn, except that the pointer is in the local specified in
the first 4 bits of a, and the offset is taken from second four bit field of a.
Read Indirect Local f a i r
RILP ( 2 ) :
push[ + a [ 4 : 7 ]>]
Writing version of RILP.
Write Indirect Local fair
WlLP ( 2 ) :
pop[ < mds+L+localbase+a[ 0:3] >+a[4:7]]
This instruction is similar to RILP, except that the pointer is taken from the global
frame.
Read Indirect Global Pair
RlGP (2):
>]
push[ + a [ 4 : 7 ]
Read Indirect Local Pair Long
RlLPL (2):
lpointerl
+
lpointerh +-
push[ ]
Read Indirect Global Pair Long
RIGPL (2):
I p o i11t e r I
3
lpointerh +
push~
-- I
25
Write Indirect Locat Pair Long
WlLPL ( 2 ) :
lpointerl 6
lpointerh
+-
pop[lpointer +a[4:7]]
Write Indirect Global Pair Long
WlGPL ( 2 ) :
I poinl er I +-
lpointerh
+-
pop[lpointer+a[4:7 J]
These instructions optimize double indirection.
Read Indirect Indirect Local 0 Pair
RllLP ( 2 ) :
pointer +
push[ +a[4:7]>]
Read Indirect lndirect Pair
RllP ( 2 ) :
pop[ pointer]
push[ +ct[4:7]>]
26
Read/Write String
These operations take a byte index into a string from the top element of the'stack,
a pointer to the string from the second element, and read or write a single
character (byte) from the string. There' are also versions which use the second
and third elements of the stack as a long pointer. A Mesa string has the format
shown in figure 3 (the instructions do not make use of the first two words of the
string).
Read String
RSTR . (1):
pop[ i nd ex]
p op[pointet-]
if index odd do --odd index means right byte
push[ and 377B]
else do
push[( and 177400B) rshift 8J
Read String Long
RSTRL (1):
pop [in d e x]
pop [IPO i nt e r h]
popCtpointerI )
if index odd do --odd index means right byte ,
push[ and 37781
else do
push[( and 177400B) rshift 8)
Write String
WSTR (1):
pop[index)
popCpointer]
c
POP data)
if index odd do
+
and 1774008) or (data and 3778) --odd index means right byte
else do
+ and 3778) or (data and
17740QB) --even index means left byte
Write String Long
WSTRL (1):
pop [index]
pop[ Ipointerh]
pop[ipointert ) '
PoPCdatal
if index odd d o
+
and 1774008) or (data and 377B)..--odd index means right byte
else d o
+
and 3778) or (data and 1774008) --even index means left byte
27
Read/Wtite Field
These instructions use the top element of the stack plus a as a displacement, and
push or pop the field described by / .There are also versions which use the top
I
two elements of the stack as a long pointer.
A field descriptor is an eight-bit byte. The left four bits give the position of the
field in a word, the right four bits indicate its size. If pos,,size is a field descriptor,
the first bit of the field it describes is bit (16-pos-size), the last bit is (l!j-pos),
i.e. pos indicates the amount by which a word must be right-shifted to extract the
field, and size indicates the width of the mask which must be applied to the word.
Operations which read a field leave i t right justified on the stack; Operations which
write a field store the rightmost size bits in the correct position in the word, and
leave the remaining bits unchanged.
Read Field
RF (3):
pop[pointer J
temp 6
m a s k 6 2**p[4:7]-1
push[(temp rshift /3[0:3]) and mask]
Read Field Long
RFL ( 3 ) :
pop[lpointerh J
pop[ lpointerl]
temp 6
mask 6 2**p[4:7]-1
push[(temp rshift p [ O : 3 ] ) and mask]
c This instruction is similar to RF, except that the pointer is in local zero, and the
field size and field position are taken from two four bit fields of a.
r --
Read lndirecf Local 0 Field
RlLF ( 2 ) :
pointer 6
temp +-
mask 6 2**a[4:7]-1
push[(ternp rshift cx[O:3]) and mask]
This instruction is a combination of RiLP and RF.
Read lnddirect Local f a i r Field
RlLPF ( 3 ) :
pointer 6
t ernp+- < mds+poi t i t er + a[4 7 1>
mask +- 2",@4:7]-1
push[( temp rshift p [ 0 : 3 ] ) and mask]
i 28
Write Field
WF (3):
pop[ pointer]
POP[: data1
temp +
mask + (2**/3[4:7]-1) lshift p[0:3]
data + data lshift / [ : ]
303
6 (temp and not mask) or (data and mask)
Write Field Long
WFL ( 3 ) :
pop[ Ipointerh)
pop[lpointerl)
PoPCdatal
temp C-
mask 6 (2**p[4:7]-1) lshift P [ O : S ]
data + data lshift / [ : ]
303
(temp and not mask) or (data and mask)
The Write Swapped Field instruction is similar'to WF, except that the operands are
reversed on the stack so that the pointer may be recovered by a Push instruction:
Write Swapped Field
WSF (3):
POPCd a t 4
pop[ pointer J
temp 6
mask 6 (2**p[4:7]-1) lshift p [ 0 : 3 ]
data 6 data lshift p [ O : 3 ]
6 (temp and not mask) or (data and mask)
The Put Swapped Field instruction is similar to WF, except that the operands are
reversed on the stack and the pointer is left on the stack for a subsequent
instruction:
Put Swapped Field
PSF ( 3 ) :
PoPCdatal
pop[ pointer]
temp 6
mask + (2"p[4:7]-1) lshift pC0:S-J
data 6 data lshift p [ O : 3 ]
6 (temp and not mask) or (data and mask)
stkp 6 stkp + 1
Read Field 0
RFO ( 2 ) :
pop[pointer)
temp
mask c- 2"0[4:7]-1
push[(temp rshift a [ O : 3 ] ) and mask)
I
- --
29
The Read Bit instructions are similar to RF, except that the size portion of the field
descriptor is implicitly 1, and the offset and field position are taken from two four
bit fields of a. The pointer may be either on the stack or in local 0.
Read Indirect Local 0 Bit
RILBIT (2):
pointer +
temp +
push[(temp rshift a [ 4 : 73 ) and A ]
Read Bit
RBI1 (2):
pop[pointer)
temp c.
push[(temp ?shift a [ 4 : 7 ] ) and 1)
r 1
30
Data Modification I nst ructions
These instructions pop their operands from the stack, perform an operation, and push
the result.
Add
ADD (1):
The top two elements of the stack taken as two's complement numbers are
added. The result is pushed onto the stack.
Sub tra cf
SUB (1):
The top element of the stack is subtracted from second element using two's
complement arithmetic. The result is pushed onto the stack.
Double Add
DADD (1):
POPCXJ
POPCYI
PoPCtl
POPCUJ
push[u+y] ( c l +carry)
push[t+x+cl J ( c 2 c c a r r y )
push[ c2]
stkp+ stkp-1
The two doublewords on the stack are added and pushed. The carry resulting from the
32-bit addition i l e f t above the top of the stack (in bit 15), so that i t may be recovered
s
by a Push instruction if required.
31
Double Subtract
DSUB (1):
POPCXl
POPCY 1
POPCtI
POPCUI
push[u-y] ( c l +carry)
push[t-x-cl) (c2ccarry)
push[c2)
stkp+ stkp-1
The doubleword on the top of the stack is subtracted from the doubleword in the
second stack position, and the result is pushed. The carry resulting from the 32-bit
subtraction is left above the top of the stack (in bit 15), so that it may be recovered by
a Push instruction if required.
Multiply
MUL (1):
POPCXI
POPCYl
push[(x*y)[16:31 J]
push[(x'y)[O:l5 J ]
stkp + stkp-1
The top two elements of the stack are multiplied, and the result, which is a 32-bit
quantity, is pushed onto the stack with the most significant 1 6 bits in the top element,
and the least significant 16 bits in the second element. The stack pointer is then
decremented, so that the least significant 16 bits occupy the top of stack. In most
cases a 16-bit product will be desired, which is the result. If a full 32-bit product is
needed, a Push instruction may be used to recover the most significant bits. The
operanrjs and the result are treated as two's complement numbers, and the sign of the
result is calculated according to the rules of algebra.
Unsigned Mu1tip ly
UMUL (1):
The top two elements of the stack are multiplied. and the result, which is a 32-bit
quantity, is pushed onto the stack with the most Significant 16 bits irl the top element,
arid the least significant 16 bits in the second element. The stack pointer is then
decremented, so that the least significant 16 bits occupy the toy, of stack. In most
cases 3 16-bit product will be desired, which is the result. If a full 32-bit product is
needed, a Push instruction may be used to recover the most significant bits. The
operands and the result are treated as unsigned numbers.
32
Double
DBL (1):
POPCXI
push[x lshift 1)
The top element of the stack is left shifted by 1.
Divide
DIV (1):
POPCXl
POPCYl
quot,,rem + y/x
push[ quot]
push[ r em]
stkpkstkp-1
The top element of the stack is used as a 16-bit signed divisor, the second
element is taken as a 16 bit signed dividend. The division 'is performed, and the
16-bit quotient is pushed onto the stack. The remainder is left above the top of
stack. Divisor and dividend are treated as two's complement numbers, and the
signs of the quotient and remainder a-e calculated according to the following rules:
-_
Dividend Divisor Quotient Remainder
positive positive positive positive
positive negative negative positive
negative positive negative negative
negative negative positive negative
The division is not performed and the trap ZeroDivisor is generated i f the divisor is zero.
Long Divide
LDlV ( I ) :
POPCXl
POPCY3
POPCZl
quot,,rem + y,,z/x'
push[quot]
push[rem]
stkp + stkp-1
The top element of the stack is used as a 16-bit signed div sor, the second and third
elements are used as a 32-bit signed dividend (with the least significmt bits in the third
element). The division is performed, and tile 16-bit quotient is pushed onto the stack.
The remainder is left ahove the top Gf stack. Divisor and div dend are treated as two's
complement numbers, and the signs of the quotient and remainder are calciilated
according to the rule for DIV.
33
If the magnitude of the most significant half of the dividend is greater than that of the
divisor, the trap Dividecheck is generated, indicating that the quotient will not fit into a
single word. If the divisor is zero, the trap ZeroDivisor is generated. If either trap
occurs, the division i not performed.
s
Unsigned Divide
UDIV (1):
POPCXI
PoPrYl
POPCZl
quot..rem 4 y.,z/x
push[ quot)
push[ rem]
stkpestkp- 1
The top element of the stack is used as a 16-bit unsigned divisor, the second and third
elements are used as a 32-bit unsigned dividend (with the least significant bits in the
third element). The division is performed, and the 16-bit quotient is pushed onto the
stack. The remainder is left above the top of stack. Divisor and dividend are treated as
unsigned numbers.
If the magnitude of the most significant half of the dividend is greater than that of the
divisor, the trap Dividecheck is generated, indicating that the quotient will not fit into a
single word. If the divisor is zero, the trap ZeroDivisor is generated. If either trap
occurs, the division is not performed.
The following instruction negates (2's complemen