EXTENDED_ADDRESSING
+---------------------------+
| | | | | | | | i n t e r o f f i c e
| d | i | g | i | t | a | l |
| | | | | | | | m e m o r a n d u m
+---------------------------+
To: Architecture distribution Date: 24 Jun 83
From: Mike Uhler
Dept: L.S.E.G.
DTN: (8-)231-6448
Loc/Mail stop: MRO1-2/E85
Net mail: UHLER at IO
Subject: Extended addressing
Revision: 5
Revision history
Revision Date Changes
5 07-Jul-83 Make one-word global byte pointers legal in
section 0. Make JSA and JRA illegal for
inter-section use.
1.0 Introduction
As we attempted to implement the EBOX microcode for Jupiter, we
quickly discovered that there were some serious deficiencies in
the documentation for what we were trying to implement. The most
serious deficiency was in the area of rules for extended
addressing, especially for the exception conditions. We found
ourselves implementing the EBOX microcode partially from the
Processor Reference Manual (PRM) but, more often than not, from a
collection of old documentation, memos, and recollections of what
was decided in the design of extended addressing.
After spending two weeks attempting to decipher what the rules
should be and comparing them with the KL10 implementation, I wound
up with a large collection of notes concerning aspects of extended
addressing which are either not documented or poorly documented.
Several meetings of the PDP-10 Architecture Committee ensued, and
this memo is an attempt to formalize my notes.
The intent of the memo is to provide a description of extended
addressing as defined by the PDP-10 architecture. This material
Page 2
really belongs in the Processor Reference Manual, and every
attempt will be made to get it included in the next release of the
manual. Note that certain implementations of the PDP-10
architecture don't always conform to the descriptions given in the
memo. These are descriptions of what SHOULD be implemented, not
necessarily what IS implemented. However, all future PDP-10
processors should conform to these descriptions.
In order to make it easier for the reader, I've also added a lot
of background, definitions, and descriptions of extended
addressing that are found in other references. This additional
discussion should make the overall structure of extended
addressing more clear.
In order to avoid swamping the reader with too much detail at any
point, I sometimes intentionally ignore or understate certain
important aspects of the examples that I use. These items are
generally covered later in the memo. I also occasionally forward
reference topics. Because of this organization, it may be best to
make a quick first pass through the memo to pick out the
highlights and then go back and make a more detailed pass.
This memo assumes that the reader has at least a basic knowledge
of the PDP-10 instruction set, the notation used to describe
instructions, and the format of an instruction word. Readers who
do not have this knowledge are referred to sections 1.4 through
1.6 of the Processor Reference Manual and to the Macro Assembler
Reference Manual.
Page 3
2.0 Reference materials
The primary source of information about the instruction set is the
Processor Reference Manual. Unfortunately, there are some
inaccuracies and some omissions in the sections related to
extended addressing. The "Extended Effective Address Calculation"
flow chart on page 1-30 of the PRM is the best "description" of
the effective address calculation algorithms and it is attached to
this memo for the convenience of the reader.
The KL10 Engineering Functional Spec contains several chapters
related to this topic and has some interesting insights.
Especially interesting are chapters 2.2, "User Interface to
Extended Addressing", and 2.3, "Monitor Calling (MUUO, PXCT)".
Along with these chapters is a hand-drawn flow chart by Tom
Hastings entitled "Flow for Extended Addressing" that clears up
several questions about EA-calc algorithms, especially in the area
of PXCT. A copy of this flow chart is attached.
Old memos describing the design of extended addressing and the
implementation of extended addressing in TOPS-20 are also somewhat
helpful.
Finally, the KL10 microcode contains a few helpful comments about
exception conditions in that implementation of extended
addressing. It is in no sense "light reading", however.
Page 4
3.0 Historical summary of extended addressing
PDP-10 processors prior to the model B KL10 implemented a virtual
address space of 256K words. As programs and the operating
systems grew, it became apparent that a virtual address space that
was limited to 256K was insufficient for future expansion.
Sometime in late 1973, an Extended Addressing Design Group was
formed to evaluate proposals for increasing the virtual address
space of the PDP-10. By early 1975, this group had agreed upon
one proposal, and this proposal was documented in chapter 2.2 of
the KL10 Engineering Functional Spec.
This proposal increased the size of the virtual address space from
256K words to 1 billion words by expanding the size of a virtual
address from 18 bits to 30 bits. The virtual address space is
logically divided into 4096 sections of 256K words each. The
program may use these sections as separate logical entities or
treat them as one large contiguous address space. Instructions,
however, must explicitly transfer control between sections; they
may not "fall" into the next section.
The increase in the size of the virtual address space was
accompanied by an increase in the size of PC, from 18 to 30 bits.
This increase allowed a program to execute in any of the extended
sections. The contents of bits 6-17 of PC were termed the "PC
section".
In order to allow an instruction to specify a full 30-bit virtual
address, the rules for indexing and indirection were modified when
PC section was non-zero. In addition, new instructions were
defined to allow a program to jump to other sections.
To insure compatibility with programs written for non-extended
processors, section zero is treated exactly as it is on
non-extended processors. This means that if a program is
executing in section zero, nearly all instructions behave exactly
as they would if the program were executed on a non-extended
machine. Programs running in section zero cannot reference data
in any other section (with one exception) and entry into another
section is possible only with a few instructions (e.g., XJRSTF,
XJRST, etc.).
The first processor to implement extended addressing was the model
B KL10. Due to hardware restrictions, this processor implemented
only 32 of the 4096 sections of virtual address space. References
to virtual sections above the implemented range cause a page fail
trap to the monitor. The KC10 implements the full 30-bit virtual
address space.
Page 5
4.0 Definition of terms
Before we start looking at extended addressing, let's define some
terms:
o A virtual address is a 30-bit address used to reference a word
in an address space. Although the address space can be
considered to be one large, contiguous space, it is probably
easier to consider it to be broken into sections of 256K words
each. Bits 6-17 of the virtual address then specify the
section number and bits 18-35 specify the word within the
section. A virtual address looks like:
6 17 18 35
|---------------------------------------------|
| Section number | Word within section |
|---------------------------------------------|
Virtual address format
PC has the same format as a virtual address.
o An address word is a word containing I, X, and Y fields (see
the PRM for definitions for these fields) in either IFIW or
EFIW (see below) format. An effective address calculation
takes such a word as input. Thus, instructions, indirect
words, and byte pointers are all examples of address words.
o A local address is an 18-bit in-section address that, when
combined with a default section number, specifies a full
30-bit address. The section number is supplied by something
other than the address word or index register.
o A global address is a 30-bit address that supplies its own
section number. Therefore, no default section need be
applied.
o A local index is an 18-bit displacement or address obtained
from an index register used in an effective address
calculation in section zero, or from an index register used in
a non-zero section that has bit 0=1 or bits 6-17 equal zero.
In a non-zero section, an index register containing a local
index has one of the following formats:
0 1 17 18 35
|-------------------------------------------------------|
|1| Ignored | Local address (or offset)|
|-------------------------------------------------------|
Local index format (bit 0 = 1)
0 1 5 6 17 18 35
|-------------------------------------------------------|
|0|Ignored| 0000 | Local address (or offset)|
|-------------------------------------------------------|
Local index format (bits 6-17 = 0)
Page 6
o A global index is a 30-bit displacement or address obtained
from an index register used in an effective address
calculation in a non-zero section, that has bit 0=0 and bits
6-17 non-zero. An index register containing a global index
looks like:
0 1 5 6 35
|-------------------------------------------------------|
|0|Ignored| Global address with 6-17 non-zero |
|-------------------------------------------------------|
Global index format
o An instruction format indirect word (IFIW) is any indirect
word in section zero, or an indirect word in a non-zero
section that has bit 0=1 and bit 1=0 (instructions being
executed are always interpreted in IFIW format). In this
format, bit 13 is the indirect bit, bits 14-17 are the index
register address, and bits 18-35 are the local memory address.
An IFIW in a non-zero section looks like:
0 1 2 12 13 14 17 18 35
|-------------------------------------------------------|
|1|0| Ignored |I| X | Y |
|-------------------------------------------------------|
IFIW format
o An extended format indirect word (EFIW) is any indirect word
in a non-zero section that has bit 0=0. In this format, bit 1
is the indirect bit, bits 2-5 are the index register address,
and bits 6-35 are the global memory address. An EFIW looks
like:
0 1 2 5 6 35
|-------------------------------------------------------|
|0|I| X | Y |
|-------------------------------------------------------|
EFIW format
o An illegal indirect word is any indirect word in a non-zero
section that has both bits 0 and 1 set to a 1. This type of
indirect word is reserved for use by future hardware. If an
EA-calc encounters this type of indirect word in a non-zero
section, it will generate a page fail. The monitor cannot
perform any user service as a result of this trap, including
trapping to the user, since this would cause possible
compatibility problems with future machines. An illegal
indirect word looks like:
0 1 2 35
|-------------------------------------------------------|
|1|1| Reserved |
|-------------------------------------------------------|
Illegal indirect word format
Page 7
o A one-word local byte pointer is any byte pointer whose P
field is less than or equal to 36 and that has bit 12=0. In
this type of byte pointer, bits 13-35 have the same format as
an IFIW, and bits 0-11 specify the size and position of the
byte. A one-word local byte pointer looks like:
0 5 6 11 12 14 17 18 35
|-------------------------------------------------------|
| P | S |0|I| X | Y |
|-------------------------------------------------------|
One-word local byte pointer format
o A one-word global byte pointer is any byte pointer whose P
field is greater than 36. In this type of byte pointer, bits
0-5 are an encoded representation of the size and position of
the byte and bits 6-35 supply a full 30-bit address of the
word containing the byte. A one-word global byte pointer
looks like:
0 5 6 35
|-------------------------------------------------------|
|P,S enc | 30-bit address |
|-------------------------------------------------------|
One-word global byte pointer format
o A two-word global byte pointer is any byte pointer in a
non-zero section whose P field is less than or equal to 36 and
which has bit 12=1. As its name implies, this type of byte
pointer consists of two words where bits 0-11 of the first
word give the size and position of the byte and bit 12 must be
a 1. The second word is either an IFIW or an EFIW and, when
EA-calc'ed, supplies the address of the word containing the
byte. A two-word global byte pointer looks like:
0 5 6 11 12 17 18 35
|-------------------------------------------------------|
| P | S |1|Reserved| Available to user |
|-------------------------------------------------------|
| IFIW or EFIW |
|-------------------------------------------------------|
Two-word global byte pointer format
o A local stack pointer is any stack pointer in section zero, or
a stack pointer in a non-zero section that has bit 0=1 or bits
6-17 equal zero before incrementing or decrementing (exactly
like a local index). Incrementing or decrementing such a
stack pointer will operate on both halves of the pointer
independently, suppressing carries out of bit 18.
Page 8
o A global stack pointer is a stack pointer in a non-zero
section that has bit 0=0 and bits 6-17 non-zero before
incrementing (exactly like a global index). Incrementing or
decrementing such a stack pointer will treat the entire word
as a 30-bit quantity.
Page 9
5.0 Effective Address Calculations
No discussion of extended addressing is complete without talking
about EA-calc's. An effective address calculation is performed on
every instruction before it is executed. In addition, some
instructions perform additional EA-calc's during the processing of
the instruction (e.g. byte instruction EA-calc of the byte
pointer).
5.1 Description of the EA-calc algorithm
The basic operation of an EA-calc is to process a so-called
address word by adding the Y field of the word to the contents of
the optional index register to compute a modified address. If the
indirect bit is set in the address word, another word is fetched
from the memory location addressed by the computed address and the
entire process repeats until a word is found with the indirect bit
not set. Sound simple? Well, let's look at the operation in a
bit more detail.
The address word can be of two different formats, IFIW or EFIW (an
instruction is treated as an IFIW when it is EA-calc'ed). In
addition, an index can be of two different formats, local or
global. Note that in section zero, all address words are IFIWs
and all indices are local by definition. The complexity involved
in the EA-calc algorithm is the result of these multiple formats.
Since the indirect bit simply causes another address word to be
fetched and the EA-calc process to be repeated, we can fully
characterize an EA-calc by looking at the combinations of IFIW,
EFIW, and indices in local and global format. Let's look at these
combinations one at a time.
5.1.1 No indexing
If no index register is specified in the address word, the EA-calc
is strictly a function of the Y field in the address word. For an
IFIW, the result is a local address. For example, both
1,,100/ MOVE 1,200
and
1,,100/ MOVE 1,@150
1,,150/ 400000,,200
compute a local effective address of 200. In the first case, the
only address word is the instruction itself, which is treated as
an implicit IFIW. In the second case, there are two address
words, the instruction and the indirect word, and the indirect
word is in the IFIW format.
Page 10
For an EFIW, the result is a full 30-bit global address. For
example,
1,,100/ MOVE 1,@[1,,200]
computes a global effective address of 1,,200 because the indirect
word has a global format.
5.1.2 IFIW with local index
If the address word is an IFIW and the index is local, the result
is a local address. The 18-bit address is computed by adding the
Y field to the right half of the contents of the index register.
For example:
1,,100/ MOVE 1,[-1,,10]
1,,101/ MOVE 2,@[400001,,200]
The indirect word has an IFIW format, so bits 14-17 specify the
index register address. Since the contents of the index register
are negative, it is a local index and the EA-calc is performed by
adding the Y field (200) to the right half of the index register
(10) to produce a local effective address of 210.
5.1.3 IFIW with global index
If the address word is an IFIW and the index is global, the result
is a 30-bit global address. The address is computed by adding
bits 6-35 of the contents of the index register to the value of
the Y field, that has been sign-extended from bit 18 into bits
6-17. For example:
1,,100/ MOVE 1,[2,,10]
1,,101/ MOVE 2,-2(1)
The second instruction word has an implicit IFIW format, so bits
14-17 specify the index register address. Since the left half of
the index register is positive non-zero, it is a global index and
the EA-calc is computed by adding the Y field, after
sign-extending it from bit 18 into bits 6-17 (7777,,-2), to bits
6-35 of the contents of the index register (2,,10), producing a
global effective address of 2,,6.
Note that the sign extension allows Y to be used as a positive or
negative constant offset to the global address in an index
register. This offset is limited to +/- 128K.
Page 11
5.1.4 EFIW with global index
If the address word is an EFIW, the index is always assumed to
have the global format and the result is a 30-bit global address.
The address is computed by adding bits 6-35 of the contents of the
index register to bits 6-35 of the Y field. For example:
1,,100/ MOVE 1,[2,,10]
1,,101/ MOVE 2,@[010002,,200]
The indirect word has an EFIW format, so bits 2-5 specify the
index register address. The index is always global, so the
EA-calc is computed by adding the Y field (2,,200) to bits 6-35 of
the contents of the index register (2,,10) to produce a global
effective address of 4,,210.
5.1.5 References to section zero
Note that the only way to reference section zero from a non-zero
section is via an EFIW format indirect word with bits 6-17 equal
zero. Indexing alone cannot be used to reference section zero,
because an index with bits 6-17 equal zero is treated as a local
address to the section from which the last address word was
fetched.
5.1.6 Summary of EA-calc rules
The preceding sections can be summarized by the table that
follows. This table gives the computation done for all
combinations of address words and index registers formats plus an
indication as to whether the result is local or global.
Address
Word Type
IFIW EFIW
===========================================================
|| Y[18:35] || Y[6:35] ||
None || || ||
|| Local || Global ||
===========================================================
Index || Y[18:35]+(XR)[18:35] || Not Defined ||
Reg Local || || (Actually the case ||
Type || Local || below) ||
===========================================================
|| Y[18]*7777,,Y[18:35]+ || Y[6:35]+(XR)[6:35] ||
Global || (XR)[6:35] || ||
|| Global || Global ||
===========================================================
Page 12
5.2 Results of an EA-calc
When the microcode performs an EA-calc, it is simply following the
rules described above and shown graphically in the EA-calc flow
chart from the PRM. The result of this EA-calc is a 30-bit
address and a 1-bit flag that indicates the address is local or
global. These two pieces of information must be considered
together whenever the results of the EA-calc are used; it is
seldom, if ever, correct to consider the address without also
considering the local/global bit.
Every EA-calc carries a default section along during the
calculation of the effective address. The initial default section
for an EA-calc of an instruction is PC section. More generally,
the default section is initially that from which the first address
word was fetched. This default section is changed from the
initial value if the EA-calc follows a global address into another
section. In fact, the default section is always the section from
which the last address word was fetched.
If a local address is calculated using the rules given above, the
default section is applied to complete the 30-bit address. If a
global address is calculated, the default section is not used.
The last iteration of the EA-calc (the computation done on the
last address word that doesn't have the indirect bit set)
determines whether or not the result of the EA-calc is local or
global. If the result of the last iteration is a local address,
the result of the EA-calc is local. Similarly, if the result of
the last iteration is global, so is the entire EA-calc. The
transitions of the local/global flag are indicated on the PRM flow
chart by notations such as "E Global".
The significant thing to remember is that a local EA-calc still
results in a 30-bit address, even though 12 bits (the section
number) were not explicitly supplied to the EA-calc routines as
part of an address word or an index register.
o An effective address calculation always computes 31 bits of
information: a 30-bit address, and a 1-bit local/global flag.
5.3 Simple EA-calc examples
In the examples above, we ignored the fact that EA-calc's always
produce a 30-bit address when we said that the result was a local
address n. In the following examples, we emphasize that a full
30-bit address is produced. Consider the following instruction:
0,,200/ MOVE 1,100
The EA-calc for this instruction results in a local EA.
Therefore, the EA-calc computes the 30-bit address as 0,,100 and
Page 13
the 1-bit local/global flag as local. Since the EA is local, we
know that the section number was defaulted from something, in this
case, the PC section. We say that the effective address is 0,,100
LOCAL (this notation is used throughout the rest of this
discussion to specify all 31 bits of information).
Let's consider a slightly more complex example:
1,,200/ MOVE 1,@300
1,,300/400000,,100
As in the previous example, the effective address calculation
computes a local address of 100. Since the address word was
fetched from section 1, the result of the EA-calc is 1,,100 LOCAL.
Let's look at a global EA-calc:
1,,100/ MOVE 1,@[2,,200]
In this case, the effective address calculation produces a global
address of 2,,200 GLOBAL and no default section need be applied.
Page 14
6.0 Use of the local/global flag
There are two uses for the local/global flag. First, it is used
to determine if the address is actually an AC. If the address is
local, and bits 18-35 are in the range 0 to 17, inclusive, the
address references an AC, independent of bits 6-17. This means
that a program can reference the ACs while running in any section,
as long as the reference is local.
Second, the local/global flag determines how to increment or
decrement the address. If the address is local, incrementing or
decrementing it suppresses carries from bit 17 to bit 18 and vice
versa. That is, the address always wraps around in the current
section if the right half is incremented past 2^18-1 or
decremented past 0. A global address is handled as a full 30-bit
quantity and overflow or underflow of the right half can affect
the left half section number.
6.1 AC references
Let's look at several examples that make use of the local/global
flag. First, let's compare what happens to AC references for
local and global effective addresses.
2,,100/ MOVE 1,@[400000,,5]
The EA-calc for this instruction yields 2,,5 LOCAL, where the
section number was defaulted to 2. Is this memory location 2,,5
or AC 5? Because the EA-calc is local, the rule says that it is
an AC reference and not a memory reference. On the other hand,
the EA-calc for
2,,100/ MOVE 1,@[2,,5]
results in an EA of 2,,5 GLOBAL. Since the EA is global, this is
a memory reference and not an AC reference.
o EA-calc's which yield local addresses, where bits 18-35 of EA
are in the range 0-17, inclusive, always refer to the ACs
independent of the section number.
Finally, there is the concept of "global AC address". This
concept allows a program running in any non-zero section to make a
global reference to the ACs by computing a global address in the
first 16 (decimal) locations of section 1. Consider the following
example:
Page 15
2,,100/ MOVE 1,@[1,,5]
The EA-calc yields 1,,5 GLOBAL and because of the "global AC
address" rule, the reference is to AC 5 instead of memory location
1,,5.
o An EA-calc which yields a global address to locations 0-17,
inclusive, of section 1, refers to the ACs and not to memory.
Such an address is called a global AC address.
6.2 Incrementing EA
Another use for the local/global flag computed as the result of an
EA-calc is to determine how to increment the effective address.
Let's look at two examples using DMOVE, one computing a local EA
and one computing a global EA.
2,,100/ DMOVE 1,@[400000,,777777]
The EA-calc for this instruction results in an effective address
of 2,,777777 LOCAL. The DMOVE instruction fetches two contiguous
words from E and E+1, but what is E+1 in this case? Since the
EA-calc resulted in a local address, incrementing E is done
section-local, resulting in 2,,0 LOCAL for E+1. But this is a
local reference to the ACs, so the two references for E and E+1 go
to 2,,777777 (memory) and 2,,0 (AC). Note that the state of the
local/global flag is maintained during the incrementing of EA.
o Incrementing or decrementing a local address is always done
relative to the original section, i.e., the addresses "wrap
around" in section.
o Incrementing a local address whose in-section part is 777777
causes the address to wrap around into the ACs.
Let's look at the corresponding global case:
2,,100/ DMOVE 1,@[2,,777777]
In this case, the EA-calc yields 2,,777777 GLOBAL. Because this
is a global address, incrementing E to get the second word results
in a reference to 3,,0 GLOBAL. Since this isn't a local address,
the reference is made to memory location 3,,0 and not to AC 0.
o Incrementing or decrementing a global address affects the
entire address; i.e., section boundaries are ignored.
o The process of incrementing or decrementing an address,
whether the address is local or global, preserves the state of
the local/global flag.
Page 16
7.0 Multi-section EA-calc's
So far we have considered only EA-calc's that remain in one
section. If the program is running in a non-zero section, a
global quantity encountered during the EA-calc (from either an
index register or indirect word) can cause the EA-calc to "change
sections". An example will make this more clear:
3,,100/ MOVE 1,@[200002,,100]
2,,100/ 3,,200
The EA-calc for this instruction computes a global address of
2,,100 from the indirect word in the literal. Since the indirect
bit is set in this word (bit 1 is the indirect bit in an EFIW),
the EA-calc routine fetches the word at 2,,100 and continues the
EA-calc. The final result of the EA-calc yields 3,,200 GLOBAL.
This isn't a very interesting example, because it doesn't
demonstrate the significance of the section change, so let's look
at a slightly different example:
3,,100/ MOVE 1,@[200002,,100]
2,,100/ 400000,,200
In this example, the first part of the EA-calc remains the same
and the routine fetches the word at 2,,100. In this case,
however, the result of the EA-calc yields a local address instead
of a global one. But what section is the address local to? The
rule says that a local address is always local to the section from
which the address word was fetched. Since the EA-calc changed
from section 3 to section 2 when the last address word was
fetched, the EA-calc is relative to section 2 and the EA-calc
yields 2,,200 LOCAL.
o The default section for a local address is always that from
which the address word was fetched.
Now that we've seen what happens to EA-calc's that cross section
boundaries, let's see what happens if the EA-calc enters section
zero:
3,,077/ MOVEI 3,1
3,,100/ MOVE 1,@[200000,,100]
0,,100/ 3,,200
As with the example above, the EA-calc for this instruction
fetches the word at 0,,100 and continues. But since the EA-calc
entered section zero, this word is treated as an IFIW instead of
an EFIW. Therefore, the 3 in the left half of 0,,100 is
interpreted as the index register field instead of a global
section number. Since AC 3 contains a 1, the EA-calc yields
0,,201. In addition, the last address word was fetched from
section zero, so the result is a local address.
Page 17
o An effective address calculation which "falls" into section
zero always results in an effective address that is local (to
section zero). Furthermore, the effective address calculation
can never "get out" of section zero once it enters it because
all addresses in section zero are treated as local. Further
operations obey section zero rules.
Page 18
8.0 Special case instructions
Other than modifications to the EA-calc algorithms when the PC is
in a non-zero section, most instructions are unaffected by the
addition of extended addressing. However, there are a few classes
of instructions that behave differently on an extended machine
from the way they would on a non-extended machine. This section
describes the behavior of each class of instruction that has this
characteristic.
Examples in this section sometimes use the POINT pseudo-op to
describe a byte pointer. For those readers who do not know what
this pseudo-op generates, a description can be found in the Macro
manual.
8.1 Byte instructions
The effective address calculation for a byte instruction addresses
the byte pointer word(s). The instruction then does another
EA-calc on the byte pointer after determining which one of the
three possible byte pointer formats was supplied.
8.1.1 Byte pointer interpretation
The algorithm for determining the type of the byte pointer is as
follows:
+---------------+
| P field > 36? | ----> One-word global
+---------------+ Yes
|No
|
V
+---------------+
+<---- | Section 0? |
| Yes +---------------+
| |No
| |
| V
| +---------------+
| | Bit 12=1? | ----> Two-word global
| +---------------+ Yes
| |No
| |
V V
+--------------+-------------> One-word local
Byte pointer decode algorithm
The "Section 0?" test in the flow chart is based on where the
first word of the two-word global byte pointer was fetched from
Page 19
and not on PC section. This is an important distinction if the
byte instruction and the byte pointer are not in the same section.
o For byte instructions, the test for the possibility of a
two-word global byte pointer is done based on the section from
which the first word of the byte pointer was fetched. That
is, if the section from which the first word of the byte
pointer was fetched is non-zero, the byte pointer may be
global.
8.1.2 Byte pointer EA-calc
The default section for the byte pointer EA-calc is initially that
from which the byte pointer was fetched. Once again, this may be
different from PC section if the instruction and byte pointer are
in different sections. If we realize that the byte pointer is
really an address word, this is an extension of the rule that says
local addresses are local to the section from which the address
word was fetched. For example:
3,,100/ LDB 1,@[2,,100]
2,,100/ POINT 6,200,0
In this example, the byte instruction is fetched from section 3.
The EA-calc for the instruction follows an EFIW into section 2 and
the byte pointer is fetched. The byte pointer is in one-word
local format, so the EA-calc of the byte pointer results in a
local address. But is the address local to section 3 (section
containing the byte instruction) or 2 (section containing the byte
pointer)? The rule says that byte pointer EA-calc's start off
local to the section from which the byte pointer was fetched, so
the EA-calc is local to section 2. The result of the EA-calc is
therefore 2,,200 LOCAL.
Note that, while the initial default section may be that
containing the byte pointer, the default section may change if the
EA-calc encounters a global quantity. For example:
3,,100/ LDB 1,@[2,,100]
2,,100/ POINT 6,@[200004,,100],0
4,,100/ 400000,,200
As in the previous example, the byte pointer is fetched from
section 2. The byte pointer has the indirect bit set, so the byte
pointer EA-calc follows the EFIW in the literal (which also has
the indirect bit set) into section 4, where the final address word
is fetched from location 4,,100. This final address word is an
IFIW, so the result of the EA-calc is a local address. Even
though the byte pointer EA-calc started in section 2, the result
of the EA-calc is local to section 4, because that's where the
last address word was fetched from. The byte pointer EA-calc
results in an effective address of 4,,200 LOCAL.
Page 20
o For byte instructions, the initial default section for the
byte pointer EA-calc is the section from which the byte
pointer was fetched, which may not be the same section as that
containing the byte instruction. Further, if the EA-calc
results in a local address, the address is local to the
section from which the last address word in the effective
address calculation was fetched.
8.2 EXTEND instructions
Like the byte instructions, certain EXTEND instructions perform
another EA-calc for the byte pointer (MOVSxx, CMPSxx, CVTBDx,
CVTDBx, and EDIT). The AC field of the EXTEND instruction
addresses a block of ACs, that contain the byte pointers. In
addition, some EXTEND instructions perform an EA-calc on the
extended opcode word, which is interpreted in IFIW format. The
extended opcode word is addressed by the effective address of the
EXTEND instruction.
8.2.1 Byte pointer interpretation
The algorithm for determining the byte pointer format is the same
as that described for byte instructions with one exception. For
EXTEND instructions, the "Section 0?" test in the flow chart is
based on PC section.
o For EXTEND instructions, the test for the possibility of a
two-word global byte pointer is done based on PC section.
That is, if PC section is non-zero, the byte pointers may be
global.
8.2.2 Byte pointer EA-calc
The default section for the byte pointer EA-calc is initially PC
section even if other parts of the EXTEND instruction are in other
sections. For example:
Page 21
3,,100/ MOVEI 1,5 ;Source length
3,,101/ MOVE 2,[POINT 7,200] ;Source byte pointer
3,,102/ MOVEI 4,5 ;Destination length
3,,103/ MOVE 5,[POINT 7,300] ;Destination byte pointer
3,,104/ SETZB 3,6 ;Clear 2nd word of BPs
3,,105/ EXTEND 1,@[2,,100]
2,,100/ MOVSLJ ;Extended opcode is MOVSLJ
2,,101/ 0 ;Fill character is 0
In this example, the EXTEND instruction is in section 3 and the
EA-calc of the instruction follows an EFIW into section 2. The
EA-calc's for the one-word local byte pointers in ACs 2 and 5
generate local addresses of 200 and 300 respectively. But are
they local to section 3 (PC section) or to section 2 (section
containing the extended opcode)? Because the byte pointers are
fetched from the ACs, which are implicitly in PC section, the
EA-calc is relative to PC section. Once again, this is a
conceptual extension to the rule that local addresses are local to
the section from which the address word (in this case, the byte
pointer) was fetched.
As with byte instructions, the default section of the EA-calc may
change if the EA-calc encounters a global quantity. An example of
this for the EXTEND instruction would be analogous to that for
byte instructions given above.
o For EXTEND instructions, the initial default section for the
byte pointer EA-calc is PC section.
One interesting aspect of this rule is demonstrated by the
following example:
3,,100/ MOVEI 1,5 ;Source length
3,,101/ MOVE 2,[POINT 7,200] ;Source byte pointer
3,,102/ MOVEI 4,5 ;Destination length
3,,103/ MOVE 5,[POINT 7,300] ;Destination byte pointer
3,,104/ SETZB 3,6 ;Clear 2nd word of BPs
3,,105/ EXTEND 1,@[0,,100]
0,,100/ MOVSLJ ;Extended opcode is MOVSLJ
0,,101/ 0 ;Fill character is 0
In this example, the EXTEND instruction is in a non-zero section
(3) and the extended opcode is in section zero. Even though part
of the processing of the instruction fell into section zero, the
EA-calc of the byte pointers is still done relative to PC section.
Hence, the result is the same as in the previous example.
Page 22
8.2.3 Extended opcode EA-calc
Some EXTEND instructions also perform an EA-calc on the extended
opcode word. In this case, the default section for the EA-calc is
initially the section from which the extended opcode word was
fetched. For example:
3,,100/ MOVEI 1,5 ;Source length
3,,101/ MOVE 2,[POINT 7,200] ;Source byte pointer
3,,102/ MOVEI 4,5 ;Destination length
3,,103/ MOVE 5,[POINT 7,300] ;Destination byte pointer
3,,104/ SETZB 3,6 ;Clear 2nd word of BPs
3,,105/ EXTEND 1,@[2,,100]
2,,100/ MOVST 200 ;Extended opcode is MOVST
2,,101/ 0 ;Fill character is 0
As in the last example, the EXTEND instruction EA-calc follows an
EFIW into section 2 to fetch the extended opcode word from
location 2,,100. In this example, the extended opcode turns out
to be a MOVST which addresses a translation table with the result
of the EA-calc of the word. This EA-calc results in a local
address which is local to the section from which the address word
was fetched. Therefore, the table is read from locations starting
at 2,,200 LOCAL.
o The initial default section for the EA-calc of the extended
opcode word under an EXTEND instruction is that from which the
extended opcode word was fetched.
8.2.4 EDIT pattern and mark addresses
In addition to byte pointer type determination, the EDIT
instruction under EXTEND interprets the pattern string and mark
addresses differently based on PC section. If PC section is zero,
both addresses are limited to 18-bit addresses in section zero and
the result of setting bits 6-17 non-zero is undefined.
Conversely, if PC section is non-zero, both addresses are treated
as full 30-bit global addresses and no default sections are
applied. An example of this is too complex to be given here and
will be left as an exercise to the reader.
8.3 JSP and JSR
In a non-extended machine, these two instructions store the flags
and an 18 bit PC before jumping to the effective address. This is
also true if the instructions are executed in section zero of an
extended machine. Because this format is insufficient to store a
full 30-bit address, the operation of the instructions is modified
when the PC is in a non-zero section. Instead of storing the
Page 23
flags and PC, these instructions store the full 30-bit PC
(actually PC+1), omitting the flags. For example:
2,,100/ JSP 1,200
stores 2,,101 in AC 1 before jumping to location 2,,200.
Similarly,
2,,100/ JSR 200
stores 2,,101 in 2,,200 before jumping to location 2,,201. Note
that for JSR, the PC is stored in the word addressed by the
effective address even if that address is in another section,
e.g.,
2,,100/ JSR @[3,,200]
In this case, the EA-calc for the JSR results in an effective
address of 3,,200 GLOBAL. Therefore, 2,,101 (PC+1) is stored in
3,,200 (EA) before jumping to 3,,201 (EA+1).
An interesting aspect of this is demonstrated by the following
example:
2,,100/ JSP 1,@[0,,100]
Because the PC is in a non-zero section, the instruction stores
2,,101 in AC 1 and then jumps to location 0,,100. But an attempt
to return to the caller in section 2 via the usual JRST (1)
instruction would fail, because the EA-calc of the return
instruction, done in section zero, would fail to produce a 30-bit
global address. As a result, it is difficult to write a
subroutine in section zero that can be called via JSP or JSR from
an arbitrary section.
A final example illustrates the difference between a local and
global EA for JSR:
2,,200/ JSR 777777
The EA-calc for this case results in a value of 2,,777777 LOCAL.
Therefore, 2,,201 (PC+1) is stored in 2,,777777 (EA) and the
destination of the jump is 2,,0 (EA+1 local). This is consistent
with the rule that local addresses always wrap around in section
when incremented.
The global analogy is as follows:
2,,200/ JSR @[2,,777777]
In this case, the result of the EA-calc is 2,,777777 GLOBAL so the
instruction stores 2,,201 (PC+1) into location 2,,777777 (EA) as
in the last example. The difference is in the destination of the
jump. Because the effective address is global, incrementing it
produces 3,,0 GLOBAL (EA+1 global) as the destination of the jump.
Page 24
See the section on instruction fetches below for additional
information on these two cases.
o If PC is in a non-zero section, the JSP and JSR instructions
store a full 30-bit PC in the appropriate place instead of
storing flags and PC. This is true even if the destination of
the jump is in section zero.
8.4 Stack instructions
In a non-extended machine (and an extended machine in section
zero), the stack pointer typically contains a negative control
count in the left half and an 18-bit address in the right half.
Such a stack pointer is called a local stack pointer. Because
this format is insufficient to hold a full 30-bit stack address,
an additional format for stack pointers is allowable when the PC
is in a non-zero section. In this format (called a global stack
pointer), the stack pointer is positive, bits 6-17 are non-zero,
and bits 6-35 of the word are interpreted as the global address of
the stack.
If the stack pointer is in local format, the stack address is
local to PC section. For example:
2,,100/ MOVE 17,[-100,,200]
2,,101/ PUSH 17,300
Because the left half of the stack pointer is negative, it is in
local format. Therefore, the stack address is 2,,200 LOCAL,
because the stack is local to PC section.
o Local stack pointers are always local to PC section.
o The test for the possibility of a global stack pointer is done
based on PC section. That is, if PC section is non-zero, the
stack pointer may be global.
Note that a PUSH-type stack operation done on a local stack
pointer that has overflowed (i.e., the left half of the pointer
has gone to zero) changes the stack pointer to global format.
The type of stack pointer also determines how the stack address is
incremented or decremented. For example, consider the following:
Page 25
2,,100/ MOVE 17,[-100,,777777]
2,,101/ PUSH 17,200
The stack pointer in this example is local, so the stack address
is 2,,777777 LOCAL. When the PUSH instruction increments the
pointer, it does so section-local, resulting in an incremented
stack address of 2,,0 LOCAL (which actually references AC 0). The
stack pointer would then look like -77,,0.
Let's look at the same example with a global stack pointer:
2,,100/ MOVE 17,[2,,777777]
2,,101/ PUSH 17,200
With a global stack pointer, the increment is done globally,
resulting in an incremented stack address of 3,,0 GLOBAL (which is
memory location 0 in section 3). The stack pointer would then
look like 3,,0.
o Incrementing or decrementing a local stack pointer wraps
around in section. Conversely, the same operation on a global
stack pointer may cross section boundaries.
In addition to the requirement for a global stack pointer to
specify a full 30-bit stack address, the operation of the PUSHJ
and POPJ instructions is modified when the PC is in a non-zero
section. Like JSP and JSR, PUSHJ stores a full 30-bit PC (again,
actually PC+1) on the stack, omitting the flags. Similarly, POPJ
restores a full 30-bit PC from the stack instead of an 18-bit PC
local to PC section. Let's look at some examples:
2,,100/ MOVE 17,[-100,,200]
2,,101/ PUSHJ 17,400
Because PC section is non-zero, the PUSHJ stores 2,,102 on the
stack at location 2,,201, which was addressed by a local stack
pointer, and then jumps to location 2,,400. An updated stack
pointer of -77,,201 is stored back into AC 17. Similarly:
2,,400/ MOVE 17,[-77,,201]
2,,401/ POPJ 17,
restores the full 30-bit PC from stack location 2,,201 (addressed
by the local stack pointer) and then stores an updated stack
pointer of -100,,200 back into AC 17.
This behavior has some interesting aspects, as the next example
demonstrates:
Page 26
2,,100/ MOVE 17,[2,,200]
2,,101/ PUSHJ @[0,,300]
Because PC is in a non-zero section, the PUSHJ instruction stores
a full 30-bit PC (2,,102) on the stack at location 2,,201
(addressed by the global stack pointer). The jump is then made
into section zero. But an attempt to return to the caller with a
POPJ instruction will result in bedlam. In the first place, the
global stack pointer will be interpreted as a local one in section
zero. In addition, POPJ will assume that the stack word contains
flags and PC and restore an 18-bit PC, local to section zero.
As this example demonstrates, it isn't very practical to call
subroutines in section zero, from a non-zero section, using the
normal call/return conventions.
o If PC is in a non-zero section, the PUSHJ instruction stores a
full 30 bit PC on the stack. This is true even if the
destination of the jump is in section zero and regardless of
the format of the stack pointer.
o If PC is in a non-zero section, the POPJ instruction always
restores a full 30-bit PC from the stack.
8.5 JSA and JRA
These instructions use a format that is incompatible with extended
addressing. Because they are also considered an obsolete method
for subroutine call/return, no attempt has been made to find an
alternate format for these instructions when executed in a
non-zero section.
For compatibility with section zero programs, these two
instructions continue to work in non-zero sections. However,
their use is restricted to intra-section operation, and all
inter-section use is undefined.
In the case of JSA, the effective address is calculated in the
normal manner. However, if the EA-calc results in an address
outside of PC section, the action of the instruction is undefined.
For example, the results of:
2,,100/ JSA 1,@[3,,200]
are undefined because the effective address is in section 3 and PC
section is section 2. Note that a JSA which computes a global
effective address which addresses the last word of PC section is
also undefined. Let's look at an example of why this is true:
Page 27
2,,100/ JSA 1,@[2,,777777]
In this case, the microcode would store the contents of AC into
2,,777777 and attempt to jump to E+1. But because EA is global,
the computation of E+1 would result in 3,,0 GLOBAL which is
outside of PC section.
The normal usage of JRA is of the form JRA AC,(AC) and the
operation of the instruction is defined to take this into account.
After the normal effective address calculation is performed, PC
section is appended to the in-section addresses in AC to form the
address of where the old contents of AC were stored and the new PC
address. This forces all references to be in PC section. For
example,
2,,201/ MOVE 1,[200,,101]
2,,202/ JRA 1,(1)
restores AC from location 2,,200 (PC section plus contents of AC
left) and then jumps to 2,,101 (EA in PC section).
These definitions for JSA and JRA are consistent with the
operation of the instructions in section zero.
o The use of JSA and JRA in a non-zero section is restricted to
the case where the EA-calc results in an address in PC
section. All inter-section usage is undefined.
8.6 LUUOs
In a non-extended machine, LUUOs trap via a pair of locations (40
and 41) in exec or user virtual memory. Because this scheme is
insufficient to support extended addressing, the operation of
LUUOs is modified if the PC is in a non-zero section. In this
circumstance, the LUUO is processed through a four-word block
which is addressed by a word in the exec or user process tables.
See the PRM for more details.
o If PC is in a non-zero section, LUUOs trap through a four-word
block addressed by a location in the EPT (exec LUUO) or UPT
(user LUUO).
8.7 BLT
The format used for source and destination addresses by BLT is
insufficient to represent two 30-bit addresses. As a result, the
XBLT instruction was added to the instruction set to allow block
transfers from one arbitrary 30-bit address to another. Despite
Page 28
this, BLT is still useful for intra-section block transfers, and
the operation of the instruction has been changed slightly.
The initial source address is constructed by taking the 18-bit
address in the left half of the AC and appending it to the section
number and local/global flag from the effective address.
Similarly, the initial destination address is constructed from the
18-bit address in the right half of the AC and the section number
and local/global flag from the effective address. This means that
transfers are always to and from the same section as that
specified by the effective address, which need not necessarily be
the same as PC section. Source and destination addresses are then
incremented, section-local (even if EA is global) until the
destination address is equal to EA. For example:
2,,100/ MOVE 1,[200,,300]
2,,101/ BLT 1,@[3,,302]
In this example, the EA-calc for the BLT results in 3,,302 GLOBAL.
Using the rules above, the initial source and destination
addresses would be 3,,200 GLOBAL and 3,,300 GLOBAL. Therefore,
the following transfer would take place:
3,,200 => 3,,300
3,,201 => 3,,301
3,,202 => 3,,302
Let's look at an example that demonstrates the significance of
incrementing the addresses section-local:
2,,100/ MOVE 1,[777776,,300]
2,,101/ BLT 1,@[3,,302]
As in the previous example, EA is 3,,302 GLOBAL and the initial
destination address is 3,,300 GLOBAL. In this case, the initial
source address is 3,,777776 GLOBAL and the following transfer
takes place:
3,,777776 => 3,,300
3,,777777 => 3,,301
3,,0 => 3,,302
Note that the source address was incremented section-local even
though it was a global address.
It is important to note that the local/global flag must be
included in constructing the initial source and destination
addresses even though the addresses are always incremented
section-local. This is because the check for an AC reference is
done by including this flag. Let's look at two examples, one
whose EA is local and one whose EA is global:
Page 29
2,,100/ MOVE 17,[1,,200]
2,,101/ BLT 17,201
In this case, the result of the EA-calc for the BLT is 2,,201
LOCAL. Therefore, the initial source and destination addresses
are 2,,1 LOCAL and 2,,200 LOCAL, respectively. Because the source
is a local address whose in-section part is in the range 0-17, it
references AC 1. Now let's look at the global case:
2,,100/ MOVE 17,[1,,200]
2,,101/ BLT 17,@[2,,201]
In this case, the result of the EA-calc for the BLT is 2,,201
GLOBAL. Therefore, the initial source and destination addresses
are 2,,1 GLOBAL and 2,,200 GLOBAL, respectively. In this case,
the source address references memory location 2,,1 instead of the
ACs because the effective address is global. In both cases,
however, the addresses are incremented section-local.
o The initial source and destination addresses for BLT are
constructed by appending the appropriate half of the AC to the
section number and local/global flag from the effective
address. Incrementing of source and destination addresses is
always done section-local independent of the state of the
local/global flag. However, the determination of AC reference
is done via the normal rules by including the local/global
flag.
8.8 XBLT
The XBLT instruction is the one exception to the rule that a
section zero program cannot reference data in non-zero sections.
In this one case, the contents of AC+1 (source pointer) and AC+2
(destination pointer) are always treated as 30-bit global
addresses, even if the PC is in section zero. This means that a
program running in section zero can allocate a non-zero section
and XBLT code or data into it without having to jump into a
non-zero section to do it.
o The source and destination addresses for XBLT are always
interpreted as full 30-bit global addresses, even if the PC is
in section zero.
This means that the final addresses left in AC+2 and AC+3 at the
end of the XBLT may be inaccessible by other instructions in
section zero. For example:
Page 30
0,,100/ MOVEI 1,777777 ;Word count
0,,101/ MOVEI 2,20 ;Source address
0,,102/ MOVE 3,[2,,100] ;Destination address
0,,103/ EXTEND 1,[XBLT]
In this example, the transfer is from 0,,20 to 2,,100, and the
number of words transferred is 256K-1. The final source and
destination addresses left in ACs 2 and 3 are 1,,17 and 3,,77
respectively.
o For XBLT, the final values stored in AC+2 and AC+3 for source
and destination addresses are computed by adding the initial
word count to the initial source and destination addresses.
This computation is the same in all sections, including
section zero.
8.9 JRSTF
If the PC is in a non-zero section, JRSTF traps as an MUUO. This
is because JRSTF is usually used with an indirect word or index
register with PC flags in the left half. It is quite likely that
these flags would be mistaken for a global section number.
o If PC is in a non-zero section, JRSTF traps as an MUUO.
XJRSTF should be used in a non-zero section.
8.10 XMOVEI and XHLLI
Unlike other immediate instructions that use only 18 bits of the
effective address, these two instructions operate on all 30 bits
of EA. XMOVEI returns the full 30-bit effective address in AC.
XHLLI stores the section number of the effective address in the
left half of AC, leaving the right half unchanged.
One important implication of these two instructions is that they
convert a local reference to an AC in any non-zero section into
the global form. For example:
2,,100/ XMOVEI 1,6
The EA-calc of the XMOVEI results in 2,,6 LOCAL, which is a local
reference to AC 6. This result is then converted to the global AC
address of 1,,6 before being loaded into AC 1.
This conversion is not done if the AC reference is local to
section zero. For example:
Page 31
2,,100/ XMOVEI 1,@[200000,,6]
In this example, the EA-calc follows an indirect EFIW into section
zero. The result of the EA-calc is therefore 0,,6 LOCAL, which is
a local reference to AC 6. Because the effective address is in
section zero, it is not converted to the global form and 0,,6 is
stored in AC 1.
o If the effective address of an XMOVEI or XHLLI is a local
reference to an AC in a non-zero section, the AC address is
converted to a global AC address before being loaded into AC.
8.11 XCT
With the exception of the modification of the EA-calc rules in a
non-zero section, the XCT instruction operates in the same manner
as on a non-extended machine. The operation of the instruction
being executed, however, may be affected. This section describes
these cases and gives examples to demonstrate them.
8.11.1 Default section for EA-calc
If an instruction is executed by an XCT, the initial default
section for the EA-calc of that instruction is the section from
which the instruction was fetched. This may be different from PC
section if the XCT and the executed instruction are in different
sections. For example:
3,,100/ XCT @[2,,100]
2,,100/ MOVE 1,200
In this example, the XCT instruction is in section 3 and the
executed instruction is in section 2. The Ea-calc for the MOVE
yields a local address, which is local to the section from which
the MOVE was fetched. Therefore, the result of the EA-calc is
2,,200 LOCAL. This rule allows one to XCT an instruction in
another section and have local references generated by the
executed instruction be local to the section containing the
instruction.
Page 32
o The initial default section for the EA-calc of an instruction
executed by XCT is that from which the instruction was
fetched.
8.11.2 Relationship with skip and jump instructions
When a skip instruction is XCTed, the skip is always relative to
PC section, i.e., the section containing the XCT (first XCT if
there is a chain of XCTs). This is true even if the skip
instruction is in another section. For example:
3,,100/ XCT @[2,,300]
2,,300/ SKIPA 1,200
In this example, an XCT in section 3 executes a skip instruction
in section 2. Because this instruction always skips, the next
instruction is taken from location 3,,102 (PC+2), not 2,,302
(instruction+2). However, the EA-calc of the SKIPA instruction
results in 2,,200 LOCAL, so the contents of location 200 in
section 2 are stored in AC.
o If an XCT executes a skip instruction, the skip is always
relative to PC section, even if the skip instruction is in
another section.
The following example demonstrates the effect of XCTing a jump
instruction:
3,,100/ XCT @[2,,100]
2,,100/ JRST 200
In this example, an XCT in section 3 executes a jump instruction
in section 2. The EA-calc for the JRST results in an address
local to section 2, so the next instruction is taken from 2,,200,
not 3,,200.
o If an XCT executes a jump instruction that jumps, the next
instruction is fetched from the effective address of the jump.
This is true even if the XCT and the jump are in different
sections and the EA-calc of the jump results in a local
address whose section is different from PC section.
Page 33
8.11.3 PC storing instructions
When an XCT executes an instruction that stores PC as part of the
operation of the instruction (e.g., PUSHJ, JSP, etc.), the value
stored is relative to PC section (i.e., the XCT) and not the
section of the executed instruction. For example:
3,,100/ XCT @[2,,200]
2,,200/ JSP 1,300
In this example, an XCT in section 3 executes a JSP in section 2.
The next instruction is fetched from location 2,,300 because the
EA-calc of the JSP is local to section 2. However, the PC stored
in AC 1 is 3,,101 (XCT+1), not 2,,201 (JSP+1).
o If an XCT executes an instruction that stores PC as part of
its execution, the value stored is relative to the XCT and not
the executed instruction.
8.11.4 Local stack references
When an XCT executes a stack instruction that uses a local stack
pointer, the stack pointer is local to PC section and not to that
containing the stack instruction. For example:
3,,077/ MOVE 17,[-100,,300]
3,,100/ XCT @[2,,200]
2,,200/ PUSH 17,400
In this example, an XCT in section 3 executes a PUSH in section 2.
Since the EA-calc for the PUSH results in a local address, the
datum to be pushed is in the same section as the PUSH instruction
(at location 2,,400). However, the stack pointer is local to PC
section, not the section containing the PUSH. Therefore, the
datum is stored on the stack at location 3,,301.
o If an XCT executes a stack instruction whose stack pointer is
local, the stack is local to PC section, not the section
containing the stack instruction.
8.11.5 Generalizations for XCT
The examples above cover specific relationships between XCT and
the executed instruction. There are really two generalizations
(one of which was given above) that can be made about XCT, as
follows:
Page 34
1. The initial default section for the EA-calc of an XCTed
instruction is that from which the instruction was fetched,
and not the section from which the XCT was fetched.
2. Any test of PC section for determining whether section zero
rules or non-zero section rules apply is done based on the
section from which the XCT instruction was fetched (the first
one if there is a chain of XCTs). That is, PC section doesn't
change because an XCT executes an instruction in another
section.
Page 35
9.0 Summary of default sections for EA-calc
After covering all the special case instructions, it is worthwhile
to summarize the rules regarding the initial default section
number for EA-calc's. The initial default section for any EA-calc
is that from which the address word was fetched. This is true for
the simple cases as well as the more complex cases. The following
table gives the initial default section for the various kinds of
EA-calc:
EA-calc class Initial default section
_______ _____ _______ _______ _______
Instruction PC section
XCTed instruction Section containing the executed
instruction
Byte instruction Section containing the byte pointer
byte pointer
EXTEND instruction PC section
byte pointer
EXTEND instruction Section containing the opcode word
opcode word
Local stack PC section
pointer
Page 36
10.0 Section zero vs. non-zero section rules
As the previous discussion of special case instructions indicates,
some instructions do different things based on a test for section
zero. However, this test isn't always on PC section. We have
intentionally left out examples that demonstrate some of the
boundary conditions that make extended addressing hard to document
to avoid confusing the reader before the simple cases are
understood. This section includes examples of these boundary
conditions, and summarizes the rules for testing to see if section
zero rules apply.
The first example illustrates the test for the possibility of a
global byte pointer:
3,,100/ LDB 1,@[0,,200]
0,,200/ 000640,,300
0,,201/ 400000,,400
In this example, the byte instruction is in section 3 and the byte
pointer is in section 0. Note that bit 12 is set in the byte
pointer which, if global byte pointers are allowed, would indicate
a two-word global byte pointer. Is this byte pointer interpreted
as a one-word local or two a word global byte pointer? The rule
given in a previous section says that the test is made based on
the section from which the byte pointer was fetched. Therefore,
bit 12 is ignored, the byte pointer is interpreted in one-word
local format, and the byte is fetched from the word at location
0,,300.
Let's look at a similar case involving both XCT and EXTEND:
3,,100/ MOVEI 1,5 ;Source length
3,,101/ MOVE 2,[440740,,500] ;Source b.p. (1st wd)
3,,102/ MOVE 3,[5,,100] ;Source b.p. (2nd wd)
3,,103/ MOVEI 4,5 ;Destination length
3,,104/ MOVE 5,[440740,,300] ;Destination b.p. (1st wd)
3,,105/ MOVE 6,[5,,200] ;Destination b.p. (2nd wd)
3,,106/ XCT @[0,,100] ;Execute EXTEND in section 0
0,,100/ EXTEND 1,200
0,,200/ MOVSLJ ;Extended opcode is MOVSLJ
0,,201/ 0 ;Fill character is 0
In this example, the XCT is in section 3 and the entire EXTEND
instruction is in section zero. Both the source and destination
byte pointers have bit 12 set, which means they may be interpreted
as two-word global pointers. But are they? The rule given in a
previous section says that the test is made based on PC section,
which is non-zero. Therefore, the byte pointers are two-word
global and the string is moved from 5,,100 to 5,,200. If this
seems like an anomaly, remember that the test is based on PC
section because the byte pointers are fetched from the ACs.
References to ACs addressed by the AC field of the instruction are
Page 37
always made in PC section.
A final example combines an XCT with a JSR:
3,,100/ XCT @[0,,200]
0,,200/ JSR 300
In this example, the XCT is in section 3 and the JSR is in section
zero. The EA-calc of the JSR is local to section zero, so the
destination of the jump is 0,,301. But what is stored in 0,,300?
The rule given in a previous section says that the test is based
on PC section. Therefore, we store a full 30-bit PC (3,,101) into
location 0,,300.
o The test for section zero rules vs. non-zero section rules is
done based on PC section for all cases except byte
instructions. This is true even if the instruction is an XCT
which executes an instruction in another section (including
section zero).
o The test for section zero rules vs. non-zero section rules
for a byte instruction is done based on the section from which
the byte pointer was fetched.
It is important to realize that PC section may be different from
that containing the instruction being executed if an XCT (or chain
of XCTs) is involved. PC section is always that from which the
original instruction (the XCT if that instruction is involved) was
fetched. This is a subtle distinction, but it is important in
testing for section zero rules.
Page 38
11.0 Special consideration for ACs
On the PDP-10, the ACs are both general purpose registers and also
part of the virtual address space of every program. This dual use
is convenient but also confusing when one is attempting to
understand the rules of extended addressing. This section
describes some of the aspects of the relationship between extended
addressing and the use of the ACs.
11.1 AC references
An AC can be referenced in one of four ways as follows:
1. As a general purpose register through the AC field of an
instruction.
2. As an index register through the index register field of an
instruction or indirect word.
3. As a local memory reference to the first 16 (decimal)
locations of any section.
4. As a global memory reference to the first 16 (decimal)
locations of section 1.
In this discussion, we are concerned with the last two uses.
The rules for extended addressing say that memory references in
section zero are always local. Therefore, a section zero memory
reference can reference the ACs only if it is to the first 16
(decimal) locations in section zero. On the other hand, a memory
reference in a non-zero section can reference the ACs in two
different ways. If the memory reference is local, the ACs appear
in the virtual address space of every section as the first 16
locations. For example, both
2,,100/ MOVE 1,2
and
5,,100/ MOVE 1,2
reference AC 2 even though the addresses are local to different
sections.
In addition, the ACs may be referenced in a section-independent
way via a reference to global address 1,,n, where n is in the
range 0-17, inclusive. This means that an AC address can be
passed between two routines running in a non-zero section, even if
the routines are in different sections. For example:
Page 39
5,,100/ MOVE 16,[1,,6] ;Get global AC address for AC
5,,101/ PUSHJ 17,@[3,,200] ; 6 and call routine
:
:
3,,200/ MOVE 1,(16) ;Use global XR to fetch data
In this example, the calling routine in section 5 places the
global AC address for AC 6 into AC 16 and calls a routine in
section 3. Because 1,,6 is a global AC address, the called
routine interprets the index in global format and the data is
fetched from AC 6.
Note that an address of the form 1,,n, where n is in the range
0-17, will always reference the ACs, whether the address is local
or global. If the address is local, the reference is a local
reference to the ACs in section 1. If the address is global, it
is a global AC reference to the ACs.
o An address of the form 1,,n, where n is in the range 0-17,
inclusive, refers to the ACs whether it is a local or global
address. Therefore, such an address can be used to refer to
the ACs even if the state of the local/global bit is not
known.
11.2 Instruction fetches
All instruction fetches are made as local references, even though
the PC is a full 30-bit address. Therefore, an instruction is
fetched from the ACs whenever bits 18-35 of PC are in the range
0-17, inclusive, independent of the section number. Consider the
following example:
1,,100/ XJRST [3,,2]
This instruction sets the PC to 3,,2. However, the next
instruction fetch will come from AC 2 because it is made as a
local reference.
This behavior can have some implications for instructions that
also store information before changing PC. Consider the following
example:
1,,100/ JSR @[3,,2]
The JSR stores the current PC into memory location 3,,2 and then
changes the PC to 3,,3. The next instruction is then fetched from
AC 3 because of the local reference, but the old PC is in memory
and must be fetched with a global reference.
o Instruction fetches from C(PC) are always made as local
references even if PC was previously set to a global address.
Page 40
This means that instruction fetches from the first 16
(decimal) locations of any section cause the instruction to be
fetched from the ACs.
11.3 Storing PC
If an instruction that stores PC as part of its execution is
fetched from the ACs, the PC is stored as a full 30-bit address if
PC is in a non-zero section. For example:
3,,100/ MOVE 4,[JSP 2,200]
3,,101/ JRST 4
In this example, the MOVE instruction stores a JSP into AC 4, and
the JRST instruction computes a local effective address that
references the ACs. PC is set to 3,,4, but the next instruction
is fetched from AC 4 because instruction fetches are always made
as local references. Therefore, the next instruction to be
executed is the JSP. Because PC section is non-zero (it is still
3), the JSP must store a full 30-bit PC into AC 2. The important
thing to realize is that PC is 3,,4 and is not 0,,4 (a section
zero AC address) or 1,,4 (a global AC address). Therefore the JSP
stores 3,,5 (remember, it stores PC+1) into AC 2 and jumps to
3,,200.
o If an instruction that is fetched from AC stores PC as part of
its execution, the PC stored is a full 30-bit address
including PC section, if PC section is non-zero.
11.4 Storing EA for LUUO, MUUO and page fails
When an LUUO or MUUO is executed or an instruction page fails, the
microcode stores some information about the exception in a block
addressed by a word fetched from the UPT or EPT. The information
stored includes the effective address (or reference address in the
case of page fail) for the instruction that caused the exception.
If the resulting effective address is a local reference to an AC
in a non-zero section, the microcode converts this address to a
global AC reference before storing it in the block. This is the
same rule used for XMOVEI and XHLLI.
Page 41
o If the effective address of an LUUO or MUUO, or an instruction
that causes a page fail results in a local reference to the
ACs in a non-zero section, the microcode converts the local AC
reference to a global AC address before storing the result.
11.5 An example
Consider the following example that brings together all of these
rules:
3,,100/ MOVE 6,[001000,,10]
3,,101/ JRST 6
In this example, the MOVE stores an LUUO (opcode 001) into AC 6
and the JRST sets PC to 3,,6. The following list indicates the
significant actions that are performed to process the LUUO:
1. The EA-calc for the LUUO is performed and the result is 3,,10
LOCAL.
2. Because PC section is non-zero, the LUUO must be processed
through a four-word block addressed by a location in the UPT.
3. PC+1 must be stored as a full 30-bit address, including
section number. The value stored is 3,,7.
4. Because the EA-calc of the LUUO resulted in a local reference
to AC 10, it must be converted to a global AC address before
it is stored in the block. The value stored is therefore
1,,10.
Page 42
12.0 PXCT
When the monitor is invoked by an MUUO, page fail, etc., the
address space of the process that caused the invocation is
potentially different from that of the monitor. In order to
provide a communications mechanism between the monitor and the
so-called "previous context", the PXCT (for Previous context XCT)
instruction was defined. Although PXCT is normally considered as
a separate topic from extended addressing, there are interactions
between the two that make it desirable to talk about them
together.
Because PXCT is legal only in exec mode, there is no need to
define a new opcode for the instruction. Rather, the normal XCT
opcode is used, and a non-zero AC field distinguishes a PXCT from
a normal XCT. The opcode name PXCT is simply a notational
convenience to emphasize that the executed instruction is making
previous context references.
12.1 Previous context
For the purposes of this discussion, "previous context" is defined
by three processor state variables: Previous Context Section
(PCS), Previous Context User (PCU), and Previous AC Block (PAB).
PCS is a 12-bit state register (5 on the KL10) that gives the
value of PC section in the previous context at the time of the
event that invoked the monitor. PCU is a 1-bit register that
indicates that the previous context was user mode (as opposed to
exec mode). PAB is a 3-bit register that gives the AC block
number used by the previous context (there are typically multiple
AC blocks implemented by a machine, 8 in both KL10 and KC10. The
so-called "current ac block" is addressed by another 3-bit state
register called Current AC Block, or CAB). Therefore, the
previous context includes both the address space and ACs that were
in use at the time of the event that invoked the monitor.
When a context change occurs as the result of an MUUO, page fail,
interrupt, etc., the previous context state variables are set
according to a set of rules that are defined for each type of
context change. The specific rules aren't important for the
purpose of this discussion and the reader is referred to other
sources for more information. The important point is that the
state variable are set as the result of the context change.
In addition to being set on a context change, the monitor may also
set the state variables explicitly when it desires to make an
asynchronous reference to previous context.
These previous context state registers then direct references to
the previous context as described below. Note that the previous
context need not always be user mode. It is exec mode in cases
where the monitor makes a request of itself, such as the execution
of an MUUO by the monitor.
Page 43
12.2 Use of the previous context state variables
The state registers PCS, PCU, and PAB hold information necessary
to make a previous context memory or AC (as memory or index
register) reference. This section describes the use for each
register.
PCS is a 12-bit state variable that gives the value of PC section
in the previous context. It is used in the PXCT EA-calc algorithm
as described below to provide a default section number for a local
EA-calc. It is also used as the basis for the test for section
zero in some instructions that behave differently in non-zero
sections as described below. (For most instructions, the effect
is as if the instruction were executed in previous context.)
PCU is a 1-bit state variable that indicates that the previous
context was user mode. PCU is used to select the address space
for a previous context memory reference. That is, if the
reference is to previous context and PCU is set, the reference is
made to the user address space as mapped through the UPT.
Conversely, if the reference is to previous context and PCU is not
set, the reference is to the exec address space as mapped through
the EPT.
PAB is a 3-bit state variable that gives the AC block number for
the previous AC block. If an index register or AC is referenced
in previous context, PAB gives the number of the AC block
containing the data.
12.3 References to previous context
The PXCT mechanism allows the monitor to execute an instruction
such that certain references of the executed instruction are made
to the previous context. Conceptually, these references are made
as if the PXCTed instruction were being executed in the previous
context.
It is important to understand exactly which operations are
modified by PXCT. The instruction fetch and EA-calc of the PXCT
instruction and the fetch of the executed instruction are always
done in current context. In addition, all AC references (as the
result of bits 9-12 of the executed instruction) are made to the
current context ACs. The only difference between an instruction
executed under PXCT and one that is not is the way certain memory
and index register references are made. In particular, the
EA-calc of the executed instruction may reference indirect words
and index registers in previous context. Also, memory and AC
references made as the result of the EA-calc may be to previous
context. Exactly which references are made in previous context is
determined by the type of instruction that is being executed and
by the bits set in the AC field of the PXCT instruction.
Page 44
12.4 Applicable instructions
Not all instructions may be executed via PXCT. The use of PXCT is
limited to instructions that are useful to the monitor, and no
attempt is made to trap those cases that aren't applicable. The
instructions that may be executed are as follows:
MOVE class instructions
Halfword class instructions
EXCH
XMOVEI, XHLLI
BLT (with restrictions), XBLT
Arithmetic (integer and floating point) instructions
Boolean instructions
DMOVE class instructions
CAI and CAM class instructions
SKIP, AOS, and SOS class instructions
Logical test instructions
PUSH and POP (with restrictions)
Byte class instructions
MOVSLJ (with restrictions)
MAP
All other instructions are inapplicable, and the results of
executing an inapplicable instruction are undefined. Note that
this list explicitly excludes all instructions that jump.
12.5 Interpretation of the AC field bits
The four bits of the AC field of the PXCT instruction determine
which memory references of the executed instruction are made to
previous context. For most PXCTed instructions, the AC field bits
are logically grouped into two pairs (9-10 and 11-12) to control
how EA-calc and data references are performed. Within each pair,
the first bit (the generic "E control bit") causes index register
and address word references to come from previous context during
an EA-calc. The second bit (the generic "D control bit") causes
data fetches as the result of instruction execution to come from
previous context. When considered as a whole, bits 9-12 of the AC
field are named "E1", "D1", "E2", and "D2" but the generic names
("E" and "D") may be used when it is clear which bits control the
reference in question.
Not all executed instructions use both pairs of bits. In fact,
the great majority of applicable instructions use only bits 9 and
10; bit 9 for the EA-calc of the PXCTed instruction and bit 10
for the data reference made as the result of that EA-calc. A
notable example of the use of bits 11 and 12 to control previous
context references is the byte instructions. In this case, bit 11
controls the EA-calc of the byte pointer and bit 12 controls the
data reference to the word containing the byte. Some instructions
use other combinations of bits, e.g., BLT, EXTEND (MOVSLJ and
XBLT), and stack instructions.
Page 45
The previous context memory references controlled by each AC field
bit may be summarized by the following table:
Bit References made in previous context if bit is 1
9 (E1) Effective address calculation of instruction (index
registers, indirect words).
10 (D1) Memory operands specified by EA, whether fetch or store
(e.g, PUSH source, POP or BLT destination); byte
pointer.
11 (E2) Effective address calculation of byte pointer; source in
EXTEND (e.g., XBLT or MOVSLJ source); effective address
calculation of source byte pointer in EXTEND (MOVSLJ).
12 (D2) Byte data; source in BLT; destination in EXTEND (e.g.,
XBLT or MOVSLJ destination); effective address
calculation of destination byte pointer in EXTEND
(MOVSLJ).
There are obviously a limited number of valid combinations of AC
field bits for those instructions that may be PXCTed. The
following table gives the legal combinations. The "AC" column
gives the AC field value for the equivalent bits, e.g., the AC
column would contain a 4 for a 0 1 0 0 bit string.
E1 D1 E2 D2
Instructions AC 9 10 11 12 References
General 4 0 1 0 0 Data
14 1 1 0 0 E, data
PUSH, POP 4 0 1 0 0 Data
14 1 1 0 0 E, data
Immediate 10 1 - 0 0 E (no data reference)
BLT 5 0 1 0 1 Source data, destination data
15 1 1 0 1 E, source data, destination
data
XBLT 2 0 0 1 0 Source data
1 0 0 0 1 Destination data
3 0 0 1 1 Source data, destination data
Page 46
Byte 1 0 0 0 1 Byte data
3 0 0 1 1 Pointer E, byte data
7 0 1 1 1 Pointer, pointer E, byte data
17 1 1 1 1 E, pointer, pointer E, byte
data
MOVSLJ 1 0 0 0 1 Destination pointer E,
destination data
2 0 0 1 0 Source pointer E, source data
3 0 0 1 1 Source pointer E, destination
pointer E, source data,
destination data
Note that BLT, PUSH, POP, and MOVSLJ have restrictions on what
memory references can be PXCTed. For BLT, all references,
optionally including the EA-calc, must be done in previous
context. The results of PXCTing a BLT where source but not
destination or destination but not source is in previous context
are undefined. The LDPAC and STPAC instructions should be used to
transfer the previous ACs to and from current context. In all
other cases, XBLT must be used to transfer data between current
and previous context.
For PUSH and POP, the stack must always be in current context.
This means that previous context references for PUSH and POP are
limited to the EA-calc and data reference made to the location
addressed by the EA-calc. PUSH and POP therefore reduce to the
"general" case.
For MOVSLJ, if source or destination data is in previous context,
the source or destination byte pointer EA-calc must be done in
previous context also. If the monitor wishes to force a current
context EA-calc for a previous context data reference, it can
compute the effective address of the byte word and use a one- or
two-word global byte pointer. The microcode will still do the
EA-calc in previous context, but no previous context defaults will
be applied.
12.6 Modifications to the EA-calc algorithm
The appropriate "E" and "D" control bits from the AC field of the
PXCT instruction are used to modify an EA-calc done on the
executed instruction or a subsequent EA-calc done by the
instruction (e.g., byte pointer). This modification involves pre-
and post-processing the normal effective address calculation
algorithms to conditionally include PCS at two points.
If the appropriate "E" control bit is set, the initial default
section for the EA-calc is set to PCS. Since the "E" control bit
also controls previous context indirect word and index register
references, this means that the entire EA-calc is done in previous
context. If the "E" control bit is not set, the initial default
Page 47
section for the EA-calc is that from which the address word was
fetched, and the EA-calc is done in current context.
When the normal EA-calc is completed, the resulting value is
post-processed. If the result of the EA-calc was a local address
AND the "E" control bit was not set AND the "D" control bit was
set, the section number of the EA-calc is replaced by PCS. Note
that the local/global flag remains local if this is done.
The application of PCS at the end of the EA-calc may seem to make
no sense at first glance, so let's take a closer look at it.
Remember that the purpose of PXCT is to allow the monitor to
reference data in the previous context as if the user had supplied
it. If the user supplies a local address in, for example, a JSYS
argument, the monitor should make the data reference local to the
section in which the user was running. By applying PCS at the end
of the EA-calc as indicated above, the microcode automatically
makes the reference to the correct section.
This algorithm may be described by the following flow chart:
Page 48
+-----------------+
| Set initial |
| default section |
+-----------------+
|
V
+-----------------+
| "E" control |No
| bit set? |---->-+
+-----------------+ |
|Yes |
V V
+-----------------+ |
| Initial default | |
| section := PCS | |
+-----------------+ |
|<--------------+
V
+-----------------+
| Perform normal |
| EA-calc |
+-----------------+
|
V
+-----------------+
| "D" control |
| bit set? |
| AND |
| "E" control |No
| bit not set? |---->-+
| AND | |
|EA-calc resulted | |
| in a | |
| Local address? | V
+-----------------+ +---> Final EA
|Yes |
V A
+-----------------+ |
| EA[6:17] := PCS | |
+-----------------+ |
| |
V A
+--->-----------+
PXCT EA-calc algorithm
Page 49
Assume that PCS is 1 and consider the following example:
2,,100/ PXCT 4,[MOVE 1,100]
MOVE is one of the "general" class of opcodes, so bits 9 and 10 of
the PXCT AC field control the previous context references. In
this example, bit 9 (The "E1" bit) is off and bit 10 (the "D1"
bit) is on. Therefore, the EA-calc is done in current context
with a result of 2,,100 LOCAL. Because the "D1" bit is on, the
"E1" bit is off, and the result of the EA-calc is local, the PXCT
EA-calc algorithm applies PCS to bits 6-17 of the EA-calc. The
final effective address is therefore 1,,100 LOCAL and the data
reference is made to that location in previous context.
Let's look at another example. Assume that PCS is 2 and that the
following locations exist in previous context:
2,,200/ 200003,,300
3,,300/ 400000,,400
In current context, the following instruction is executed:
1,,100/ PXCT 14,[MOVE 1,@200]
In this example, both the "E1" and "D1" bits are on in the PXCT AC
field. Therefore, the EA-calc is done in previous context and the
initial default section for the EA-calc is set to 2 (PCS).
Location 2,,200 in previous context contains an indirect EFIW that
the EA-calc follows into section 3. The final address word
fetched from previous context location 3,,300 is in IFIW format,
so the result of the EA-calc is local to the section from which
the address word was fetched. The result of the EA-calc is 3,,400
LOCAL. Because the "D1" bit is also set, the MOVE fetches data
from previous context location 3,,400.
A final example demonstrates the result of an EA-calc that
references an AC. Assume that PCS is 3.
2,,100/ PXCT 4,[MOVE 1,2]
As with the first example, the EA-calc is done in current context
and PCS is applied to bits 6-17 of the result to produce an
effective address of 3,,2 LOCAL. Just as in the non-PXCT case,
this is a local reference to AC 2. Because the "D1" bit is set,
the reference is made to previous context AC 2 in the AC block
specified by PAB.
Page 50
o The EA-calc of a PXCTed instruction may be pre- or
post-processed as directed by the AC field control bits of the
PXCT instruction. Except for this additional processing, the
EA-calc algorithms and results are exactly the same as for the
non-PXCT case. This includes the uses for the local/global
flag.
12.7 Section zero vs. non-zero section rules
Of the instructions that may be PXCTed, there are three types
(stack, byte, and MOVSLJ) that operate differently in non-zero
sections and section zero. When one of these instructions is
PXCTed, the test for zero/non-zero rules may not be the same as
the test when there is no PXCT involved. The interaction of PXCT
with each of the instruction types is covered separately below.
12.7.1 Stack instructions
When no PXCT is involved, the test for the possibility of a global
stack pointer is done based on PC section. When a PUSH or POP
instruction is PXCTed, the previous context references are limited
to the EA-calc and the datum addressed by the EA-calc, and the
stack reference is always made in current context. Because the
stack is in current context, the interpretation of the stack
pointer type is made based on the current context PC section and
is not dependent on PCS. For example, assume that PCS is 0.
2,,100/ MOVE 1,[3,,1000]
2,,101/ PXCT 4,[PUSH 1,200]
In this example, PC section is non-zero and the stack pointer in
AC 1 has a global format. The test to determine whether the stack
pointer is allowed to be global is still made based on PC section
(even though there is a PXCT involved), and not on PCS.
Therefore, the stack pointer is indeed global and previous context
location 0,,200 is pushed onto the stack in current context
location 3,,1001.
o When a stack instruction (PUSH, POP) is PXCTed, the test for
the possibility of a global stack pointer is done based on PC
section.
o When a stack instruction is PXCTed, local stack pointers are
always local to PC section.
Page 51
12.7.2 Byte instructions
Normally, the byte instruction test for the possibility of global
byte pointers is done based on the section from which the byte
pointer was fetched. When a byte instruction is PXCTed, this rule
continues to apply, with extensions to include the possibility
that the byte pointer may be fetched from previous context. This
is best explained with several examples.
Assume that PCS is 0 and that the following locations exist in
previous context:
0,,100/ 400000,,200
0,,200/ 12
In current context, the following instruction is executed:
2,,300/ PXCT 3,[LDB 1,400]
2,,400/ 000640,,0
2,,401/ 400020,,100
For PXCT of byte instructions, bits 9 (E1) and 10 (D1) direct the
EA-calc of the byte instruction and the fetch of the byte pointer.
Bits 11 (E2) and 12 (D2) direct the EA-calc of the byte pointer
and the fetch of the word containing the byte. In this example,
the "D1" bit is off, so the byte pointer is fetched from current
context location 2,,400. Bit 12 is on in the byte pointer, and a
test must be made to see if it may be global. The byte pointer is
global because it was fetched from current context section 2, and
the fact that PCS is zero is not considered.
The "E2" bit and the "D2" bit of the PXCT AC field are both on, so
the byte pointer EA-calc is done in previous context. The second
word of the two-word global byte pointer has the indirect bit set,
and the next address word is fetched from previous context
location 0,,100. The final result of the EA-calc is 0,,200 LOCAL
in previous context and bits 30-35 of that word are extracted and
placed in current context AC 1.
Let's look at a similar example in which the byte pointer is also
fetched from previous context. Once again assume that PCS is 0
and the previous context contains the following locations:
0,,400/ 000640,,100
0,,401/ 400000,,200
0,,100/ 10
0,,200/ 20
In current context, the following instruction is executed:
2,,300/ PXCT 7,[LDB 1,400]
Page 52
In this case, the "D1" bit of the PXCT AC field is set, so the
byte pointer is fetched from previous context location 0,,400. As
in the last example, bit 12 is set in the byte pointer. But
because the byte pointer was fetched from previous context section
0, bit 12 is ignored and the byte pointer is interpreted in
one-word local format. The EA-calc is done in previous context
and results in an effective address of 0,,100 LOCAL. The byte is
then fetched from bits 30-35 of previous context location 100.
o When a byte instruction is PXCTed, the test for the
possibility of a global byte pointer is done based on the
section from which the byte pointer was fetched. This is true
independent of whether the byte pointer is fetched from
current or previous context.
This interpretation, while correct architecturally, causes some
problems for TOPS-20 as it is implemented today because TOPS-20
copies byte pointers from the previous context into current
context. Ideally, when a JSYS does a byte instruction on behalf
of the user, the byte pointer would be interpreted exactly as if
the user had executed the byte instruction. Thus, if the byte
pointer were fetched from section 0, it would be interpreted as a
local pointer; if it were fetched from any other section, it
would be interpreted as possibly being global. This can be
accomplished by using PXCT 7, as indicated in the example above.
Because TOPS-20 copies the byte pointer from the previous context
into current context, one that looks like a global byte pointer
will be interpreted as a global byte pointer even if it is fetched
from previous context section zero. This is because the monitor
typically runs in a non-zero section and the PXCTed byte
instruction fetches the byte pointer from current context. Hence
the test for the possibility of a global byte pointer is made
based on current context section rather than previous context
section.
12.7.3 EXTENDed MOVSLJ instruction
If no PXCT is involved, the MOVSLJ test for the possibility of a
global byte pointer is made based on PC section. If a PXCT is
involved, the test is more complex because it is based on PC
section if the PXCT control bit for the byte pointer is off and on
PCS if the PXCT control bit is on. For example, assume that PCS
is zero and that previous context contains the following
locations:
0,,200/ ASCII|ABCDE|
0,,300/ ASCII|FGHIJ|
Page 53
In current context, the following instruction sequence is
executed:
3,,100/ MOVEI 1,5 ;Source length
3,,101/ DMOVE 2,[440740,,200 ;Source BP (word 1)
400000,,300] ;Source BP (word 2)
3,,102/ MOVEI 4,5 ;Destination length
3,,103/ DMOVE 5,[440740,,400 ;Destination BP (word 1)
400000,,500] ;Destination BP (word 2)
3,,104/ PXCT 2,[EXTEND 1,600] ;PXCT the MOVSLJ
3,,600/ MOVSLJ ;Extended opcode is MOVSLJ
3,,601/ 0 ;Fill character is 0
In this example, the "E2" bit is set in the PXCT AC field, which
indicates that the source EA-calc and string reference are to be
made to previous context. Conversely, the "D2" bit is off, which
indicates that the destination EA-calc and string references are
to be made to current context.
Because the source-in-previous control bit is set in the PXCT AC
field, the test for the possibility of a global source byte
pointer is made based on PCS. In this case, PCS is zero, so bit
12 is ignored in the byte pointer and it is interpreted in
one-word local format. The byte pointer EA-calc results in 0,,200
LOCAL in previous context.
On the other hand, the destination-in-previous control bit is not
set, so the test for the possibility of a global destination byte
pointer is made based on PC section. Since PC section is non-zero
and bit 12 is set, the byte pointer is interpreted in two-word
global format, and the byte pointer EA-calc results in 3,,500
LOCAL in current context.
The result is to transfer the string "ABCDE" from previous context
location 0,,200 to current context location 3,,500.
o When a MOVSLJ instruction is PXCTed, the test for the
possibility of a global byte pointer is done based on PC
section if the appropriate PXCT control bit is off. If the
bit is on, the test is done based on PCS.
APPENDIX A
EA-CALC FLOWCHARTS
The following pages contain the EA-calc flowcharts from the
Processor Reference Manual (page 1-30) and from the KL10
Engineering Functional Spec.
Page Index-1
INDEX
AC references . . . . . . . . . 38
global . . . . . . . . . . . . 38
local . . . . . . . . . . . . 38
Address word . . . . . . . . . . 5
BLT . . . . . . . . . . . . . . 27
AC references . . . . . . . . 28
source and destination addresses 28
Byte instructions . . . . . . . 18
Byte pointer decode . . . . . . 18
Byte pointer EA-calc
byte instructions . . . . . . 19
EXTEND instructions . . . . . 20
Byte pointer type
byte instructions . . . . . . 18
EXTEND instructions . . . . . 20
EA-calc . . . . . . . . . . . . 9
algorithm . . . . . . . . . . 9
EFIW with global index . . . 11
IFIW with global index . . . 10
IFIW with local index . . . 10
no indexing . . . . . . . . 9
section 0 . . . . . . . . . 11
summary . . . . . . . . . . 11
byte instructions . . . . . . 18
byte pointers . . . . . . . . 19
default section . . . . . . . 12
default sections . . . . . . . 35
EXTEND instructions . . . . . 20
flowcharts . . . . . . . . . . A-1
local or global result . . . . 12
local/global flag . . . . . . 14
multi-section . . . . . . . . 16
results . . . . . . . . . . . 12
section zero . . . . . . . . . 16
Effective address calculation . 9
EFIW . . . . . . . . . . . . . . 6
EXTEND instructions . . . . . . 20
byte pointer EA-calc . . . . . 20
byte pointer type . . . . . . 20
extended opcode EA-calc . . . 22
Extended addressing
EA-calc . . . . . . . . . . . 9
historical summary . . . . . . 4
reference materials . . . . . 3
terms . . . . . . . . . . . . 5
address word . . . . . . . . 5
EFIW . . . . . . . . . . . . 6
global address . . . . . . . 5
Page Index-2
global index . . . . . . . . 6
global stack pointer . . . . 7
IFIW . . . . . . . . . . . . 6
illegal indirect word . . . 6
local address . . . . . . . 5
local index . . . . . . . . 5
local stack pointer . . . . 7
one-word global byte pointer 7
one-word local byte pointer 7
two-word global byte pointer 7
virtual address . . . . . . 5
Extended format indirect word . 6
Extended opcode EA-calc . . . . 22
Global AC address . . . . . . . 14
Global address . . . . . . . . . 5
Global index . . . . . . . . . . 6
Global stack pointer . . . . . . 7
Global stack pointers . . . . . 24
IFIW . . . . . . . . . . . . . . 6
Illegal indirect word . . . . . 6
Incrementing EA . . . . . . . . 15
Instruction fetches . . . . . . 39
Instruction format indirect word 6
JRA . . . . . . . . . . . . . . 26
EA-calc . . . . . . . . . . . 26
JRSTF . . . . . . . . . . . . . 30
JSA . . . . . . . . . . . . . . 26
EA-calc . . . . . . . . . . . 26
JSP . . . . . . . . . . . . . . 22
storing PC . . . . . . . . . . 23
JSR . . . . . . . . . . . . . . 22
storing PC . . . . . . . . . . 23
Local AC references . . . . . . 14
Local address . . . . . . . . . 5
Local index . . . . . . . . . . 5
Local stack pointer . . . . . . 7
Local stack pointers . . . . . . 24
Local/global flag . . . . . . . 14
LUUO . . . . . . . . . . . . . . 27
Multi-section EA-calc . . . . . 16
Non-zero section rules . . . . . 36
One-word global byte pointer . . 7
One-word local byte pointer . . 7
PAB . . . . . . . . . . . . . . 42 to 43
PC store . . . . . . . . . . . . 40
PCS . . . . . . . . . . . . . . 42 to 43
PCU . . . . . . . . . . . . . . 42 to 43
Page Index-3
Previous context
applicable instructions . . . 44
references . . . . . . . . . . 43
state registers . . . . . . . 42
use . . . . . . . . . . . . 43
PXCT . . . . . . . . . . . . . . 42
AC field bits . . . . . . . . 44
EA-calc algorithm . . . . . . 46
flow chart . . . . . . . . . 48
local/global flag
byte instructions . . . . . 51
MOVSLJ . . . . . . . . . . . 52
stack instructions . . . . . 50
Section zero rules . . . . . . . 36
Stack instructions . . . . . . . 24
storing PC . . . . . . . . . . 25
Stack pointers . . . . . . . . . 24
default section . . . . . . . 24
incrementing . . . . . . . . . 24
Storing EA . . . . . . . . . . . 40
Two-word global byte pointer . . 7
Virtual address . . . . . . . . 5
XBLT . . . . . . . . . . . . . . 29
non-zero section references . 29
XCT . . . . . . . . . . . . . . 31
default section for EA-calc . 31
local stack references . . . . 33
PC storing instructions . . . 33
skip and jump instructions . . 32
stack instructions . . . . . . 33
XHLLI . . . . . . . . . . . . . 30
AC references . . . . . . . . 30
XMOVEI . . . . . . . . . . . . . 30
AC references . . . . . . . . 30