Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
DE~MANDE~S OU BR~/ETS YOLUMlNEl3X
LA PRÉSENTE PART,IE 1:9E CETTE DEMANDE OIJ CE BREVET
COMPREND PLUS l)'UN TONlE.
l 3
CECI EST LE TOME _ DE ~
NOTE: Pour les tornes additionels, veuillez contactsr le Bureau canadien des
brevets
ll~q ~ ~ .
.
JlJMBO APPLIC~TIONSIPATENTS
THIS SECTION OF THE APPLICATION/PATEINT CONTAINS MORE
THAN ONE VOLUNlE
1 3
THIS IS VOLUME r l)F _
NOTE: For additional volumes please contact the Canadian Pa~ent Office
lt~91)63
CROSS REFERENCE TO REL~TED APPLICATIONS
The present patent applica-tion is related to copending
Canadian patent applications 403,453, 403,454, 403,455 and 403,457
all filed May 21, 1982 and assigned to the assignee of the
present application.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a digital data
processing system and, more particularly, to a multiprocess
digital data processing system suitable for use in a data
processing network and having a simplified, flexible user
interface and flexible, mu]tileveled internal mechanisms.
2. Description of Prior Art
A general trend in the development of data
processing systems has been towards systems suitable for use in
interconnected data processing networks~ Another trend has
been towards data processing systems wherein the internal
structure of the system is flexible, protected from users, and
effectively invisible to the user and wherein the user is
presented with a flexible and simplified interface to the system.
Certain problems and shortcomings affecting the
realization of such a data processing system have appeared
repeatedly in the prior art and must be overcome to create a
data processing system having the above attributes. These prior '
art problems and limitations include the following topics.
cr/,~ -
;~.',
1 ~79 ~6 3
First, the data processing systems of the prior art
have not provided a system wide addressing system
suitable for use in common by a large number of data
processing systems interconnected into a networ~.
Add~e~sing systems of th~ prior art have not provided
su ficiently large addr~ss spaces and have no~ allowed
information ~o be permanently and uniquely identified.
Prior addressing systems have not made provisions for
information ~o be located and identiied as ~o type or
~ormat, and have not provided sufficient granularity~ In
addition, prior addressing sy~tems have reflected the
physica~ structure of particular data processing
systems. That is, the addressing systems have been
dependent upon whether a particular computer was, for
example, an 8, 16, 32, 64 or 128 bit machine. Since
prior data processing systems have incorporated
addressing mechanisms wherein the actual physical
structure of the processing sy~tem is apparent to the
user, the operations a user could perform have been
limited by the addressing mechanisms. In addition, prior
processor systems have operated as fixed word length
machines, further limiting user operationsO
Prior data processing systems have not provided
effective protection mechanisms preventing one user from
ef~ec~ing another user's da~a and ~rograms without
permission. Such protection mechanisms have not allowed
unique, positive identification of users requesting
~.~ 79063
access to information, or of information, nor have such
mechanisms been sufficiently flexible in operation. In
addition, access rights have pertained to the users
rather ~han ~o the information, so that control of access
rights has been difficult. Finally, prior art pro~ection
mechanisms have allowed the use of "Trojan ~orse
argumentsn. That is, users not having access rights ~o
certain information have been able to gain access to that
information through another user or procedure having such
access rights.
Yet another problem of thP prior art is that of
providing a simple and flexible interface user int~rface
to a data processing system. The character of user's
interface to a data processing system is determined, in
part, by the means by which a user refers to and
identifies operands and procedures of the userls programs
and by the instruction structure of the system. Operands
and procedures are customarily reerred to and identified
by some ~orm of logical address having points of
re~erence, and validity, only within a user's program~
These add~esses must be translated into logical and
physical addresses within a data processing sys~em aach
time a program is executed, and must then be frequently
retranslated or generated during execution of a programO
In addition, a user must provide specific instructions as
to data format and handling. As such reference to
operands or procedures typically comprise a major portion
9~)63
--4--
of the instruction stream of the user's program and
requires numerous machine translations and operations to
implementO A user's inter~ace to a conventional system
is thereby complicated, and the speed of execution of
proqrams reduced, because of the complexity of the
program references to operands and procedures.
A data processing system's instruction structure
includes both the instructions for controlling system
operations and the means by which these instructions are
executed. Conventional data processing systems are
designed to ef~icien~ly execute instructions in one or
two user languages, for example, FORTRA~ or COBOL.
Programs written in any other language are no~
efficiently executable. In addition, a user is often
faced with difficult programming problems when using any
high level languase other than the particular one or two.
languages that a particular con~entional system is
designed to utilize.
Yet another problem ln conventional data processing
systems is that of protecting the system 1 5 internal
mechanisms, for example, stack mechanisms and internal
control mechanisms, from accidental or malicious
interference by a u er.
Finally, the internal structure and operation of
prior art data processing systems ha~e not been flexible,
or adaptive, in structure and operation~ That is, the
internal structure structure and operation of prior
systems have not allowed the systems to be easily
1~790f~ -
modified or adapted to meet particular data processing
re~uirements. Such modifications may include changes in
internal memory capacity, such as the addition or
deletion of special purpose subsystems, for example,
floating point or array processors~ In addi~ion, such
modifications have significantly effected the users
interface with the system. Ideally, the actual physical
structure and operation of the data proc2ssing system
should not be apparent at the user interface.
The present invention provides data processing sys~em
improvements and features which solve the above-described
~roblems and limi~ations.
The present invention relates to structure and
operation of a data processing system suitable for use in
interconnected data processing networks, which internal
structure is flexible, protected from users, ef~ectively
invisible to users, and provides a flexible and
simplified interface to users. The da~a processing
system provides an addressing mechanism allowing
permanent and unique identiication of all information
generated for use in or by operation of the systeM, and
an extremely large address space which i9 accessible to
and common ts all such da~a processing systems. The
addres~ing mechanism provides addresses which are
independent of the physical configuration of the system
and allow information to be completely identified, with a
~7~63
single address, to the bit granular level and with regard
to in~ormation type or format. The present invention
further provides a protection mechanism wherein variable
access rights are associated with individual bodies o
information. Information, and use~s requesting access to
information9 are uniqu ly identified through the system
addressin~ mechanism. The protection mechanism also
prevents use o~ Trojan ~orse arguments. And, the present
invention provides an instruction structure wherein high-
level usPr language instructions are transformed intodialect coded, uniform, intermediate level instructions
to provide equal facility of execution for a plurality of
user languages. Another feature is the provision of an
operand reference mechanism wherein operands are referred
to in user's programs by uniform format names which are
transformed, by an internal mechanism transparent to the
user, into addresses. The present invention addi~ionally
provides multilevel control and stack mechanisms
protecting the system's internal mechanism from
interference by usersO Yet another feature is a data
processing system having a flexible internal structure
capable of performing multiple, concurren~ operations and
comprised of a plurality of separate, independent
processors. Each such independent processor has a
separate microinstruction control and at least one
separate and independent port to a central communicatlons
and memory node. The communications and memory node is
also an independent processor having separate and
- \
~'79(~63
independent microinstruction con~rol. The memory
processor is internally comprised of a plurality of
independently operating, microinstruction controlled
processors capable o~ performing multiplet concurrent
memory and communications operation~. The present
invention also provides further data processing system
structural and operational features for implementing the
above features.
It is thus advantageous to incorporate the present
invention into a data processins system because the
present invention provides addressing mechanisms suitable
for use in large interconnected data processing
networks. Additionally, the present invention is
advantageous in that it provides an information
L5 protection mechanism suitable for use in large,
interconnected data processing networks. The present
invention is further advantageous in that it provides a
simplified, flexible, and more efficient interface to a
data processing system. ~he present invention is yet
further advantageous in that it provides a data
processing system which is equally efficient with any
user level language by providing a mechanism for
referring to operands in user prosrams by uniform format
names and instruction structure incorporating dialect
coded, uniform format intermediate level instructions.
Additionally, the present invention pro~ects data
processing system internal mechanisms from user
interference by providing multilevel con~rol and stack
11~79I~63
--8--
mechanisms. The present invention is yet further
advantageous in providing a flexible internal system
structure capable of performing multiple, concurrent
operations, comprising a plurality of sPparater
independent processors, ea~h having a sepaxate
microinstruction control and at least one separate and
independent port to a central, independent communications
and memory processor comprised of a plurality of
independent processors capable of par~orming multiple,
concurrent memory and communications operations.
It is thus an object of the present invention to
provide an improved data processing system.
It is another object of the present invention to
provide a data processin~ system capable of use in large,
interconnected data processing networks.
It is yet ano~her object of the present invention to
provide an improved addressing mechanism suitable for use
in large, interconnected data processing networks.
It is a further object of the present invention to
provide an improved information protection mechanism.
It is still another object of the present invention
to provide a simpliied and flexible user interface to a
data processing system.
Tt is yet a further object of the present invention
to provide an improved mechanism for referring to
operand~.
It is a still further object of the present invention
to provide an instruction structure allowing efficient
-
llt~9~63
- 9 -
data processing system operation with a plurality o~ high
}evel user languages.
It is a further object o the present invention to
provide data processing internal mechanisms protected
from user interference.
It is yet another sbject of the present invention to
provide a data processing system having a flexible
internal structure capable of multiple, concurrent
operations.
Other objects, advantages and features of the present
invention will be understood by those of ordinary skill
in the art, after referring to the ~ollowing detailed
description of the preferred embodiments and drawings
wherein: -
~ ~ 9~ hEY~
Fig. l is a partial block diagram of a computer
system incorporating the present invention;
Fig. 2 is a diagram illus~rating computer qystem
addressing struc~ure of the present invention;
Pig. 3 is a diagram illustrating the computer
system instruction stream of the present invention;
Fig. 4 is a diagram illustrating the control
structure of a conventional computer sys~em;
Fig. 4A is a diagram illustrating the control
structure o~ a computer system incorporating the present
invention;
Fig. 5 - Fig. Al inclusive are diagrams all
relating to the present invention;
1~'79C)63
--10--
Fig~ 5 is a diagr~m illustrating a stack
mechanism~
Fig. 6 is a diagram illustrating procedures,
procedure objects, processes, and virtual processors;
. 5 Fig. 7 is a diagram illustrating operating
levels and mechanisms of the present computer;
Fig. 8 is a diagram illu~trating a physical
implementation o~ processes and virtual processors;
Fig. 9 is a diagram illustrating a process and
10 ~process stack objects;
Fig. 10 is a diagram illustrating operation of
macrostacks and secure stacks;
Fig. 11 is a diagram illustrating detailed
structure of a stack;
Figa 12 is a diagram illustratins a physical
descrip~or;
Fig. 13 is a diagram illustrating the
relationship between logical pages and frameq in a memory
storage space;
Fig. 14 is a diagram illustrating access con~rol
to objects;
Fig. lS is a diagram illustrating virtual
processors and.virtual proce~sor swapping;
Fig. 16 is a partial block diagram o~ an I/O
system of the present compu~er system;
Fig..17 is a diagram illustrating operation o~ a
ring grant generator;
1~79~63
Fig. 18 is a partial block diagram of a memory
system;
Fig. 19 is a partial block diagram of a fe~ch
unit of the presen~ computer system;
Fig~ 20 is a partial block diagram of an execute
unit of the present computer system;
Fig. lOl is a more detailed partial block
diagram o the present computer system~
Fig. 102 is a diagram illus~rating certain
information structures and mechanisms o~ the present
computer system;
Fig. 103 is a diagram illustrating process
structures;
: Fig. 104 is a diagram illustrating a macrostack
structure;
Fig. 105 is a diagram illustratinq a secure
stac~ structure;
Figs. 106 A, B, and C are diagrams illustrating
the addressing structure of the present computer system;
Fig. 107 is a diagram illustrating addressing
mechanisms of the present computer system;
Fig. 108 is a diagram illustratin~ a name table
entry;
Fig. 109 is a diagram illustrating protection
mechanisms of the present computer system;
Fig. 110 is a diagram illustrating instruc~ion
and microinstruction mechanism of the present computer
system;
11~79063
~12--
Fig. 201 is a detailed block diagram of a memory
system;
- Fiq. 202 is a detailed block diagram of a fetch
unit;
s Fig~ 203 is a detailed block diagram of an
execute unit;
Fig. 204 is a detailed block diagram of an I/O
system;
~ig. 205 is a partial block:diagram of a
: 10 diagnostic processor system;
Fig. 206 is a diagram illustrating assembly of
Figs. 201-205 to form a detailed bloGk diagram of the
present computer system;
Fig. 207 is a detailed block diagram of a memory
interface controller;
Fig. 209 is a diagram of a memory to I/O system
port interface;
~ig. 210 is a diagram of a memory operand port
interface;
Fig. 211 is a diagram of a memory instruction
port interface;
Fig. 230 is a detailed block diagram o~ memory
field interface unit logic;
Fig. 231 is a diagram illustrating memory format
manipulation operations;
Fig. 238 is a detailed block diagram of fetch
unit offset multiplexer;
9063
--13--
~ ig. 239 is a detailed block diagram of fetch
unit bias logic;
Fig. 240 is a detailed block diagram of a
generalized four way, set associative cache representing
name cache, protection cache, and address transl~tion
unit;
Fig. 241 is a detailed block diagram of portions
of computer system instruction and microinstruction
control logic
Fig. 242 is a detailed block diagram of portions
of computer system microinstruction control logic;
Fig. 243 is a detailed block diagram of further
portions of computer system microinstruction co~trol
logic;
~ig. 244 is a diagram illustrating computer
system states of operation;
~ ig. 245 is a diagram illustrating computer
system states of operation for a trace trap request;
Fig. 246 is a diagram illustrating computer
20 system states of operation ~or a memory repeat interrupt;
Fig. 247 is a diagram illustrating priority
level and masking of computer system events ,.
Fig, 248 is a detailed block diagram of event
logic;
Fig. 249 is a detailed block diasram of
microinstruction control store logic;
Fig. 251 is a diagram illustrating a return
control word stack word;
- \
~79~63
--14--
Fig. 252 is a diagram illustrating machine
control word~;
Fig. 253 is a detailed block diagram of a
register address generator;
Fig~ 254 is a block diagram of interval and egg
timers;
Fig, 255 is a detailed block diagram of execute
unit control logic;
Fig. 257 is a detailed block diagram of execute
unit multiplier data paths and memory;
Fig. 260 is a diagram illustrating operation of
an execu~e unit command ~ueue load and interface to a
fetch unit;
Fig. 261 is a diagram illustrating operation of
an execu~e unit operand buffer load and interface to a
fetch unit;
Fig. 262 is a diagram illustrating operation of
an execute unit storeback or transfer of results and
interface to a fetch unit;
Fig. 263 is a diagram illustrating operation of
an execute unit check test condition and interface to a
fetch unit;
Fig. 264 is a diagram illustrating operation of
an execute unit exception test and interface to a fetch
unit;
Fig. 265 is a block diagram of an execute unit
arithmetic operation stac~ mechanism;
~79063
--15-- ,
Fig. 266 is a diagram illustrating execute unit
and fetch unit interrupt handshaking and interface;
Fig. 267 is a diagram illustrating execute unit
and fetch unit interface and operation for nested
interrupts;
Fig. 268 is a diagram illustrating execute unit
and fetch unit interface and operation for loading an
execute unit control store;
Fig. 26g is a detailed block diagram and
illustration of operation of an I/0 system ring grant
generator;
Fig~ 270 is a detailed block diagram of a fetch
uni~ micromachine of the present computer system;
Fig. 271 is a diagram illustrating a logical
descriptor;
Fig. 272 is a diagram illustrating use of fetch
unit stack registers;
~ ig. 273 is a diagram ilustrating struc~ures
controlling event invocations;
Fig. 301 is a diagram illu~trating pointer
formats; .
Fig. 302 is a diagram illustrating an associated
address table;
Fig, 303 is a diagram illustrating a namespace
overview of a procedure object;
Fig. 304 is a diagram illustrating name table
entries;
f
t79~3
-16-
Fig. 305 is a diagram illustrating an example of
name resolution;
Fig~ 306 is a diagram illustrating name cache
entries;
Fig. 307 is a diagram illQstrating translation
of S-interpreter universal identifiers to dialect
nu~bers;
Fig. 401 is a diagram illustrating operating
syQtems and system resources;
Fig. 402 is a diagram illustrating multiprocess
operating systems;
Fig. 403 is a diagram illustrating an extended
operating system and a kernel operating system;
Fig. 404 is a diagram illus~rating an EOS view
of objects;
Fig. 405 is a diagram illustrating pathnames to
universal identifier translation;
Fig. 406 is a diagram illustrating universal
identifier detail;
Fig. 407 is a diagram illustrating address
translation with an address translatioQ unit, a memory
hash tabie, and a memory;
Fig. 408 is a diagram illustrating hashing in an
active subje~t table;
~ig. 409 is a diagram illustrating logical
allocation unit and objects;
9()63
--17--
Fig. 410 is a diagram illustrating an active
logical allocation unit table and active allocation
units;
Fig~ 411 is a diagram illu~trating a conceptual
logical allocation unit directory structure;
~ig. 412 is a diagram illustrating detail of a
logical allocation unit directory entry;
Fig. 413 is a diagram illustrating universal
identifiers and active object numbers;
10~ig. 416 is a diagram illustrating subject
templates, primitive access control lis~ entries, and
: extended access control list entries;
Fig. 421 is a diagram illustrating an active
primitive access matrix and an active primitive access
matrix entry;
. Fig. 422 is a diagram illustrating primitive
data access checking;
FigO 448 is a diayram illustrating event
counters and await entries;
20Fig. 449 is a diagram illustrating an await
table overview
Fig. 453 is a diagram illustrating an overview
: of a virtual processor;
Fig. 454 is a diagram illustrating virtual
processor synchronization;
Fig. 467 is a diagram illustrating an overview
of a macrostack objec~;
l~t79~63
-18-
Fig. 468 is a diagram illustrating details of a
macrostack object base;
FigO 46g is a diagram illustrating details of a
macrostack frame;
Fl~. 470 is a diagram illustrating an overview
of a secure stack;
Fig~ 471 is a diagram illustrating de~ails of
secure stack frame; and,
~ ig. 472 is a diagram illustrating an overview
o~ p~ocedure object.
The followin~ description presents the structure and
operation of a computer system incorporating a presently
preferred embodiment of the present invention. As
15 indicated in the following Table of Contents, certain
features of compuker system structure and operation will
first be described in an Introductory Overview. Next,
these and other features will be described in further
detail in a more detailed Introduction to the detailed
descriptions of the computer sys~em. Following the
Introduction, the structure and operation of the computer
system will be described in detail. The detailed
descriptions will present descriptions of the structure
and operation of each of the major subsystems, or
elements, of the computer system, of the interfaces
between these major subsystems, and o~ overall computer
system operation. Next, certain features of the
operation of the individual subsystems will be presented
in further detail.
~91~6~
--19--
Certain conventions are used throughout the following
descriptions to enhance clarity of presentation. ~irqt,
and with exception of the IntroductoEy Overview, each
figure referred to in the following descriptions will be
referred to by a three digit number. ~he most
significant digit represents the number of he chapter in
~he followiny descriptions in which a par~icular figure
is first referred to. The two least significant digits
represent the sequential number of appearance of a figure
in a particular chapter. For example, Figure 319 would
be the nineteenth figure appearing in the third chapter.
Figures appearing in the Introductory Overview are
referred to by a one or two digit number representing the
order in which they are referred to in the Introductory
lS Overview. It should be noted that certain figure
numbers, for example, Figure 208, do not appear in the
following figures and descriptions; the subject matter of
these figures has been incorporated into other ~igures
a~d these figures deleted, during drafting of the
following descriptions, to enhance clarity of
presentation.
Second, reference numerals comprise a two digit
number ~00-99) preceded by the number of the figure in
which the corresponding elements first appear. For
example, reference numerals 31901 to 31999 would refer to
elements 1 through 99 appearing in Fig. 319.
~1~7~()63
--20--
Finally, interconnections between related circuitry
is represented in two ways. First, to enhance clarity of
presentation~ interconnections between circuitry may be
represented by common signal names or refere~ces~ rather
than by drawn represen~ations of wires or buses. Second,
where related circuitry is shown in two or more figures,
the figures may share a common figure number and will be
distinguished by a letter designation, for example, Figs.
319, 319A, and 319B. Common electrical points between
such circuitry may be indica~ed by a bracket enclosing a
ead to such a point and a designation of the farm ~A-b".
"A" indicates other figures having the same common point
for example, 319A, and "b" designates the particular
comm~n electrical point. In cases of related circuitry
shown in this manner in two or more ~igures, re~erence
numerals to elements will be assigned in sequence through
the group of figures; the figure number portion of such
reference numerals will be ~hat of the ~irst ~igure of
the group of ~igures9
20 .~ ~e~
A. ~ardware Overview (Fig. l~
B. Individual Operating Features (Figs. 2, 3, 4, 5, 6)
l. Addressing (Fig. 2)
2. S-Language Instructions and Namespace Addressing
Z5 (Fig. 3)
3. Architectural Base Pointer Addressing
4. Stack Mechanisms ~Figs. 4-5)
~t~9~3
-21-
C. Procedure Processes and Virtual Processors (Fig. 6)
D. CS 101 Overall Structure and Operation (Figs~ 7, 8,
9, 10, 11, 12, 13, 14, 15)
1. Introduction (Fig. 7)
2. Compilers 702 (Fig. 7)
3. Binder 703 (Fig. 7)
4O EOS 704 (Fig. 7)
5. ~OS and Architectural Interface 708 (Fig. 7)
6. Processes 610 and Virtual Processors 612 (Fig.
8)
7. ProcesseS 610 a~d Stacks (Fig. 9)
8~ ~rocesses 610 and Calls (Figs. 10, 11)
9. Memory References and the Virtual Memory
Management System (Fig. 12, 13)
10. Access Control (Fig. 14~
11~ Virtual Processors and Virtual Processor
Swapping (Fig. 15)
E. CS 101 Structural Implementation (Figs. 16, 17, 18,
19, 20)
1. (IOS) 116 (Figs~ 16, 17)
20 Memory (MEM) 112 (Fig. 18)
3~ Fetch Unit (FU) 120 (Fig. 19)
4. . Execute Uni~ (EU) 122 (Fig. 20)
1. ~e~
A. General Structure and Operation (Fig. 101)
a. General Structure
b. General Operation
1~79~63
--22--
c. Definition of Certain Terms
d. Multi-Program Operation
e. Multi-Language Operation
f. Addressing Structure
g. Protection Mechanism
B. Computer System lQ110 Information Structure and
Mechanisms (Figs. 102, 103, 104, 105)
a~ Introduction (Fig. 102~
b. Yrocess Struc~ures 10210 (Figs. 103, 1~4,
105)
1. Procedure Objects (Fig. 103)
2. Stack Mechanisms (Figs. 104, 105)
3. F~RSM 10214 (Fig. 103)
C. ~irtual Processor State Blocks and Virtual
Process Creation (Fig. 102)
D~ Addressing Structures 10220 (Figs. 103, 106,
107, lOR)
1. . Objects, UID's, AON's, ~ames, and Physical
Addresses (Fig. 106)
2. Addressing Mechanisms 10220 (Fig. 107)
3. Name Resolution (Figs. 103, 108)
4. Evalua~ion of AON Addresses to Physical
Addresses (FigO 107)
E. CS 10110 Protection Mechanisms ~Fig. 109)
F. CS 10110 Micro-Instruction Mechanisms (Fig. 110)
G. Summary of Cer~ain CS 10110 Features and
Alternate Embodiments.
~79 ~ ~ 3
-23-
2.
a ~-2~-2~
A. ME~ 10110 (Figs~ 201, 206~ 207-237)
a. Terminology
b. ~E~ 10112 Physical Structure (Fig. 201)
cO M~M 10112 General Operation
d. MEM 10112 Port Structure
1. IO Port Characteristics
2. JO Port Characteristics
3. JI Port Characteristics
e. MEM 10112 Control Structure and Operation
(Fig. 207)
1. ~EM 10112 Control Structure
2. MEM 10112 Contr~l Opera~ion
. ME~ 10112 Operations
g. MEM 10112 Interfaces to JP 10114 and IOS
10116 (Figs. 209, 210~ 211, 204
1. IO Port 20910 Operating
Characte~ls~ics (Figs 209, 204)
2. JO Port 21010 Operating
Characteristics (Fig. 210)
3~ JI Port 21110 Operating
Charactertiscis (Fig. 211)
h. FIU 20120 (Figs. 201, 230, 231)
B. Fetch Unit 10120 (Figs. 202, 206, 101, 103, 104,
238)
1. Descriptor Processor 20210 (Figs. 202,
101, 103, 10~, 238, 239)
~ '790~3
--24--
a. Ofset Processor 20218 Structure
b. AON Processor 20216 Structure
c~ Length proGessor 20220 Structure
d. Descriptor Processor 20218 Operation
a.a. Offset Selector 20238
b.b. Offset Multiplexer 20240 Detailed
S~ru ture (Fig. 238)
c.c. O~fset ~qultiplexer 2024Q Detailed
Operation
aaa. Internal Operation
bbb. Operation Relative to DESP
20210
e, Length Processor 20220 (Fig. 239)
a.a. Length ALU 20252
b.b. BIAS 20246 (Fig. 239)
fr AON Processor 20216
a.a. P~ON&RF 20232
b~bo AO~ Selector 20248
2. Memory Interface 20212 (Figs. 106, 240)
a.a. Descriptor Trap 20256 and Data Trap
2025~
b.b. Name Cache 10226, Addre~s ~ranslation
Unit 10228, and Protection Cache 10234
(Fig. 106)
c.c.. Structure and Operation of Generalized
Cache and NC 102~6 ~Fig. 240)
d.d. ATO 10228 and PC 10234
3O Fetch Unit Control Logic 20214 (Fig. 202)
a.a. Fetch Unit Control Logic 20214 Overall
Structure
,f~
r ~
7~9063
--25--
b.b. Fetch Unit Control Logic 20214
Qperation
a.a.a. ~refetcher 20264,
Instruction Buffer 20262,
Parser 20264, Operation Code
Register 20268, CPC 20270,
IPC 20272, and EPC 20274
(Fig., 241)
b.b~,b. Fetch Unit ~ispatch Table
11010, Execute Unit Dispatch
Table 20266, and Operation
Code Register 20268 (Fig.
242)
c.c.c. ~ext Address Generator 24310
(Fig. 243)
cc. FUCTL 20214 Circuitry for CS 10110
Internal Mechanisms (Figs. 244-250)
a.a.a. State Logic 20294 (Figs.
244A 244~)
2û b.b.b. Event Logic 20284 ~Figs.
245, 246, 247, ~48)
c.c.c. Fetch Unit S-Interpreter
Table 11û12 (Fig. 249)
d~.d. CS 10110 Internal Mechanism Control
25a.a.a. Return Control Word Stack
10358 (Fig. 251)
b.b.b. Machine Control Block (Fig.
252)
11'~90~3
-26-
c.c.c. Register Address Generator
202a8 (Fig. 253)
d.d~d. Timers 20296 (~ig. 254)
e.e.e. ~etch Unit 10120 Interace
- to Execute Unit 10122
C. Execute ~nit 10122 (Fig~. 203, 2S5-268)
: a. General Structure of Execute Unit 10122
1. Execute Unit I/O 20312
2. Execute Unit Control Logic 20310
3. M~ltiplier Logic 20314
4. Exponent Logic 20316
5~ Multiplier Control 20318
6. Test and Interface Logi~ 20320
b. Execute ~nit 10122 Operation (Fig. 255)
1. Execute Unit Control Logic 20310 (Fig.
: 255)
a.a. Command Queue 20342
b.b. Comm~nd Queue Event Control Store
25514 and Command Queue Event
Address Control Store 25516
c.c. Execute Unit S-Interpreter Table
20344
d.d. Microcode Control Decode Register
20346
e.e. Next Address Generator 20340
2. Operand Buf~er 20322 (Fig. 256)
3. Multiplier 20314 tFigs. 257, 258)
a.a~ Multiplier 20314 I/O Data Paths
and ~emory (Fig 257)
llt79~63
-27-
a.a.a. Container Size Check
b.b.b, Final Result Output
Multiplexer 20324
4. Test and Interface Logic 20320 ~Figs.
260-268)
a.a. F~ 10120/E~ 10122 Interace
a.a.a. Lo~ding of Command
Queue 20342 ~Fig. 260)
b.b.b. Loading of Operand
Bufer 20320 (Fig. 261)
c.c.~ Storeback (Fig. 262)
d.d.d. Test Conditions (Fig.
~63)
e.e.e. Exception Checking
(~ig. 264)
f.f~f. Idle Routine
g.g~g. EU 10122 Stack
Mechanisms (Figs. 265,
266, 267)
h.h~h. Loading of Execute Unit
S-Interpreter Table
20344 (Fig. 268)
D. I/O Sys~em 10116 (Figs. 204, 206, 269)
a. I/O System 10116 Structure (Fig. 204)
b. I/O System 10116 Operation (FigO 269)
1. Data Channel ~evlces
2. I/O Control Proce~sor 20412
3. Data Mover 20410 (Fig. 269)
a.a. Input Data Buffer 20440 and
Ou~put Data Buf~er 20442
1~'79~)~3
-28--
b~b~ Priority Resolution and Control
20444 (Fig. 269)
E. Diagnostic Processor 10118 (Fig. 101, 205)
~. CS 10110 ~icromachine Structure and Ope~ation
(Figs. 270-274)
a. Introduc~ion
bo Overview of 9evices Comprising F~
Micromachine (Fig. 270~
1. Devices Used By Most Microcode
a.a. MOD Bus 10144, JP~ Bus 10142, and
DB Bus 27021
b.b. Microcode Addressing
c.c. Descriptor Processor 20218 (Fig.
271)
d.d. EU 10122 Inter~aCe
2. Specialized Micromachine Devices
a.a. Instruction Stream Reader 27001
b~b. SOP Decoder 27003
cOc. ~ame Translation Unit 27015
d.d. Memory R~eren~e Unit 27017
e.e. Protec~ion Unit 27019
f.f~ ROS Micromachine Devices
c. Micromachine Stacks and ~icroroutine Calls
and Returns t~igs. 272, 273)
lo Micromachine Stacks (Fig. 272)
2. ~icrom chine Invocations and Returns
3. Means of Invoking Microroutines
11~75~)63
-29- -
4. Occurrence o~ Event Invocations (FigO
273)
d. Virtual Micromachines and Monitor
Micromachine
1. Virtual Mode
2. Monitor Micromachine
e. Interrupt and Fault ~andling
1. General Principles
~. ~ardware Interrupt and Fault Handling
in CS 10110
3O Monitor Mode: Differen~ial Masking
and ~rdware Interrupt ~andling
g. FU Micromachine and CS 10110 Subsystems
3.
1QlL=2~gl
. Pointers and Pointer Resolution (Figs. 301, 302)
a. Pointer Formats (Fig. 301)
b. Pointers in F~ 10120 (Fig. 302)
c. Descriptor to Pointer Conver~ion
B. Namespace and the S-Interpreters (Figs. 303-307)
a. Procedure Object 606 Overview ~Fig. 303)
b. ~amespace
1. ~ame Resolution and Evaluation
2. The Name Table ~Fig. 304)
3. Architectural Base Pointers (Figs.
305, 306)
~79C~3
-30-
a.a. Resolving and Evaluating Names
(FigO 305)
b.b. Implementation of Name Evaluation
and ~ame Resolve in C5 10110
c.c. Name Cache 10226 Entries (Fig~
306)
d.d. Name Cache 10226 ~its
e.e. Name Cache 10226 ~isses
f.f. Flushing Name Cache 10226
g.g. Fetching the Instr~lction Stream
1~ h.h. Parsing the Instruction Stream
c. The S-Interpreters (Fig. 307)
1. Translating SIP into a Dialect ~umber
. 307)
2. Dispatching
15 4~ o~ bD5=~5b~
A. Introduction
a. Operating Systems (Fig. 401)
1. Resources Controlled by Operating
Systems (Pig7 402)
b. The Operating 5ystem in CS 10110
c. Extended Operating System and the ~ernel
Operating System (Fig. 403)
B. Objects and Object Management (Fig~ 404)
a. Objects and User Programs (Fig. 405)
b. UIDs 40401 (Fig. 406)
c~ Object Attributes
li~79063
d. Attributes and Access Control
e. Implementation o~ Objects
1. Introduction ~Figs 407, 408)
Objects in 8econdary Storage 10124
(~igs ~0~, 410~
a.a. Representation of an Object's
: Contents on Secondary 5torage
10124
b.b. LAUD 40903 (Figs. 411, 412)
3. Active Objects (Fig. 413)
a.a. UID 40401 to AO~ 41304
Translation
C. The Access Control System
a. Subjects
b. Domains
c. Access Control Lists
13 Subject Templates (Fig. 416)
20 Primitive A~cess Control Lists ~PACLs)
3. APA~ 10918 and Protection Cache lOZ34
~Fig. 421)
40 Protection Cache 10234 and Protection
Checking ~Fig. 422)
D. Processes
lo Synchronization of Processes 610 and
Virtual Processors 612
a. Event Counters 44801, Await Entries 44804,
and Awai Tables (Fig. 448, 44g)
9O ~ 3
-32-
b. Synchronization ~ith Even~ Counters 44801
and Await Entries 44804
E. Virtual Processors 612 tFig. 453)
a. Virtual Processor ~anagement (Fig. 453)
b. Virtual Processors 612 and Synchronization
(Fig~ 454)
F~ Process 610 Stack ~anipulation
1. Introduction to Call and Return
2. ~acrostac~ (MAS~ 502 (Fig. 467)
a.a. MAS Basa 10410 (Fig. 468
b.b. Per-domain Data Area 46853 (Fig~
. ~68)
c.c. ~AS Frame 46709 Detail (Fig. 469)
3. SS 504 ~Fi~ 470)
- a.a~ SS Base 47001 (Fig. 471)
b.b. SS Frames 47003 (Fig 471)
a~a.a~ Ordinary SS Frame
~eaders 10514 (Fig.
471)
b.b.b. Detailed Structure of
. Macrostate 10516 (Fig.
47~)
c.c.c. Cross-domain SS Frames
47039 (Fig. 471)
4. Portions of Procedure Objec~ 608
Relevant to Call and Return (Fig~ 472)
5. Execution of ~ediated Calls
a.a. Mediated Call SINs
~790~3
o33-
b.b. Simple Mediated Calls ~Figs. 270 r
468, 469, 470, 471, 472)
C.G. Invocations of Procedures 602
. Re~uiring SEBs 468~4 (Figs. 270,
468, 469, 470, 471, 472)
d.d. Cross-Procedure Object Calls
(Fi~s. 210, 468, 469, 470, 471,
~72)
e.e. Cross-Domain Calls (Figs. 270,
408, 418, 468, 469, 470, 471,
472)
f.~ Failed Cross-Domain Calls (Figs.
: 270, 468, 469, 470, 471, 472)
6. Neighborhood Calls (Figs. 468t 469,
' 472)
~5~
The following overview will first briefly describe
the overall physical structure and operation of a
presently preferred embodiment of a digital computer
20 system incorporating the present invention. Then certain
operating features o~ that computer system will be
individually describedO Next, overall operation of the
computer system will be descr ibed in terms of those
individual features.
11~79~)~3
--34--
A. ~ 5~uo~L4eL=lL s~
Referring to Figc 1, a block diagram of Computer
System (CS) 101 incorporating the present invention is
shown. ~ajor elements of CS 101 are I/O System (IOS)
116, ~emory (MEM) 112, and Job Processor (~P) 114~ JP
114 is comprised of a Fetch Unit (F~) 120 and an Execute
~nit (EU) 122~ CS 101 may also include a Diagnostic
Processor (DP), not shown or described in the instant
descrip~ion.
Referring first to IOS 116, a primary function of IOS
116 is control of transfer of information between MEM 112
and the outside world. Information is transferred from
MEM 112 to IOS 116 through IOM Bus 130, and from IOS 116
to ME~ 112 through ~IO Bus 129. IOMC Bus 131 is
15 comprised o~ bi-directional control signals coordinating
operation of MEM 112 and IOS 116. IOS 116 also has an
interface to ~U 120 ~hrough IOJP Bus 132. IOJP Bus 132
is a bi-directional control bus comprised essentially of
two interrupt lines. These interrupt lines allow ~U 120
20 to indicate to IOS 116 that a request for information by
FU 120 has been placed in ~EM 112, and allows IOS 116 to
inform FU 120 that informatîon requested by P~ 120 has
been transferred into a location in MEM 112. ME~ 112 is
CS 101's main memory and serves as the path for
25 information transfer between the outside world and JP
114. MEM 112 provides instructions and data to FU 120
and EU 122 through Memory Output Data (MOD3 Bus 140 and
receives information from F~ 120 and EU 122 through Job
9063
--35--
Processor Data (JP~) Bus 142. F~ 120 submits read and
write re~uests to ~E~ 112 through Physical Descriptor
tP~j Bus 146O
JP 114 is CS 101's CPU and, as described above, is
comprised of FU 120 and E~ 122. ~ primary ~unction o F~
120 is e~ecuting operations of user's programs. As part
of this func~ion, FU 120 controls transfer of
instructions and data from MEM 112 and t~an~fer of
results of ~P 114 operations back to MEM 112. FU 120
also performs operating system type functions, and is
capable of operating as a complete, general purpose CPU.
EU 122 is primarily an arithmetic and logic unit provided
to relieve F~ 120 of certain arithmetic operations. FU
120, howe~er, is capable of performing EU 122
operations. In alternate embodiments of CS 101, EU 122
may be provided only as an option for users having
particular arithmetic ~equirements. Coordination of F~
120 and EU 122 operations is accomplished throuyh FU/E~
~FUEU) Bus 148, which includes bi-directional control
signals and mutual interrupt lines. As described further
below, both FU 120 and EU 122 contain register file
arrays referred to respectively as C~F and ERF, in
addition to registers associated with, for example, ALUs.
A primary feature of CS 101 is that IOS 116, ~EM 112,
FU 120 and EU 122 each contain ~eparate and independent
microinstruction control, so that IOS 116, ~E~ 112, and
~U 122 operate asynchronously under the general control
of FU 120. EU 122, ~or example, may execute a complex
9~63
~36--
arithmetic operation upon receipt of data and a single,
initial command from FU 120.
~ aving brie~ly described the overall structu~e and
operation of CS 101, certain features of CS 101 will be
individually further described next below.
B.
1.. ~
Referring to ~ig. 2, a diagramic representation of
portions of CS 101's addressing structure is shown. CS
l0 101's addressing structure is based upon the concept of
Objects. ~n Objec~ may be regarded as a container for
holding a p rticular type of information. For example,
ona type of Object may contain data while another type of
Object may con ai~ instructions or procedures, such as a
15 user program. Still another type of Object may CQntain
microcode. In general, a particular Object may contain
onl~ one type or class of informtion. An Object may, for
example, contain up to 2 bi~s of information, but the
ac~ual size o~ a particular Object is flexible. That is,
20 the actual size of a particular Object will increase as
information is written ints that Object and will decrease
as information is taken from that Object. In general,
information in Objects is stored sequentially, that is
without gaps.
Each Object which can ever exist in any CS 101 system
is uniquely identified by a serial number referred to as
a Unique Identifier (UID). A UID is a 128 bit value
comprised of a serial number dependent upon, for example,
- \
1179C~3
--37--
the particular CS 101 system and user, and a time code
indicating time of creation of that Object. UIDs are
permanently assigned to Objects, no two Objects may have
the same UID, and UIDs may not be reused. UIDs provide
an ddressing base common to all CS 101 systems which may
ever exist, through which any Object ever created may be
: permanently and uniquely identified.
As described above, UIDs are 128 bit values and are
thus larger than may be conveniently handled in present
embodiments of CS 101. In each CS 101, therefore, those
Ob~ects which are active ~currently being used) in th~t
system are assigned 14 bit Active Object Numbers (AO~s).
Each Object active in that system will have a uni~ue
AO~. ~nlike UIDs, AONs are only temporarily assigned to
particular Objects. AONs are valid only within a
particular CS 101 and are not uni~ue between systems. An
Object need not physically reside in a system to be
assigned an AON, but can be active in that system only if
it has been assigned an AO~.
A particular bit within a particular Object may be
identified by means of a UID address or an AON address.
In CS 101, AO~s and AON addresses are valid only within
JP 114 while VIDs and UID addresses are used in MEM 112
and elsewhere. UID and AO~ addresses are formed by
appending a 32 bit Offset ~0~ field to that Object's UID
or AON. O fields indicate offset, or location, of a
particular bit relative to the start of a particular
Obiect.
1~79~63
-38-
Segments of information (sequences of information
~its) within particu~ar Objects may be identified by
means of descriptors. A UID descriptor is ~ormed by
appending a 32 bit Length (~) field of a UID address. An
5 AON, or logical descriptor is formed by appending a 32
bit L field to an AO~ address. L fields identi~y length
of a segment of information bits within an Object,
starting from the information bit identified by the UID
or AO~ address. In addition to length information, UID
and logical descriptors also contain ~ype fields
containing information regardin~ certain characteristics
o~ the information in the information segment. Again,
AO~ ba~ed descriptors are used within JP 114, while UID
based descriptors are used i~ ~EM 112.
Referring to FigsO 1 and 2 together, translation
between UID addresse~ and descriptors and AO~ addresses
a~d descriptors is performed at the interface between MEM
112 and JP 114. That is, addresses and descriptors
within JP 114 are in AON form while addresses and
descrip~ors in ~ M 112, IOS 116, and the external world
are in UID ~orm. In other embodiments ~ CS 101 using
A9~s, transformation from UID to AO~ addre~sing may occur
at other interfaces, for example at the IOS 116 to MEM
112 interface, or at the IOS 116 to external world
inter~ace. Other embodiments of CS 101 may use UIDs
throughout, that i5 not use AONs even in JP 114.
- J
11~79~63
-39-
Finally, information within MEM 112 i5 located
through MEM 112 Physical Addresses identifying particular
physical locations within ~EM 112lS memory space. Both
IOS 116 and JP 114 address information within MEM 112 by
providing physical add~esses to ~EM 112. In the case of
physical addresses provided by JP 114, these addresses
are referred to as Physical Deseriptors (PDs) As
described below, ~P 114 contains circuitry to translate
logieal descrip ors into physical descriptors~
2. ~
CS 101 is both an S-Language machine and a Namespace
machine. That is, operations to be executed by CS 101
are expressed as S-Language Operations ~SOPs) while
operands are identified by Names. SOPs are of a lower,
more detailed, level than user language instructions, for
example FORT~AN and COBOL, but of a higher level than
conventional machine language instructions. SOPs are
specific to particular user languages rather than a
20 particular embodiment of CS 101, while conventional
machine language instructions are specific to particular
machines. SOPs are in turn interpreted and exeauted by
microcode. There will be an S-Language Dialect, a set of
SOPs, for each user languages. CS 101, for example, may
have SOP Dialects f or COBOL, FORTRAN, and SPL. A
particular distinction of CS 101 is that all SOPs are of
a uniform, fixed length, for example 16 bits. CS 101 may
generally contain one or more sets of microcode for each
1~79~3
-40-
S-Language Dialect. These microcode Dialect Sets may be
completely distinct, or may overlap where more than one
SOP utilizes the same microcode.
As stated above, in CS 101 all operands are
identified by Nam2s, which are 8, 12, or 16 bit numbers.
CS 101 includes one or more "~ame Tables" containing an
Entry for each operand ~ame appearing in programs
currently being executed. Each ~ame Table Entry contains
information describing the operand referred to by a
particular ~ame, and the directions necessary for CS 101
to translate that information into a corresponding
logical descriptorO As previously describedt lcgical
descriptors may then be transformed into physical
descriptors to read and write operands from or to MEM
112. As described above, UIDs are unique for all CS 101
systems and AONs are unique within individual CS 101
systems. ~ames, however, are unique only within the
context of a userls program. That is, a particular Name
may appear in two different user's programs and, within
each program, will have different ~ame Table Entries and
will refer to diferent operands.
CS 101 may thereby be considered as utilizing two
sets of instructions. A ~irst set i5 comprised of SOPs,
that is instructions selecting algorithms to be
executed. The second set of instructions are comprised
of Mames, which may be regarded as entry points into
tables of instructions for making references r~garding
operands.
~1~79~63
--41--
Referring to Fig .3, a diagramic representation of CS
101 instruction stream is shown. A typical SIN is
comprised of an SOP and may include one or more Names
referring to operands0 SOPs and ~ames allow user's
5 proyrams to be expressed in very compact code. Fewer
SOPs than machine language instxuctions are re~uired to
express a user's program. Also, us~ of SOPs allows
easier and simpler construction of compilers, and
facilitates adaption o~ CS 101 systems to new user
10 languages. In addition~ use of ~ames to refer to operands
means that SOPs are independent of the form of the
operands upon which they operate. This in turn allows
for more compact code in expressing user prosrams in that
SOPs specifying operations dependent upon operand form
15 are not required.
3~ ~
As will be described further below, a user's program
residing in CS 101 will include one or more Objects.
First, a Procedure Object contains at least the SINs of
20 the user's programs and a Name Table con~aining entries
for operand Names of the program. The SINs may include
references, or calls, to other Procedure Objects
containing, for example, pEocedures available in common
to many users. Second, a Static Data Area may contain
static data, that is data having an existence for at
leas~ a sin~le execution of the program. And third, a
Macro-stack, described below, may contain local data,
that is data generated durin~ execution o~ a program.
Each Procedure Object, the Static Data Area and the
30 Macro-stack are individual Objects identified by UIDs and
-~17~6~3
--42--
AONs and addressable through ~ID and AON addresses and
descriptors.
Locations of information within a user's Procedure
Objects, Static Data Area, and Macro-stack are expressed
s as o~sets from one of three values, or base addresses,
referred to as Architectural Base Pointers (~BPs). For
example, location information in Name Tables is expressed
as offsets from one of the ABPs. ABPs may be expressed
as previously described.
The three ABPs are the Frame Pointer (FP), the
Procedure Base Pointer (PBP), and the Static Data Pointer
(SDP). Locations o~ data local to a procedure, for
example in the procedure's Macrostack, are described as
offsets from FP. Locations of non-local data r that is
Static Data, are des~ribed as offsets ~rom SDPo
Loca~ions o~ $IN~ in Proceds~re Objects are expressed ~s
og sets ~om P~g; these o~S~t5 are determine~ as a
Program Coun~er (PC~ value. Va7ues o~ the ABPs vary
during pro~ram execution and are therefore not provided
20 by the compiler converting ~ user's high level language
program into a program to be executed in a CS 101
sy~tem. When the program is executed, CS 101 provides
the proper values for the ABPs. Whe~ a program is
actually being executed, the ABP's values are stored in
25 FU 120's GRF.
~1~79063
--43--
Other pointers are used, for example, to identify the
top frame of CS 101's Secure Stack (a microcode level
stack described below) or to identify the microcode
Dialect currently being used in execute the SINs of a
procedure. These pointers are similar to EP, SDP, and
PBP~
4. 5e~s~_ oeu~ ib~ s:~=t=~l
Referring to Fig. 4 and 4At diagramic representations
of various control levels and stack mechanisms of,
respectively, conventianal machines and CS 101, are
shown. Referring first to Fig. 4, top level of control
is provided by User Language Instructions 402, or
example in FORTRAN or COBOL. User Language Instructions
402 are converted into a greater number of more detailed
Machine Language Instructions 404, used within a machine
to execute user's programs. Within the machine, Machine
Language Instructions 404 are interpreted and executed by
Microcode Instructions 406, that is sequences of
microinstructions which in turn directly control ~achine
20 ~ardware 408. Some conventional machines may include a
Stack Mechanism 410 used to save current machine state,
that is current microinstruction and contents of various
machine registers, if a current Machine Language
Instruction 404 cannot be executed or is interrupted. In
general, machine state on the microcode and hardware
level is not saved. Execution of a current Machine
Language Instruction 404 is later resumed at tart of the
microinstruction sequence for executing ~hat Machine
Language Instruction 404.
1179~3
~44--
Referring to Fig. 4A, top level control in CS 101 is
by User Language Instructions 412 as in a conven~ional
machine. In CS 101, however, User Language Instructions
412 are translated into SOPs 414 which are of a higher
level than conventional machine language instructions.
In general, a single User Language Instruction 412 is
transformed into at most two or three SOPs 414, as
opposed to an entire sequence of conventional ~achine
Language Instructions 404. SOPs 414 are interpreted and
executed by Microcode Instructions 416 (sequences of
microinstructions) which directly control CS 101 ~ardware
418. CS 101 includes a Macro-stack Mechanism (~AS) 420,
at SOPs 414 level, which is comparable to but different
in construction and operation from a conventional Machine
15 Lan9uase Stack Mechanism 410. CS 101 also includes
Micro-code Stack ~echanisms 422 operating at Microcode
416 level, so that exe~ution of an interrupted
microinstruction of a microinstruction sequence may be
later resumed with the particular microinstruction which
20 was active at the time of the interrupt. CS 101 is
therefore more efficient in handling interrupts in that
execution of microinstruction sequences is resumed from
the particular poin~ that a microinstruction sequence was
interrupted~ rather from the beginning of khat sequence.
25 As will be described further below, CS 101's Micro-code
Stack Mechanisms 422 on microcode level is effectively
comprised of two stack mechanisms. The first stack is
Micro-instruction Stack (MIS) 424 while the second stack
is referred to as Monitor Stack (MOS) 426. CS 101 SI~
30 Microcode 428 and MIS 424 are primarily concerned with
~79~63
45--
execution of SOPs of user's programs. Monitor ~icrocode
430 and MOS 426 are concerned with operation of certain
CS 101 internal functionsO
Division o~ CS 101's microcode stacks into an MIS 424
5 and a MOS 426 illustrates a further feature of CS 101.
In conuentional machines, monitor functions may be
performed by a separate CPU operating in conjunction with
the machine's primary CPU~ In CS 101, a single hardware
CPU is used ~o perform both functions with actual
10 execution of both functions performed by separate groups
of microcodeO Monitor microcode operations may be
initiated either by certain SI~s 414 or by control
signals generated directly by CS 101ls ~ardware 418.
Invocation o~ Monitor Nicrocode 430 by Hardware 418
15 generated signals insures that CS 101's monitor functions
may always be invoked.
Referring to Fig. S t a diagramic representation o~ CS
lOl's stack mechanisms for ~ ~ins~ oaram,
~ y ~ shown. 8asically, and with exception of
20 MOS 426, CS 101's stacks reside in MEM 112 with certain
portions of those stacks accelerated into FU 120 and E~
122 to enhance speed of operation.
Certain areas of MEM 112 storage space are set aside
to contain Macro-S~acks (MASs) 502, stack mechanisms
25 operating on the SINs level, as described above~ Other
areas of ME~ 112 are set aside to contain Secure Stack
~SS) 504, operating on the microcode level, as described
above and of which MIS 424 i a part.
9 ~ ~ 3
-46-
As described further below, both FU 120 and EU 122
contain register file arrays, referred to respectively as
GRF and ERF, in addition to registers associated with,
for example, ALUs. Referring to FU 120, shown therein is
FU 120's GRF 506. GR~ 506 is horizonkally divided into
three areas. A first area, reerred to as General
Registers ~GRs) 508 may in general be used in the same
manner as registers in a conventional machine. A second
area of G~F 506 is Micro-Stack (~IS~ 424, and is set
aside to contain a portion of a Process's SS 504. A
third portion of GRE 506 is set aside to con~ain ~OS
426. Also indicated in ~U 120 is a block referred to as
Microcode Control State (mCS) 510. mCS 510 represents
registers and other FU 120 hardware containing current
operating state of FU 120 on ~he microinstruction and
hardware level. mCS 510 may include, for example, the
current microinstruction controlling operation of FU 120.
Referring to EU 122, indicated therein is a
first block referred to as Execute Unit State (EUS) 512
20 and a second block referred to as SOP Stack 514. EUS 512
is similar to mCS 510 in F~ 120 and includes all
registers and other EU 122 hardware containing
information reflecting EU 122's current operating state.
SOP Stack 51B is a portion of EU 122's ER~ 516 which has
25 been set aside as a stack mechanism to contain a portion
of a process's SS 504 pPrtaining to EU 122 operations.
Considering first MASs 502, as stated a~ove MASs 502
operate generally upon the SINs level. ~ASs 502 are used
in general to store current state of a processls (defined
30 below) execu~ion of a user's program.
11~7~()63
--47--
Referring next to MIS 424, in a present embodiment of
CS 101 that portion of GRF 506 set aside to contain MIS
424 may have a capaci~y o~ eight stack frames. That is,
up to 8 mictoinstruction level interrupts or calls
5 pertaining to execution of a user's program may be
stacked within MIS 424. Information stored in MIS 424
stack frames is generally information from G~ 508 and MCS
51n. MIS 424 stack frames are ~ransferred between ~IS
424 and S5 504 such that at least one frame, and no more
10 than 8 frames, of SS 504 reside in ~F 506. This insures
that at lea t the top-most frames of a process's SS 504
are present in FU 120, thereby enhancing speed of
operation of F~ 120 by providing rapid access to those
top frames. SS S04, residing in M~M 112, may contain,
15 for all practical purposes, an unlimited number of frames
so that MIS 424 and SS 504 appear to a user to be
efe~tively an infinitely deep stac~.
~ OS 426 resides entirely in FU 120 and, in a present
embodiment of CS 101, may have a capacity of 8 stack
20 frames~ A feature o~ CS 101 operation is that CS 101
mechanisms for handling certain events or interrupts
should not rely in its operation upon those portions of
CS 101 whose operation has resulted in those faults or
interrupts. Among events handled by CS 101 monitor
25 microcode, for example, are MEM 112 page faults An MEM
112 page fault occur whenever FU 120 makes a reference
to da~a in M~M 112 and that data is not in MEM 112. Due
9~63
-~8-
to this and similar operationsr MOS 426 resides entirely
in FU 120 and thus does not rely upon information in MEM
112.
As described above, GRs 508, MIS 424, and ~OS 426
5 each reside in certain assigned portions of GRF S06.
This allows flexibility in modifying the capacity of GRs
508, MIS 424, and MOS 426 as indicated by experience, or
to modify an indiYidual CS 101 for particular purposes.
Referring finally to EU 122, EUS 512 is functionally
10 a part of a process's SS 504. Also as previously
described, EU 122 performs arithmetic operations in
response to SI~s and may be interrupted by FU 120 to aid
certain FU 120 operations. EUS 512 alIows stacking of
interrupts. For example, FU 120 may first interrupt an
15 arithmetic SOP to request EU 122 to aid in evaluation of
a Name Table Entry. Before that first interrupt is
completed, FU 120 may interrupt again, and so on.
SOP Stack 514, is a single frame stack for storing
current state o~ EU 122 when an interrup interrupts
20 execution of an arithmetic SOP. An interrupted SOP's
sta e is transferred into SOP Stack 514 and the interrupt
begin~ execution in EUS 512. Upon occurrence of a second
interrupt ~before the first interrupt is completed) EU's
first inte~rupt state is transferred from EUS 512 to a
25 stack frame in SS 504, and execution of the second
interrupt begins in EUS 512. If a third interrupt occurs
before completion of second interrup~, EU's second
interrupt state is transferred from EUS 512 to another
stack ~rame in SS 504 and execution of the third
30 interrupt is begun in EUS 512; and so on. ~US 512 and SS
504 thus provide an apparently infinitely deep microstack
~791~3
-49-
for EU 122. ~ssuming that the third interrupt is
completed, state of second interrupt is transferred from
SS 504 to EUS 512 and exe~ution of second lnterrupt
resumed. Upon completion of second interrupt, state of
first interrupt is transferred from SS 504 to EUS 512 and
completedO After completion of firs~ interrupt, state of
the original SOP is transferred from SOP Stack 514 to E~5
512 and execution of that SOP resumed.
C. ro~dure--~roces~e~:~n~-~irtys~ ~J~:Es~s
~ Eia . ~i ~
Referring to Fig. 6, a diagramic ~epresentation of
procedures, processes, and virtual processes is shown.
As described above, a user's program to be executPd is
compiled to result in a Procedure 602. A Procedure 602
includes a User's Procedure Object 604 containing the
SOPs of the user's program and a ~ame Table containing
Entries for operand Names of the user's program, and a
Static Data Area 606. A Procedure 602 may also include
other Procedure Objects 608, for example utili~y programs
20 available in common to many users. In effect, a
Procedure 602 contains the instru tions ~procedures) and
data of a user's program.
A Process 610 includes, as described above, a ~acro-
Stac~ (~AS) 502 storing state o execution of a user's
25 Procedure 602 at the SOP levelr and a Secure Stack (SS)
504 storing state of execution of a user's Procedure 602
at the microcode level. A Process 610 is associated with
a user's Procedure 602 through the ABPs described above
and which are stored in the MAS 502 of the Process 610.
30 Similarly, the MAS 502 and SS 504 o~ a Process 610 are
063
--50--
associated through non-architectural pointers, described
above. A Process 602 is effectively a body of
information linking the resources, hardware, microcode,
and software, of CS 101 to a user's Procedure 602. In
5 effect, a Process 610 makes the resources of CS 101
available to a user's Procedure 502 ~or executinq of that
Procedure 602. CS 101 is a multi-program machine capable
: of accommodating up to, for example, 128 Processes 610
concurrently. The number of Processes 610 which may be
10 executed concurrently is determined by the number of
Virtual Processors 612 of CS 101. There may be, for
example, up to 16 Virtual Proce sors 612.
As inaicated in Fig. 6, a Virtual Processor 612 is
comprised of a Virtual Processor State Block [VPSB) 614
15 associated with the SS 504 of a Process 612. A VPSB 614
is, in effec~, a body of infsrmation accessible to CS
lOl's operating system and through which CS lOl's
operating system is informed of, and provided with access
tol a Process 610 through that Process SlOIs SS 504. A
20 VPSB 614 is associated with a particular Process 610 by
writin~ information regarding that Process 610 into that
VPSB 614. CS lOl's operating system may, by gaining
access to a Process 610 through an associated PSB 614,
read in~ormation, such as A~PIs, ~rom that Process 610 to
25 ~U 120, ~hereby swapping that Process 610 onto FU 120 for
execution~ It is ~aid that a Virtual Processor 612
thereby executes a Process 610; a Virtual Processor 612
may be regarded therefor, as a processor having
"Virtualn, or potential, existence which becomes "real"
1~79~63
--51--
when its associated Process 610 is swapped into FU 120.
In CS 101, as indicat~d in FigO 6 r only one Virtual
Processor 612 may execute on FU 120 at a time and the
operating system selects which Virtual Processor 612 will
5 excecute on F~ 120 at any giYen time. In addition, CS
101's operating system selects which Processes 610 will
be associated with the available Virtual Pxocessors 612.
~ a~ing briefly described certain individual
structural and opera ing features of CS 101, the overall
10 opexation of CS 101 will be described in further detail
next below i~ terms of these individual features.
D.
1. 3
As indicated in Fig~ 7, CS 101 is a multiple level
system wherein operations in one level are generally
transparent to higher levels. User 701 does no~ see the
S-Language, addressing, and protec ion mechanisms defined
at Architectural Level 708. Instead, he sees ~ser
20 Interface 709, which is defined by Co~pilers 702, Binde~
703, and Extended ~high level) Operating System (EOS)
704. Compilers 702 translate high-level language code
into SINs and ~inder 703 trans}ates sym~olic Names in
programs into UID-o~fset addresses.
As FigO 7 shows, Architectural Level 708 is not
defined by FU 120 Interface 711. Instead, the
architectural resources level are created by S-Language
interpreted SINs when a program is executed; Name
-
i~t790~3
-52-
Interpreter 715 operates under control of S-Language
Interpreters 705 and translates Names into logical
de~criptors. In CS 101, both S-hanguage Interpreters 705
and ~ame Interpreter 715 are implemented as microcode
5 which executes on FU 120. S-Language Interpreters 705
may also use EU 122 to perform calculations. A Rernel
Operating System (ROS) provides CS 101 with ~ID-ofse~
addr~s~ingt objects, access checkingt processes, and
virtual processors., described fu~ther below. ROS has
l0 three kinds of components: ~9S ~icrocode 710 r ROS
Software 706, and ~OS Tables in ~EM 112. ROS 710
component~ are microcode routines which assist FU 120 in
performing certain required operations. Like other high-
level language routines, ROS 706 componen~s co~tain SINs
15 which are interpreted by S-Interpreter ~icrocode 705~
Many ROS ~igh-Level Language Routines 706 are exscuted by
~pecial ~OS processes; others may be executed by any
process. Both ROS ~igh-Level Language Routines 706 and
ROS Microcode 710 manipulate ~OS Tables in MEM 112.
2~ F~ 120 Inter~ace 711 is visible only to ROS and to S-
Interpreter Microcode 705. For the purposes of this
discus~ion, FU 120 may be seen as a processor which
contains the ~ollowing main elements:
- A Control Mechanism 72S which executes
microcode stored in Writable Control S ore
713 and manipulates FU 120 devices as
directed by this microcode.
9063
--53 ~
- A GRF 506 containing registers in which
data may be stored.
- A Processing Unit 715.
All microcode which executes on FU 120 uses these
5 devices; there is in addition a group of devaces for
performing special functions; these devices are used only
by microcode connec~ed with those functions. The
- microcode, the special-ized devices, and sometimes tables
in MEM 112 make up logical machines for performing
10 certain unctions. These machines will be described in
detail ~elow.
In the followingr each of ~he levels illustrated in
: Fig~ 7 will be discusæed in turn. First, the components
at User Inter~ace 709 will be examined to see how they
: 15 translate user programs and reque~s into forms usable by
CS 101. Then the components below the User Interface 709
will be examined to see how they create logical machines
for performi~g CS 101 operations~
. 2. ~9~ 3 :_lLL l~ 5==1l
Compiler9 702 translate iles containing the high-
lev~l language code written by User 701 in~o Procedure
Objects 608. Two components o~ a procedure O~ject 608
are code (SOPs) and ~ames, previously described. SOP~
represent operations, and the ~ames represent data. A
single SI~ thus specifies an operation to be performed on
the data represented by the Names.
9063
-54
3. i~l~ f~a~ t
In som~ cases, Compiler 702 cannot de~ine locations
as offsets from an ABP. ~or example9 if a procedure
calls a procedur~ contained in another procedure object,
5 the location to w~ich the call transfers control cannot
be defined as an o~fset from the PBP used by the calling
procedure. I~ these cases, the compiler uses symbolic
~ames to define the location~. Binder 703 is a utility
which translates symbolic Names into UID-offset
10 addresses. It does so in two ways: by combining
separate Procedure Objecks 608 into a single large
Procedure Object 60&, and then redefining symbolic ~ames
as offsets from that: Procedure Object 608's ABPs, or by
translating symbolic Names when the program is executed.
In the second case, Binder 703 requires assi~tance ~rom
EOS 704.
4. ~3 _15~L~3~
EOS 704 manages the resources that User 701 re~uires
to exPcute his programs. From User 701's point of view,
20 the most important o~ these resources are files and
processes. EOS 704 creates files by requ~sting ~OS to
create an obiect and then mapping the file onto the
object. When a User 701 per~orms an opera~ion on a file,
EOS 704 translates the file operation into an operation
25 on an object. ~OS creates them at EOS 704's request and
makes them available to EOS 704, which in turn makes them
available to User 701. EOS 704 causes a process to
execute by associating it a Virtual Processor 612. In
9~63
--5~--
logical terms, a Virtual Processor 612 is the means which
ROS provides EOS 704 for execu~ing Processes 610. As
many Processes 610 may apparently execute simultaneously
in CS 101 as there are Virtual Processors 612. The
illusion of simultaneous execution is created by
multiplexing JP 114 among the Virtual Processors; the
manner in which Processes 610 and Virtual Processors 610
are implemented will be explained in detail below.
5. ~Q~ d~r~ e~t~n~ e~
~ia~
S-Interpreter Microcode 710 and Name Interpreter
Microcode 715 require an environment provided by XOS
~Microcode 710 and ROS Software 706 to execu~e SINs. For
example, as previously explained~ ~ames and program
15 locations are defined in terms of ABPs whose values vary
during execution of the program. The KOS environment
provides values for the ABPs, and therefore makes it
possible to interpret ~ames and program locations as
locations in ME~ 112. Similarly, KOS help is required to
20 transform logical descrip~ors into references to MEM 112
and to perform protection checks.
The environment pro~ided by ~OS has ~he following
elements:
- A Process 610 which contains the state of
an execution of the program for a given
User 701.
- A Virtual Processor 612 which gives the
Process 610 access to JP 114.
- )
~1~79063
-56--
- An Object Management System which
translates UIVs into values that are usable
inside JP 114.
- A Protectîon System which checks whether a
Process 610 has the right to perform an
operation on an Object.
- A Virtual ~emory Management System which
moves those por~ions of Objects which a
Process 610 actually re~erences from the
outside world into MEM 112 and tran~lates
logical descriptors into physical
descriptors.
In the following, the logical properties of this
environment and the manner in whi¢h a program is executed
15 in it will be explained.
6. ~
Processes 610 and Virtual Processors 612 have already
b~en descri~ed in logical terms; Fig. 8 gives a high-
20 level view of their physical implementation.
Fig. 8 illustrates the relationship betw~en Processes610, Virtual Processors 612, and JP 114. In physical
terms, a Process 610 is an area of MEM 112 which contains
the current state of a user 15 execution o~ a program.
25 One example of such state i5 the current values of the
ABPs and a Program Counter ~PC). Given the current value
of the PBP and the PC, the next SOP in the program can be
executed; similarly, given the current values of SDP and
- \ ~
~7~ 0 ~ 3
-57-
FP, the program's Names can be correctly resolvedO Since
the ~roc~ss 610 contains the current state of a p~ogram's
execution, the program's physical execution can be
stopped and resumed at any point. It is thus possible to
5 control program execution by means o~ the Process 610.
As already mentioned, a Process 610's exPcution
proceeds only when ROS has bound it to a Virtual
Processor 612, that is, an area of MEM 112 containing the
state required to execute microinstructions on JP 114
10 hardware. The operation of binding is simply a trans~er
of Process 610 state from the Process 610's area of MEM
lI2 to a Virtual Processor 612's area of ME~ . Since
binding and unbinding may take place at any time, EOS 704
may multiplex Proceæses 610 among Virtual ~rocessors
15 612. In Fig. 8, there are more Processes 610 than there
are Virtual Processors 612. The physical execution of a
Process 610 on JP 114 takes place only while the Process
610's Virtual Processor 612 is bound to JP 114, i.e.,
when state is transferred from Virtual Processor 612's
20 area of MEM 112 to JP 114's registers. ~ust as EOS 704
multiplexes Virtual Processors 612 among Processes 610,
KOS multiplexes JP 114 among Virtual Processors 612. In
Fig. 8, only one Process 610 is being physically
executed. The means by which JP 114 is multiplexed among
25 Virtual Processors 612 will be described in further
detail below.
79063
--s 8
7. ~
In CS 101 systems, a Process 610 is made up qf six
Objects: one Process Objec~ 901 and ~ive Stack Objects
902 to 906. ~ig. 9 illustrates a Process 610. Process
5 Object 901 contains the information which EOS 704
requires to manage the Process 610. EOS 704 has no
direct acces~ to Process Object 901l but instead obtains
the information it needs by means of functions provided
to it by ROS 706, 710. Included in the information are
10 the UIDs o~ Stack Objects 902 throuyh 906. Stack Objects
902 to 906 contain the Process 610's state.
Stack Objects 902 through 905, are re~uired by CS
101's domain protection method and comprise Process 610's
~S 502O Briefly, a domain i~ determined in part by
15 operations performed when a system is operating in that
domain. For example, the system is in EOS 704 domain
when execu~ing EOS 704 operations and in ROS 706, 710
domain when executing ROS 706, 710 operations. A Process
610 must have one stack for each domain it enters. In
20 the present embodiment, the number of domains is fixed at
~our, but alte~nate embadiments may allow any number o~
domains, and correspondingly, any number of Stack
Objects. Stack Object 906 comprise~ Process 610's Secure
Stack 504 and is required to store state which may be
25 manipulated only by ROS 706, 710.
Each invacation made by a Proce~s 610 results in the
addition of ~rames to Secure Stack 504 and to Macro-Stack
502. The ~tate stored in the Secure Stack 504 fr~me
1~79~)63
--59--
includes the macrostate for the invocation, the state
re~uired to bind Process 610 to a Virtual Processor 612.
The frame added to Macro-Stack 502 is placed in one of
Stack Objects 902 through 905. Which Stack Objects 902
to 905 gets ~he frame is determined by the invoked
procedure's domain of execution.
Fig. 9 shows the condition of a Process 610's MAS 502
and Secure Stack 504 after the Process 610 has executed
four invocations. Secure Stack 504 has one frame for
10 each invocation; the frames of Process 610's MAS ~02 are
follnd in Stack Objects 902, 904, and 905. As revealed by
their locations, Frame 1 is for an invocation o~ a
routine with ROS 706, 710 domain of execu~ion, Frame 2
~or an invocation of a routine with the EOS 704 domain of
execution, and Frames 3 and 4 for invocations of routine~s
with the User domain of execution. Process 610 has not
yet invoked a routine with the Data Base ~anagement
System (DBMS) domain of execution. The frames in Stack
Objects 9~2 through 905 are linked togeth~r, and a frame
is added to or removed from Secure Stack 504 every ti~e a
frame is added to Stack Obiects 902 through 905O MAS 502
and Secure Stac~ 504 thereby ~unction as a single lsgical
stack even though logically contained in five separate
Objects.
8. ~
In the CS 101, calls and returns are executed by KOS
706, 710. When ~OS 706, 710 performs a call for a
process, it does the following:
1~79Q63
,
-60-
- It saves the calling invocation's
macrostate in the top fr~me of Secure S~ack
504 (Fig. 9).
- It locates the procedure whose ~ame is
co~tained in the call. ~he loca~ion o~ the
fir~t SIN in the procedure becomes ~he new
PBP.
- Using in~ormation contained in the called
procedure, ROS 706, 710 creates a new ~AS
502 frame in the proper Stack Object 902
through 905 and a new Secure Stack 504
~xame in Secure Stack 504. FP is updated
to point to the new MAS 502. If necessary,
SDP is also updated.~
~: 15 Once the values of the ABPs have been updated, the PC
: is:defined, Names can be resolved, and execution o~ the
invoked routine can commence. On a return from the
: : invocation to the invoking routi~e,~the s~ack frames are
~ deleted~and t~e AB~s are set to the values saved in the
20 invoking routine's macrostate. The invoking routine then
continues execution at the point following the
invocation.
A Process 610 may be illustrated in detail by put ing
the FORTRAN statement A ~ B into a FORTRAN rou~ine called
25 EXAM~L~ and invoking it from another FORTRAN rou~ine
named CALLER. To simpli~y the example, it is assumed
that ~ALLER and EXAMPLE both have the same domain of
- - )
~t790~3
-61-
execution. The parts of EXAMPLE which ara of interest
look like this:
S~BROUTI~E EXAMPLE tC)
I~TEGER X,C
INTEGER A,B
- -
A = B
RET~R~
E~D
The new elements are a formal argument, C, and a new
local variable, X. ~ formal argument is a data item
which receives its value from a data item used in the
invoking routine. ~he formal argument's value thus
. 15 varies from invocation to invocationO The portions of
INVOgER which are of interest look like this:
SUBRO~TINE INVORER
I~TEGER Z
O --
CALL EXAMPLE (Z)
r ~-
END
The CALL statement in INVORER specifias the ~ame of
the subroutine being invoked and the actual arguments for
25 the subroutine's formal arguments. During the
invocation, the subroutine's formal arguments take on the
values of the actual arguments. Thus, during the
invocation specified by this CALL statement, the focmal
- `
r~
1179063
--62--
argument C will have the value represented by thP
~ariable Z in INVOKER.
When INVORER is compiled, the compiler produces a
CALL SIN corresponding to the CALL sta~ement. The CALL
5 SI~ contains a Name representing a pointer to the
beginning o~ the called routine's location in a procedure
object and a list of Names representing the call's actual
arguments. Wh~n CAhL is executed, the Names are
interpreted to resolve the SI~'s ~ames as previously
10 described, and ~OS 710 microcode to perform MAS 502 and
Secure Stack 504 operations.
Fig. 10 illustrates the manner in which the ROS 710
`call microcode manipulates MAS 502 and Secure Stack 504.
~ig. 10 includes the following elements:
- Call ~icrocode 1001, contained in FU 120
Writable Control Store 1014.
- PC Device 1002, which contains part of
macrostate belonging to the invocation of
INVORER which is executing the CA~L
statement.
- Registers in FU Registers 1014. Registers
1004 contents include ~he remainder of
macros~ate and the descriptors
corresponding to Names for EXA~PLE's
location and the actual argument Z.
- Procedure Object 1006 contains the entries
for INVORER and EXAMPLE, their ~ame Tables,
and their code.
\
79063
. .
-63-
- Macro-Stack Object 1008 (~AS 502) and
Secure Stack Object 1010 (Secure Stack 504
contain the stac~ frames for the
invocations of I~ORER and EXAMPLE being
discussed here. EXA~PLE's frame is in the
same Macro-Stack object as INVORER'~ frame
because both routines are contained in the
same Procedure Object 1006, and therefore
. have the same domain o~ execution.
ROS Call ~icrocode 1001 first saves the macrostate of
INVORER's invocation on Secure Stack 504. As will be
discussed later, when the state is saved, KOS 706 Call
Microcode 1001 uses other ROS 706 microcode to translate
: the location in~ormation contained in the macrostate into
: 15 the kind of point~rs u ed in ME~ 112. ~hen Microcode
1001 uses the descriptor for the routine ~ame to locate
: the pointer to ~XAMPLE's entry in Procedure Object 1006.
From the entry, it locates pointers to EXAMPLE' 9 Name
Table and the beginning of ~X~PLEIs code. ~icrocode
20 1001 takes these pointer~, uses other ROS 706 microcode
to tr~nslate them into descriptors r and places the
descriptors in the locations in Regis~ers 1004 reserved
for the values of the PBP and ~TP. It then updates the
~alues contained in PC Device 100~ so that when the call
is ~inished, the next SI~ to be executed will be the
~irst SI~ in EXAMPLE.
063
64-
CALL Microcode 1001 next constructs the frames for
EXA~PLE on Secure Stack 504 and ~acro-Stack 502. This
di cussion concerns itself only with Frame 1102 on ~acro-
Stac~ 502. Fig. 11 illustrates EXAMPLE's Frame 1102.
The size of Frame 1102 i8 determined by EXAMPLE's local
variables (Xr A, and B) and formal arguments ~C). At the
bottom of Fram~ 1102 is ~eader 1104. Header 1104
contains information used by gOS 706~ 710 to manage the
stack. Next comes Pointer 1106 to the location which
contains the value represented by the argument C~ In ~he
invocation, the actual for C is the local variable Z in
INVOKE~. As is the case with all local variables, the
storage represented by 2 is contained in the stack frame
belonging to INVORER's invocation. When a name
interpreter resolved C's name, it placed the descriptor
: in a register. Call Microcode 1001 takes this
descriptor, converts it to a pointer, and stores the
pointer above ~eader 1104.
Since the FP ABP points to the location following the
last pointer to an actual a~gument, Call Microcode 1001
can now calcu~ate that location, convert it into a
descriptor, and place it in a FU Register 1004 reserved
for FP~ The next step is providing ~torage for ~XAMPLE's
local variables. EXAMPLE's Procedure O~jeot 1006
contains the size o~ the storage required or the local
variables, so Call ~icrocode 1001 obtains this
informa~ion from Procedure Object 1006 and adds that much
storage to Frame 1102. Using the new value of ~P and the
r~. ' j
1~79063
.
-65-
information contained in the Name Table Entries for the
local data, Name Interpreter 715 can now construct
descriptor~ for the local data. For example, A's entry
in Name Table specified that it was o~fset 32 ~its from
5 FE, and was 32 bits long. Thus, i~s storage ~alls
between the storage for X and B in Figure 1~.
g- _
' ~
As already explained, a logical descriptor contains
10 an AO~ field, an offset ~ield, and a length field. Fig.
12 illustrates a Physical Descriptor. Physical
Descriptor 1202 contains a Frame Number (FN) field, a
Displacement (D) field, and a Length (L) field.
Toge her, the Frame ~umber field and the Displacement
15 field specify the losation in ~E~ 112 containing the
data, and the Length field specifies the length of the
data.
As is clear from the above, the virtual memory
management system must translate the AO~-offset location
20 contained in a logical descriptor 1204 into a Frame
~umber-Displacement location. It does so by associating
logical pages with MEM 112 rames. (~.B: ~EM 112 ~rames
are not to be confu~ed with stack frames). Fig. 13,
illustrates how Macrostack 502 Object 1302 is divided
2$ into Logical Pages 1304 in secondary memory and how
Logical Page~ 1304 are moved onto Frames 1306 in MEM
112. A Frame 1306 is a fixed-size, contiguous area of
MEM 112. When the virtual memory management system
- )
1~79063
-66-
brings data into MEM 112, it does so in frame-sized
chunks called Logical Pages 1308. Thus, from the vir~ual
m~mory system's point of view, each object is di~ided
into Logiçal Pages 1308 and the address of data on a page
consists of the AON of the data's Object, the number of
page5 in the object, and its displacement on the page.
In Fig. 13, the location of the local variable B of
EXA~PL~ is shown as it is defined by the virtual memory
system. 8's location is a UID and an offset~ or, inside
10 JP 114, an AO~ and an offset. As defined by the virtual
memory system, B7s location is the AO~, the page num~er
1308, and a displacement within the page. When a process
:references the variable B, the virtual memory management
: system moves all of Logical Page 1308 into a MEM 112
15 Frame 1306. B's displacement remains he same, and the-
virtual memory system translates its Logical Page ~umber
1308 into thP number of Yrame 1~06 in MEM 112 which
contains t~e page.
The virtual memory management system must therefore
20 perform two kinds of translations: (1) AO~-offset
addresses into AON-page number-displacement addresses,
and t2) AON-page number in~o a rame number.
10. ~
Each time a reference is made to an Objectr ROS 706,
25 710 checks whether the reference is legal~ The following
discusson will first present the logical structure of
access control in CS 101, and then discuss the microcode
and devices which implement it.
9~63
--67--
CS 101 defines access in terms of subjects, modes of
access, and Object size. A process may reference a data
item located i~ an O~iect i~ three conditions hold-
1) I ~he process's subject has access to the
Objèot.
2) If the modes of access specified for the
su~ject include those required to perform
the inte~ded operation.
3) If the data item is completely contained in
the Object, i~e., if the data item's length
added to the da~a item's offset do not
exceed the number of bits in the Object.
The sub~ects which have access to an Ob~ect and the
kinds of acce~s they have to the Object are specified by
a data structure associa~ed with the Object called the
Access Control List ~ACL). An Object's size is one of
its attributes. Neither an Object's size nor its ACL is
contained in the Object. Both are contained in system
~able., and are accessible by means of the Object's UID.
Fig. 14 shows the logical struc~ure of access control
in CS 101. Subject 1408 has four componentso Principal
1404, ~rocess 14~5, Domain 1406, and ~ag 1407. Tag 1407
is no~ implemented in a present embodimen~ of CS 101, so
the following description will deal only with Principal
1404, Process 1405, and Domain 1406.
- Principal 1404 specifies a user for whlch
the process which is making the reference
was created;
li~79~63
--6 8--
- Process 1405 specifies the process which is
making the reference; and,
- Domain 1406 specifies the domain o~
execution of the procedure which the
process is exe~uting when it makes he
reference.
Each component of the Subject 1408 is represented by
a UID. If the UID is a null UID, that component of ~he
subject does not affect access checking. Non-null UIDs
10 are the UIDs of Objects that contain information about
the subjec~ componen~s. Principal Object 1404 contains
identification and accoun~ing information regarding
system users, Pro~ess Object 1405 con~ains process
management information~ and Domain Object 1406 contains
15 information about ~ r-domain error handlers. ~
There may be three modes of accessiny an Object 1410:
read, write, and execute. ~ead and write are self-
explanatory; execute is access which allows a subje t to
execute instructions contained in the Objec
Access ~ontrol Lists (ACLs) 14i2 are made up of
Entries 1414. Each entry two components: 5ubject
Template 1416 and Mode Specifier 1418. Subject Template
1416 specifies a group of subjects that may reference the
Object and ~ode Specifier 1418 specifies the kinds of
25 acc~ss these subjects may have to the Object. Logically
speaking, ACL 1412 is checked each time a process
references an Object 1410. The reference may succeed
only if the process's current Subject 1408 is one of
~79~63
-69-
those on Object 1410's ACL 1412 and if the modes in the
ACL Entry 1414 for the Subject 1408 allow the kind of
access the process wishes to make.
11. ~ _
~
As previously mentioned/ the execution of a program
: by a Process 610 cannot take place unless EOS 704 has
bound the Process 610 ~o a Virtual Processor 612.
~ Physical execution of the Process 610 takes place only
: 10 while ~he proces~'s Virtual Proce~sor 612 is bound to JP
114. The foilowing discussion deals with ~he data bases
belonging to a Virtual Processor 612 and the means by
which a Virtual Processor 612 is bound to and removed
from JP 114.
Fig. 15 illustrates ~he devices and ~ables which ROS
706, 710 uses to implement Virtual Prscessors 612. FU
: 120 WCS contains KOS Microcode 706 for binding Virtual
Processors 612 to JP 114 and removing them ~rom JP 114.
Timers 1502 and Interrupt Line 1504 are hardware devices
: 20 which produce signals that cause the invocation o ROS
~icrocode 706. Timers 1502 contains two timing devices.
}nterval Timer 1506, which may be set by ROS 706, 710 to
signal when a certain time is reached, and Egg Timer
1508, which guarantees that there is a maximum time
interval for which a Virtual Processor 612 can be bound
to JP 114 before it invokes ROS ~icrocode 706. Interrupt
Line 1504 becomes active when JP 114 receives a message
from IOS 116, for example when IOS 116 has finished
loadin.g.a logical page into MEM 112.
~7~(~63
~70--
FU 120 Registers 508 contain sta~e belonging to the
Vlrtual Processor 612 currently bound to JP 114. ~eref
khis Virtual Processor 612 is called Virtual Processor
A. In addition; Registers 508 contain registers reserved
for the execution of VP Swapping Microcode 1510. AL~
1942 (part of F~ 120) is used for the descriptor-to-
pointer and pointer-to-descriptor trans~ormations
required when one Virtual Processor 612 is,unbound ~rom
JP 114 and another bound to JP 114. MEM 112 contains
10 data bases for Virtual Processors 612 and data bases used
by ROS 706, 710 to manage Virtual Processors 612. KOS
706, 710 provides a fixed number of Virtual Processors
612 ~or CS 101. Each Virtual.Processor 612 is represented
by a Virtual Processor State Block ~VPSB) 614. Each VPSB
614 contains information used by gOS 706, 710 to manage
the Virtual Processor 612, and in addition contains
information associating the Virtual Processor 612 with a
process. FigO 15 shows two VPSBs 614, one belonging to
Virtual Processor 612A, and another belonging to Virtual
20 Processor 612B! which will replace Virtual Processor 612A
on JP 1140 The VPSBs 614 are contained in VPSB ~rray
1512. The index of a VPSB 614 in VPSB Array 1512 is
~irtual Processor Number 1514 belonging ~o the Virtual
Processor 612 represented by a VPSB 614. Virtual
25 Processor Lists 1516 are lists which KOS 706, 710 uses to
manage Virtual Processors 612. If a Virtual Processor
612 is able to execute, its Virtual Processor ~umber 1514
is on a list called the Runnable List; Virtual Processors
~ - ~ )
~63
-71-
612 which cannot run are on other lists, depending on the
rea~on why they cannot run. It is assumed that Virtual
Processor 612~'s Virtual Processor ~umber 1514 is ~he
first one on the Runnable LiSt.
When a process is bound to a Virtual Procesor 612,
the Virtual Processor ~umber lS14 is copied into ~he
process's Process Object 901 and the AO~s of the
pr~cess'~ Process Object 901 and stacks are copied into
the ~irtual ~rocessor 612's YPSB 614. (AONs are used
10 because a process's stacks are wired active as long as
the process is bound to a Virtual Processor 612).
Binding is carried out by ROS 706, 710 at the request of
EOS 704a In FigO 15, two Secure Stack Objects 906 are
. shown, one belonging to the process to which Virtual
15 Processor 612A is bound, and one belonging to that to
: which Virtual Processor 612B is bound.
~ aving described certain overall operating features
of CS 101, a present implementation of CS 101's structure
will be described further next beIow.
E. ~
Referring to Fig. 16, a pa~tial block diagram of IOS
116 is shown. ~ajor elements of IOS I16 include an
25 ECLIPSE9 Burst Multiplexer Channel ~BMC) 1614 and a NOVA~
Data Channel (NDC) 1616, an IO Controller ~IOC) 1618 and
a Data Mover (DM) 1610. IOS 116's data channel devices,
for example B~C 1614 and MDC 1616, comprise IOS 116's
i~terface to the outside world. Information and
30 addresses are received from external devices, such a~
79~63
--72--
disk drives, communications modes, or other computer
sy~tems, by IOS 116's data channel devices and are
trans~erred to D~ 1610 (described below) to be written
into ME~ 112. Similarly, information read from ME~ 112
is provided through DM 1610 to IOS 116's data channel
devices and thus to the above described external
devices. These external devices are a part of CS 101's
addressable memory space and may be addressed through UID
a~dressPs .
IOC 1618 is a general purpose CPU, for example an
E~:LIPSE computer available from Data General
Corporation. A primary function of IOC 1618 is control
of data transfer through ~OS 116~ In addition, IOC 1618
ge~erates individual Maps for each data channel device
15 for translating external device addresses in~o physical
addresses within ~E~ 112. As indicated in Fig. 16, each
data channel device contains an individual Address
Translation Map (MAP) 1632 and 1636. This allows IOS 116
to assign individual areas of MEM 112's physical address
20 space to each data channel device. This feature provides
protection against one data channel device writing into
or reading from information belonging to another data
channel device. In addition, IOC 1618 may generate
overlapping address translation ~ap~ or two or more data
25 channel devices to allow these data channel devices to
share a common area of MEM 112 physical address space.
-
~t~63
Data transfer between IOS 116's data channel devices
and MEM 112 is through DM 1610, which includes a Buffer
memory (BUF) 1641~ BUF 1641 allows ME~ 112 and IOS 116
to operate asychronously. DM 1610 also includes a Ring
5 G~ant Generator (RGG) 1644 which controls access of
various da~a channel devices to ME~ 112. RGG 1644 is
- designed to be flexible in apportioning access to MEM 112
among IOS 116l~ data channel devices as loads carried by
various data channel devices varies. In addition, RGG
10 1644 insures that no one, or group, of data channel
devices may monopolize access to MEM 112.
Referring to Fig. 17, a diagramic represe~tation o~
RGG 16441S operation is shown. As described further in a
~ollowing description, R~G 1644 may be regarded as a
15 commutator scanning a number of ports which are assigned
to various Ghannel de~ices. For example, ports A, C, E,
and G may be assigned to a BMC 1614, ports B and F to a
NDC 1616~ and ports D and ~ to ano~her data channel
device. RGG 1644 will scan each of ~hese ports in turn
20 and, if the data channel device associated with a
particular port is requesting ac~ess to ~EM 112, will
grant access to ME~ 112 to that da~a channel device. I~
no reque~t is present at a given port, RGG 1644 will
continue immediately to the next port. Each data channel
25 device assigned one or more ports is thereby insured
opportunity o access to MEM 112. Unused ports, for
example indicating da~a channel devices which are not
presently engaged in information transferr are
, .................................................................... .
9 ~6 3
-74-
effectively skipped over so that access to MEM 112 is
dynamically modified according to the information
transfer loads of the various data channel devicPsO RGG
1644's ports may be reassigned among IOS 116's various
data channel devices as required to suit the needs of a
5 particular CS 101 sys~em. If, for example, a particular
CS 101 utilizes NDC 1616 more than a B~C 1614, that CS
101's NDC 1616 may be assi~ned more ports while that CS
101's B~C 1614 is assigned fewer ports.
: 2. ~e~s~ D~ =te~s-=~el
Referring to Fig. 18, a partial block diagram of MEM
112 is shown. Ma~or elements of ~EM 112 are M~in Store
Bank (MSB) 1810,~a Bank Controller ~BC~ 1814, a ~emory
Cache (MC) 1816r a Field Interface Unit (FIU) 1820, and
emory Interface Controller (MIC) 1822. Interconnections
: 1~ of these elements with input and output buses of MEM 112
to IOS 116 and JP 114 are indicated.
~ EM 112 is an intelligent, prioritizing memory having
a single port to IOS 116, comprised of IO~ Bus 130, ~IO
Bus 129, and IOMC Bus 131, and dual ports to JP 114. A
20 first JP 114 port is comprised of ~OD Bus 140 and PD Bus
146, and a se~ond po~t is comprised ~f JPD Bus 142 and PD
Bus 146. In general, all data transf ers from and to MEM
112 by IOS 116 and JP 114 are of single, 32 bit words;
IO~ Bus 130, MIO Bus 129, MOD Bus 140, and JPD Bus 142
25 are each 32 bits wide. CS 101, however, is a variable
word length machine wherein the actual physical width of
data buses are not appa~en~ to a userO For example, a
~7~ ~ 3
-7S-
~ame in a user's program may refer to an operan~
containing 97 bits of data. To the user 7 that 97 bit
data item will appear to be read from MEM 112 to JP 114
in a single operation, In ac~uality, JP 114 will read
that operand from ME~ 112 in a series of read operations
referred to as a string transfer. In this example, the
string transfer will comprise three 32 bit read trans~ers
and one single bit read transfer~ The final single bit
transfer, containing a single data bi~, will be of a 32
10 bit word wherein one bit is data and 31 bits are fill~
Write operations to ME~ 112 may be performed in the same
manner If a single read or write request to ME~ 112
spec~fies a da a item o~ less than 32 bits o~ data, tha~
transfer will be accomplishPd in ~he same manner as the
15 final transfer described above. That is, a single 32 bit
word will be transferred wherein non-data bits are fill
bits.
Bulk data storage in ME~ 112 is provided in MSB 1810,
which is comprised of one or more Memory Array cards
(MAs) 1812. The data pa~h into and out of ~A 1812 i~
through BC 1~14, which performs all control and timing
functions for MAs 1812. BC ~814's functions include
addressing, transfer of data~ controlling whether a read
or write operation is performed, refresh, sniffing, and
25 error correction code operations. All read and write
operations from and to MAs 1812 through BC 1814 are in
blocks of four 32 bit wordsO
-
~7~ ~ 3
-76-
$he various MAs 1812 comprising MS8 1810 need not be
of the same data storage capacity. For example, certain
MAs 1812 may have a capacity of 256 kilobytes while other
~AS 1812 may have a capacity of 512 kilo~yte
Addressing of the MAs 1812 in MSB 1810 is automatically
adapted to various ~A 1812 configurations. ~s indicated
in Fig. 18, each MA 1812 contains an address circuit ~A)
which receives an input fram the next lower ~A 1812
: indicating the highest address in that next lower MA
1812. The A circuit on an MA 1812 also receives an input
from that MA 181~ indicating the ~otal address space of
that MA 18120 The A circuit of that MA 1812 adds the
highest address input from next lower ~A 1812 to its own
input representing its own capacity and yenerates an
output to the next MA 1812 indicating its own highest
address. All MAs 1812 of MSB 1810 are addressed in
parallel by BC 1814. Each MA 1812 compares such
addresses to its input from the next lower MA 1812,
representinq highest address of that next lower ~A 1812,
and its own output, representing its own highest address,
to determine whether a particular address provided by BC
1814 lies within the range of addresses contained within
tha~ particular MA 1812. The par~icular MA 1812 whose
address space includes that addre~s will then respond by
accepting the read or write re~uest from BC 1814.
~ ~79 ~ ~ 3
MC 1816 is the data path for transfer of da~a between
BC 1814 and IOS 116 and JP 114. MC 1816 contains a high
speed cache storing data from ~SB 1810 which is currently
being utilized by either IOS 116 or JP 114~ MSB 1810
5 thereby provides M~M 112 with a large s~orage capacity
while MC 1816 provides the appearanc~ of a high speed
memory. In addit~on to operating as a cache, MC 1816
includes a bypass write path which allows IOS 116 to
write blocks of four 32 bit words directly into MSB 1810
10 through BC lgl4. In addition~ MC 1816 includes a cache
write-back path which allows data to be transferred out
of MC 1816's cache and stored while further da~a is
transferred into MC 1816lS cache. Displaced data from MC
1816's cache may then be written back into ~SB 1810 at a
15 later, more convenient time. This write-back path
enhances speed of operation of ~C 1816 by-avoiding delays
incurred by transferring data from MC 1816 to MSB 1810
before new data may be written into ~C 1816.
MEM 112's FI~ 1820 allows manipulation of data
20 formats in writes to and reads from MEM 112 by both JP
114 and IOS 116. For example, FIU 1820 may convert
unpacked decimal data to packed decimal data, and vice
versa. In addition, FIU 1820 allows MEM 112 to operate
as a bit addressable memory. For example, as described
25 all data trans~ers to and from MEM 112 are of 32 bit
words. If a data transfer o~ less than 32 bits is
re~uired, the 32 bit word containing those data bits may
~J
. .
- \ -
-
~79~63
--7 8--
be read from MC 1816 to FIU 1820 and therein manipulated
to extract the required data bits. ~IU 1820 then
generates a 32 bit word containing those required data
bits, plus fill ~it~, and provides that new 32 bit word
5 to JP 114 or IOS 116. When writing into ~EM 112 from IOS
116 through FIU 1820, data is ~ransferred onto IO~ Bus
130, read into FIU 1820, operated upon, transferred onto
MOD Bus 140, and transferred ~rom MOD Bus 140 to MC
1816. In read operations from MEM 112 to IOS 116, data
is transferred from MC 1816 to MOD Bus 140, written into
FIU 1820 and operated upon, and transferred onto MIO Bus
129 to IOS 116. In a data read from MEM 112 to JP 114,
data is transferred from ~C 1816 onto MOD Bus 140,
transferred into FIU 1820 and operated upon, and
15 transferred again onto MOD Bus 140 to JP 114. In write
operations from JP 114 ~o ~EM 112, data on JP~ Bus 142 is
transferred into ~IU 1820 and operated upon, and is then
transferred onto MOD Bus 140 to MC 1816. MOD Bus 140 is
thereby utili~ed as an ~EM 112 internal bus for FIU 1820
20 operations.
Finally, MIC 1822 provides primary control of BC
1814, MC 1816, and FIU 1820. ~IC 1822 receives control
inputs f~om and provides control outputs to PD Bus 146
and IOMC Bus 131. MIC 1822 contains primary microcode
25 control for MEM 112, but BC 1814, MC 1816, and F~U 1820
each include internal microcode control. Independent,
internal microcode controls allow BC 1814, MC 1816, and
FIU 1820 to operate independently of MIC 1822 ater their
1~7g~3
-79-
operations have been initiated by MIC 1822~ This allows
BC 1814 and MSB 1810, MC 1816, and FIU 1820 to operate
independently and asynchronously. Efficienc~ and speed
of operation of MEM 112 are thereby enhanced by allowing
pipelining of ~EM 112 operations.
. .
3. ~
A primary function of FU 120 is to execute SlNs. In
doing so, FU 120 fetches instructions and data ~SOPs and
Names) from M~M 112, returns results of operations to MEM
112, directs operation of EU 122, execu~es instructions
of user's programs, and performs the various functions of
CS 101's operating systems. As part of these functions,
F~ 120 generates and manipulates logical addresses and
descriptors and is capable of opera~ing as a general
purpose CPU.
Referring to Fig. 19, a major element of FU 120 is
the Descrip~or Processor ~DESP) 1910~ DESP 1910 includes
Gen~ral ~egister File (GRF) 506. GRF 506 is a large
register array divided ver~ically into three parts which
are addressed in parallel. A first part~ AONGRF 1932,
stores AON fields of logical addresses and descriptors.
A se~ond part, O~FGRF 1934, stores offset ~ields of
logical addresses and descriptors and is utilized as a 32
bit wide general register array. A third portion GRF
506, LENG~F 1936, is a 32 bit wide register array for
storing length fields of logical descriptor and as a
general register for ~toring data. Primary data path
9063
--8~--
from MEM 112 to ~U 120 is through MOD Bus 140, which
provides inputs to OFFGRF 1934. As indicated in ~ig. 19 7
data may be transferred from OFFGRF 1934 to inputs of
AONGRE 193~ and LENGR~ 1936 through various
5 interconnection~. Similarly, outputs from LENGRE 1936
and AONGRE 1932 may be tra~sferred to inputs of AO~GRF
1~32, OFFGRF 1.934, and LENG~F 1936.
Output of OFFG~ 1934 is connected to inputs of DESP
1910's Arithmetic and Logic Unit (ALU) 1942. ALU 1942 is
10 a general purpose 32 bit ALU which may be used in
generating and manipulating logical addresses and
descriptors, as distinct from general purpose arithmetic
and logic operands performed by MUX 1940. Output of ALU
1942 is connected to JPD Bus 142 to allow results of
15 arithmetic and logic operations to be transferred to MEM
112 or EU 122.
Also connected from output of OFFGRF 1934 is
Descriptor ~ultiplexer (MUX) lg40O An output o~ MUX 1940
: is provided to an input of ALU 1942. ~X 1940 is a 32
20 bit AL~, including an accumulator, for data manipulation
operations. MUX 1940, together with ALU 1942, allows
DESP 1910 to per~orm 32 bit arithmetic and logic
operations. MUX 1940 and ALU 1942 may allow arithmetic
and logic operations upon operands of greater than 32
25 bits by perorming successive operations upon successive
32 bit words of larger operands.
Logical descriptors or addresses genera ed or
provided by DESP 1910, are provided to Logical Descriptor
~7~ ~ 3
-81-
~LD) Bus 1902. LD Bus 1902 in turn is connected to an
input of Address Translation Unit (ATU) lg28. ATV 1928
i9 a cache mechanism for converting logical descriptors
~o MEM 112 physical dPscriptors.
LD Bus 1902 is also connected to write input o~ ~ame
CachP (NC) 1926. ~C 1926 is a cache mechanism or
s~oring logical descriptors corresponding to operand
~ames currently being used in user's programs. ~s
previously described, Name Table Entries corresponding to
10 operands currently being used in user's programs are
stored in MEM 112. Certain Name ~able Entries for
operands of a user's program currently being executed are
transferred from those Name Tables in ~EM 112 o FU 120
and are therein evaluated to generate corresponding
logical descriptors. These logical descriptors are then
stored in NC 1926. As will be described further below,
the instruction stream of a user's program is provided to
FU 120's Instruction Buffer (IB) 1962 through MOD Bus
140. FU 120's Parser ~P) 1964 separates out, or parses,
20 Names from IB 1962 and provides those ~ames as address
inputs to NC 1924. NC 1924 in turn provides logical
descriptor outputs to LD Bus 1902, and thus to input of
ATU 1928. NC 1926 input from LD Bus 1902 allows logical
descriptors xesulting from evaluation of Name Table
25 Entries to be written into NC 1926. FU 120's Protections
Cache (PC) 1934 is a cache mechanism having an input
connscted from LD Bus 1902 and providing information, as
described further below, regarding protection aspects o
1~79(~;3
-82-
references to data in MEM 112 by userls programs. ~C
1926, ATU 1928, and PC 1934 are thereby acceleration
mechanisms of, respectively, CS lOl's Namespace
addressing, logiGal to physical address structure, and
protection mechanism.
Referring again to DESP lglO, DESP 1910 includes BIAS
1952, conneGted om output o$ LE~GRF 1936. As
previously de~cribedr operands containing more than 32
data bits are ~ransferred beteen ME~ 112 and JP 114 by
means of string transfers. In order to perform string
transfers, it is necessary for F~ 120 to generate a
corresponding succession cf logical descriptors wherein
length fields of those logical descriptors is no greater
than 5 bits, that is, specify lengths of no greater than
32 data ~its.
A logical descriptor describing a data item to be
transferred by means of a string tranRfer will be stored
in GRF 506. AON field of the logical des~riptor will
reside in AOMGRE 1932, 0 field in OFFGRF 1934, and L
field in LENGRF 1936. At each successive trans~er of a
32 bit word in the string transfer, O field of that
original logical descriptor will be incremented by the
number o~ data bits transferred while L ~ield will be
accordingly decremented. The logical descriptor residing
in GRP 506 will thereby describe, upon sach successsive
transfer of the string transfer, that portion of the data
item yet to be transferred. O field in OFFGRF 1934 will
indicate increasingly larger offsets into that data i~em,
while L field will indicate successively shorter
~1~79~3
--83--
lengths. AON and O ields of the logical descriptor in
GRF 506 may be utilized directly as AO~ and O fields of
the suc~essive logical descriptors of the s~ring
~ransfer. L field of the logical descriptor residing in
LE~GRF 1936 t however, may not be so used as L f ields of
the successive string transfer logical descriptors as
this L field indicates remaining length of data item yet
to be trans~erredO Instead, BIAS l9S2 generates the 5
bit L fields of successive string transfer logical
10 descrip ors while correspondingly decrementing L field of
the logical descriptor in L~NGRF 1936. During each
transfer, BIAS lg52 generates L fiPld of the D$~ string
transfer logical descriptor while concurrently providing
L field of the ~u~ent string transfer logical
descriptor. By doing SOr B~A~ 1952 thereby increases
speed of execution of string transfers by performing
pipelined L field operations. BIAS 1952 thereby allows
CS 101 to appear to the user to be a variable word length
machine by automatically performing string transfers.
20 This mechanism is used for transfer of any data item
greater than 32 bits, for example double precision
floating point numbers.
Finally, FU 120 includes microcode circuitry for
controlling all FU 120 operations described above. In
25 particular, FU 120 includes a microinstruction sequenoe
control store (mC) 1920 storing sequences of
microins~ructions for controlling step by step ~xecution
of all F~ 120 operations. In general, these F~ 120
: ~ /
9~63
-84-
operations fall into two classes~ A first class includes
thase microinstruction sequences directly concerned with
executing the SOPs of user's programs. The second class
includes microinstruc ion sequPnces concerned with CS
101's operating systems, including and certain automatic,
internal Y~ 120 functions such as evaluation of ~ame
Table Entries.
As pre~iously described, CS 101 is a multiple S
Language machine. For example, m~ 1920 may contain
microinstruction sequences for executing user's SOPs in
at least four different Dialects. mC 1920 is comprised
o~ a writeable control store and sets of microinstruction
sequences for various Dialects may be transferred into
and out of mG 1920 as required for execu~ion of various
user's programsO B~ storing sets o~ microinstruction
sequences for more than one Dialect in mC 1920, i is
possible for user's programs to be written in a mixture
of user languages. For examplP, a particular user's
program may be written primarily in FORTRAN but may call
certain COBOL routines~ These COBQL routines will be
correspondingly translated into COBO~ dialect SOPs and
execu.ed by COBOL microi~struction sequences stored in mC
1920.
The instruction stream provided to FU 120 from ME~
112 has been previously described with reference to Fig.
3. SOPs and Names of this instruction stream are
transferred from MOD Bus 140 into IB 1962 as they are
provided from MEM 112. IB 1962 includes two 32 bit (one
~179~3
--85--
word) registers~ IB 1962 also includes prefetch
cirCuitry for reading for SOPs and Names of the
instruction stream from MEM 112 in such a manner that IB
1962 sh~ll always contain at least one SOPs or ~ame. F~
120 includes (P~ 1964 which reads and separates, or
parses, SOPs and ~ames from IB lg62. As previously
described~ P 1964 provides those ~ames to NC 1926, which
accordin~ly provides logical descriptors to ATU 1928 so
as to read the corresponding operands from MEM 112.
SOPs parsed by P 1964 are provided as inputs to Fetch
Unit Disp~tch Table (FUDT) 1904 and Execute Unit Dispatch
Table ~EUDT) 1966. Referring first to FUDT 1904, FUDT
1904 is effectively a table for translatin~ SOPs to
~tarting addresses in mC 1912 of corresponding
15 microinstruction sequences. This i~termediate
translation of SOPs to mC 1912 addresses allows e~icient
packing of microinstruction sequences within mC 1912.
That is, certain microinstruction sequences may be common
to two or more S-Language Dialects. Such
20 microinstruction ~eguences may ~herefore ~e written into
mC 1912 once and may be referred to by different SOPs of
diferent S-Language Dialec~s.
EUD~ 1966 performs a similar function with respect to
EU 122. ~s will be described below, EU 122 contains a
25 mC, ~imilar to mC 1912, which is addressed through E~DT
1966 ~y SoPs specifyiny EU 122 operations. In addition,
F~ 120 may provide such addresses mC 1912 to initiate E~
122 operations as required to assist certain FU 120
11~79063
-86 -
.
operations. Examples of such operations which may be
re~uested by FU 120 include calculations required in
evalua~ing Name Table Entries to provide logical
de~criptors to be loaded into NC 1~26.
Associated with both FUDT 1904 and E~DT 1966 are
Dialect (D) registers 1905 and 1967. D regi~ters 1905
and 1967 store infoxmation indicating the particular S-
Language Dialect currently being utilized in execution of
a user's program. Outputs of D registers 1905 and 1967
lO are utilized as part of the address inpu s to mC 1912 and
EU 122's mC.
4 0 ~g~ ( ~ ia . ~L
As previously described, EU 122 is an arithmetic and
logic unit provided to relieve F~ 120 of certain
15 arithmetic operations. EU 122 is capable of performing
additionr subtraction, multiplication, and division
operations on integer, packed and unpacked decimal, and
single and double precision floating operands~ EU 122 is
an independently operating microcode controlled machine
20 including ~icrocode Control (mC) 2010 which, as described
above, i addressed by EUDT 1966 to initiate EU 122
operationsO mC 2010 also includes logic for handling
mutual interrupts between FU 120 and EU 122. That is,
120 may interrupt current EU 122 operations to call upon
25 ~U 122 to assist an FU 120 operation. For example, FU 120
may interrupt an arithmetic operation currently bein~
executed by EU 122 to call upon E~ 122 to assist in
generating a logical descriptor from a Name Table Entry~
1~79~63
-87
Similarly, EU 122 may interrupt current FU 120 operations
when EU 122 requires F~ 120 assistance in executing a
current arithmetic operationO For example, EU 122 may
interrupt a current F~ 120 oper tion if EU 122 receives
5 an instruction and operands requiring E~ 122 to perform a
divide by zero.
Referring to Fig. 20, a partial block diagram of E~
122 is shown. E~ 122 includes two arithmetic and logic
units. A irst arithmetic and logic uni~ (~ULT) 2014 is
10 utilized to perform addition, su~traction,
multiplication, and division operations upon integer and
decimal operands r and upon mantissa fields of single and
double precision floating point operands. Second ~LU
(EXP) 2016 is utilized to perform operations upon single
and double precision floating point operand exponent
fields in parallel with operations performed upon
floating point mantissa fields by ~ULT 2014. Both MULT
2014 and EXP 2016 include an arithmetic and logic unit,
respectively M~L~ 2074 and EXPALU 2084. ~UL~ 2014 and
EX~ 2016 also include register filesr respecti~ely MRF
2050 and ERF 2080, which operate and are addressed in
parallel in a manner similar to AONGR~ 1932, OFFGRF 1984
and LE~GRF 1936.
Operands for EU 122 to operate upon are provided from
ME~ 112 through ~OD Bus 140 and are transferred into
Operand Buffer (OPB) 2022. In addition to serving as an
input-buf~er, OPB 2022 performs certain data format
~^~
~79 ~ 3
-88-
manipulation operations to transform input operands into
formats most efficiently operated with by EU 122. In
particular, EU 122 and M~LT 2014 may be designed to
operate efficiently with packed decimal operands. OPB
5 2022 may transform unpacked decimal operands into packed
decimal operands. Unpacked decimal operands are in the
: form o~ ASCII characters wherein four bits of each
characters are binary codes specifying a decimal value
between zero and nine. Other bits of each character are
10 referred to as zone fields and in general contain
information identifying particular A~CII characters. For
example, zone field bits may specify whether a particular
ASCII character is a number, a letter, or punctuation.
Packed decimal operands are comprised of a series of ~our
15 bit fields wherein each field contains a binary number
specifying a decimal value of between zero and nine. OPB
2022 converts unpacked decimal to packed decimal operands
by extracting zone field bits and packing the four
numeric value bits of each character into the our bit
20 fields of a packed decimal number.
E~ 122 is also capable o~ transforming the results of
arithmetic operand~, for example in packed decimal
format, into unpacked decimal format for transfer back to
MEM 112 or FU 120. In this case, a packed decimal result
25 appearing at output of MALU 2074 is written into ~RF 2050
-through a multiplexer, not shown in ~ig~ 20, which
transforms the four bit numeric code ~ields of the packed
9(~63
--89--
decimal results into corresponding bits of unpacked
decimal operand characters, and forces blanks into the
zone field bits of those unpacked decimal characters.
The results of t~is operation are then read from MRF 2050
5 to MAL~ 2074 and zone field bits for those unpacked
deci~al characters are read from Constant Store (CST)
2060 to MALU 2074. These inputs from ~RP 2050 and CST
2060 are added by MAL~ 2074 to generate final result
ou~puts in unpacked decimal format. These final re~ults
10 may then be transferred onto JPD Bus 142 through Output
Multiplexer (OM) 2024.
Considering first floating point operations, in
addition or sub~raction of floating p~int operands it is
necessary to equalize the values of the floating point
15 operand exponent fields. This is referred to as
prealignment. In floating point operations, exponent
fields of the two operands are transferred into EXPALU
2034 and compared to determine the difference between
exponent fieldsO An output representing difference
20 between exponent fields is provided from EXPALU 2034 to
an input of floating point control (FPC) 2002. FPC 2002
in turn provides con~rol outputs to MAL~ 2074, whi~h has
received the mantissa fields of the two operandsO MALU
2074, operating under direction of FPC 2002, accordingly
25 right or left shifts one operand's mantissa field to
effectively align that operand's exponent fi~ld with ~he
other operand's exponent field. Addi~ion or subtraction
of the operandls mantissa fields may then proceed.
il~79C~63
--g3--
EXPALU 2034 also performs addition or subtraction of
floating point operand exponent fields in multiplication
or division operations, while MALU 2074 performs
multiplication and division of the operand mantissa
5 fields. ~ultiplication and division of floating point
operand mantissa fields by M~LU 2074 is performed by
successive shifting of one operand, corresponding
generation of partial products of the other operand, and
successive addition and subtraction of those par~ial
10 products.
Finally, EU 122 performs normalization of the results
of floating point operand opera~ions by left shifting of
a finaI result's mantissa field to eliminate ze.ros in the
most significant characters of the final result mantissa
15 field, and corresponding shifting of the final result
exponent fields. Normalization of floating point
operation results is controlled by FPC 2002. FPC 2002
examines an unnormalized floating point result output of
MAL~ 2074 to detect which, if any, of the most
20 significant characters of tha~ results contain zeros.
~PC 2002 then accordingly provides control outputs to
EXPALU 2034 and MALU 2074 to correspondingly shift the
exponent and mantissa ~ields of those results so as to
eliminate leading character zeros from the mantlssa
25 field. Normalized mantissa and exponent fields of
floating poi~t results may then be transferred from MALU
2074 and EXPAL~ 2034 to JPD Bus 142 through OM 2.024.
79~63
--91--
As described above, EU 122 also performs addition,
subtraction, multiplication, and division operations on
operands~ In this respect~ EU 122 uses a leading zero
detector in FPC 2002 in efficiently performing
5 multiplication and division operations. FPC 2002's
leading zero detector examines the characters or bitq of
two operands to be multiplied or divided, starting from
the highest, to determine which, if any~ con~ain zeros so
as not to re~uire a multiplication or division
10 operation. FPC 2002 accordingly left shifts the operands
to affectively eliminate those characters or bits, thus
reducing the number of operations to multiply or divide
the operands and accordingly reducing the time required
to operate upon the operands.
~inally, EU 122 utilizes a unique method, with
associated hardware, for performing arithmetic opera~ions
on decimal operands by utilizing circuitry which is
otherwise conventionally used only to perform operations
upon floating point operands. As described above, MULT
20 2074 is designed to operate with packed decimal operands,
that is operands in the form of consecutive blocks of
four bits wherein each block of our bits contains a
binary code representiny numeric values o~ between zero
a~d nine. ~loating point operands are similarly in the
25 form of consecutive blocks of four bits. Each block of
four bits in a floating point operand, however, contains
a binary number representing a hexadecimal value o~
, .?
11~79063
--92 ~-
between æero and fifteen~ As an initial step in
operating with packed decimal operands, those operands
are loaded, one at a time, into ~ALU 2074 and, with each
such operand, a number comprised of all hexadecimal sixes
5 is loaded into MA$n 207~ from CST 2060. This CS~ 2060
number is added to each packed decimal operand to
effectively convert ~hose packed decimal operands into
hexadecimal operands wherein the four bit blocks contain
numeric values in the range of six to fifteen, rather
10 than in the original range of zero to nine. M~T 2014
then performs arithmetic operation upon those transformed
operands, and in doing so detects and saves information
regarding which four bit characters of those operands
have resulted in generation of carries during the
15 arithmetic operations. In a final step, the intermediate
result resulting from completion of those arithme~ic
operations upon those transformed operands are
reconverted to packed decimal format by subtraction of
hexadecimal sixes from those characters for which carries
20 have been generated~ ~ffectively, EU 122 converts packed
decimal operands into ~Excess Six~ operands, performs
arithmetic operations upon those "Excess Six" operands,
and reconverts "Excess Six~ results of those opera~ions
back into pa~ked d~cimal ~orma~.
Finally, as previously descibed F~ 120 controls
transfer of arithmetic results from E~ 122 to MEM 112.
In doing so, FU 120 generates a ~ogical descriptor
describing the size of MEM 11~ address space, or
~791~63
--93--
"containern, that result is to be transferred nto~ In
certain arithmetic operations, for example inte~er
operations, an arithmetic result may be larger than
anticipated and may contain more bits than the MEM 112
"containern. Container Sîze Check Circuit (CSC) 2052
compares actual size of arithmetic results and L ~ields
of MEM 112 "container" logical descriptors. CSC 2052
generates an ou~put indicating whether an MEM 112
"container" is smaller ~han an arithmetic result.
~aving briefly described certain features of CS 101
structure and operation in the above overview, these and
other features of CS 101 will be described in further
detail next ~elow in a more detailed introduction o CS
101 structure and operation. Then, in further
15 descriptions, these and other features of CS 101
structure and operation will be described in depth.
1. I~el~ i~
A.
a. G~ner~ ructu~
Re~arring to Fig. 101, a partial block diagram of
Computer System ~C5) 10110 is shown. ~ajor elements of
CS 10110 are Dual Port Memory ~EM) 10112, Job Processor
(JP) 10114, Input/Ou~put System (IOS) 10116, and
Diagnostic Processor (DP) 10118. JP 10114 includes Fe~ch
25 Unit (FU) 10120 and Execute Unit (EU) 10122.
i~79~63
-94-
Referring irst to IOS 10116, IOS 10116 is
interc~nnected with Ex~ernal Devices (ED) I0124 through
Input/Output (I/O) Bus 10126. ED 10124 may include, ~or
example, other computer systems, keyboard/display units,
5 and disc drive memories. IOS 10116 is interconnected
with Memory Input/Output (MIO) Port 10128 of ~EM 10112
through Input/Output to Memory (IOM) Bus 10130 and Memory
to Input/Output (MIO) Bus 101~9, and with FU 10120
through I/O ~ob Pr w essor (IOJP) Bus 10132.
~P 10118 is interconnected with, for example,
external keyboard/CRT Display Unit (DU) 10134 through
Diagnostic P~ocessor Input/Output (DPIO) Bus 10136. DP
10118 is interconnected with IOS -10116, MEM 10112, FU
10120, and EU 10122 through Diagnostic Processor (DP) Bus
10138.
Memory to Job Processor (MJP) Port 10140 of Memory
10112 is interconnec~ed with F~ 10120 and EU 10122
through Job Processor Data (JPD) Bus 10142. An output of
MJP 10140 is connected to inputs o~ FU 10120 and EU 10122
20 through Memory Output Data (MOD~ ~us 10144. An output o~
FU 10120 is connected to an input of ~JP 10140 through
Physical Descriptor (PD) ~us 10146. FU 10120 and EU
10122 are interconnected through Fetch/Execute (F/E) Bus
10148.
b. L~sJ~ _ 5c c ~!~
As will be discussed further below, IOS 10116 and ME~
10112 operate independently under general control of JP
10114 in executing multiple user's programs. In this
1~79(~63
--95--
regard, MEM 10112 is an intelligent, prioritizing memory
having separate and independent ports MIO 10128 and MJP
10140 to IOS 10116 and JP 10114 respectivelyO ~EM 10112
is the primary path for information transfer between
5 ~xternal Devioes 10124 ~through IOS 10116) and JP 10114.
MEM 10112 thus operates both as a buffer ~or receiving
and s~oring various individual user's programs (e.g.,
data, instructions, and results of program execution) and
as a main memory for JP 10114.
A primary function of IOS 10116 is as an input/output
buffer between CS 10110 and ED 10124. Data and
instructions are transferred from ED 10124 to ~OS 10116
through I/O Bus 10126 in a manner and format compatible
w:ith ED 10124. IOS 10116 receives and stores this
15 in~ormation, and manipulates the information into formats
suitable for transfer into MEM 10112. IOS 10116 then
indicates to ~EM 10112 that new information is available
for transer into MEM 10112. Upon acknowledgement by ~E~
10112, this information is trans~erred into ME~ 10112
20 ~hrough IOM Bus 10130 and NIO Port 10128. MEM 10112
stores the information in selected portions of MEM 10112
phy~ical address space. At this time, IOS 10116 notiies
JP 10114 that new in~ormation is present in ~EM 10112 by
providing a ~semaphore~ signal to ~U 10120 through IOJP
25 BUS 10132. As will be described further below, CS 10110
manipulates the data and instructions stored in MEM 10112
into certain information structures used in executing
user's programs. Among these structures are certain
9063
--96--
structures, discussed further below, which are used by CS
10110 in organiæing and controlling flow and execution of
user programs.
Fn 10120 and EU 10122 are independently operating
microcode controlled "machines" together comp~ising the
5 CS 10110 micromachine for executing user's pro~rams
stored in ME~ 10112. Among the principal functions of FU
10120 are: (1) fetching and interpreting instructions
and data from MEN 10112 for use by ~U 10120 and EU
10122; (2) organizing and controlling flow of user
10 programs; (3) initiating EU 10122 operations; (4)
per~orming arithmetic and logic operations on data; (5)
controlling transfer of data from FU 10120 and EU 10122
to ME~ 10112; and, (6) maintaining certain ~stack" and
"register" mechanisms, described below. FU 10120 "cache"
15 mechanisms, also described below, are provided to enhance
the speed of operation of JP 10114. These cache
mechanisms are acceleration circuitry including, in part,
high ~peed memories ~or storing copies of selected
information stored in ~EM 10112. The information stored
in this acceleration circuitry is thererore more rapidly
available to JP 10114. EU 10122 is an arithmetic unit
capable of executing integer, decimal, or floating point
arithmetic operations. The primary function of EU 10122
is to relieve FU 10120 from certain extensive arithmetic
25 operations, thus enhancing the efficiency of CS 10110.
9 ~6 3
-97-
In general, operations in JP 10114 are executed on a
memory to memory basis; data is read from MEM 10112,
operated upon, and the results returned to MEM 10112. In
this regard, certain stack and cache mechanisms in JP
10114 (described below) operate as extensions of MEM
10112 address space.
In operation, FU 10120 reads data and instructions
from ME~ 10112 by providing physical addresses to ~EM
10112 by way of PA Bus 10146 and MJP Port 10140. The
instructions and data are transferred to F~ 10120 and EU
10122 by way of MJP Port 10140 and MOD Bus 10144.
Instructions are interpreted by F~ 10120 microcode
circuitry, not shown in Fig. 101 but described below, and
when necessary, microcode instructions are provided to EU
15 10122 from FU 10120's microcode control by way of FtE Bus
10148, o.r by way of JPD Bus 10142.
As stated above; FU 10120 and EU 10122 operate
asynchronously with respect to each other's functions~ A
microinstruction from FU 10120 microcode circuitry to E~
20 10122 may initiate a selected operation of EU 10122. E~
10122 may then proceed to independently execute the
selected operation. FU 10120 may proceed to concurrently
execute other operations while EU 10122 is completing the
selected arithmetic operation. At completion of the
25 selected arithmetic operation, EU 10122 signals FU 10120
that the operation results are available by way of a
"handshake~ ~ignal through F/E Bus 10148. FU 10120 may
l~t79063
-98-
then receive the arithmetic operation results for further
processing or, as discussed momentarily, may directly
transfer the arithmetic operation results to hEM 10112.
~s described further below, an instruction buffer
. 5 referred to as a ~queue" between FU 10120 and EU 10122
allows FU 10120 to assign a sequence of arithmetic
operations to be performed by E~ 10122.
Information, such as results of exe~uting an
instruction, is written into MEM 10112 from FU 10120 or
10 EU 10122 by way of JPD Bus 10142. FU 10120 provides a
"physical write address" signal to ~EM 10112 by way of PA
Bus 10146 and MJP Port 10140. Concurrently, the
information to be written into MEM 10112 is placed on JPD
Bus 10142 and is subsequen~ly written into ~EM 10112 at
15 ~he locations selected by the physical wri~e address.
FU 10120 places a semaphore signal on IOJP Bus 10132
to signal to IOS 10116 that information, such as the
results of executing a user's program, is available to be
read out of CS 10110. IOS 10116 may then transfer the
20 information ~rom MEM 10112 to IOS 10116 by way of ~IO
Port 10128 and IOM Bus 10130~ Information stored in IOS
10116 is then transferred to ED 10124 through I/O Bus
10126.
During execution o~ a user's prosram, certain
25 information required by JP 10116 may not be available in
MEM 10112~ In such cases as further described in a
following discussion, JP 10'14 may write a re~uest for
information into MEM 10112 and notify IOS 10116, by way
11'79063
99_
of IOJP ~us 10132, that uch a request has been made.
IOS 10116 will then read the request and transfer th~
desired information from ED 10124 into MEM 10112 through
IOS 10116 in the manner described above. In such
5 operations, IOS 10116 and JP 10114 operate together as a
memory manager wherein the memory space addressable by JP
10114 is termed virtual memory space, and includes both
MEM 10112 memory space and all external devices to which
IOS 10116 has access.
As previously described, DP 10118 provides a second
interface between Computer System 10110 and the external
world by way of DPIO Bus 10136. DP 10118 allows DU
10134, for example a CRT and keyboard unit or a teletype,
to perform all ~unctions which are convention~lly
15 provided by a hard ~i.e., switches and lights) console.
For example, DP iO118 allows DU 10134 to exercise control
of Computer System 10110 for such purposes as system
initialization and start up, execution of diagnastic
processes, and fault monitoring and identification. DP
20 10118 has read and write access ~o most memory and
register portions within each of IOS 10116, ME~ 10112, F~
10~20, and E~ 10122 by way o~ DP Bus 10138. ~emories and
registers in CS 10110 can therefore be directly loaded or
initialized durin~ system start up, and can be directly
25 read or loaded with test and diagnostic signals for fault
monitoring and identification. In addition, as described
9~)63
--100--
further below, microinstructions may be loaded into JP
10114's microcode circuitry at system start up or as
required.
~aving described the general structure and operation
of Computer System 10110, certain features of Computer
System 10110 will neat be briefly described to aid in
understanding the following, more detailed de~criptions
of these and other features of Computer System 10110.
c. ~e~s~
Certain terms are used relating to the structure and
operation of CS 10110 throughout ~he following
discussions. Certain of these terms will be discussed
and defined first, to aid in understanding the following
descriptions. Other terms will be introduced in the
following descriptions as required.
A ~se~ is a sequence of operational steps, or
instructions, to be executed to perform some operation.
~ procedure may include data to be operated upon in
per~orming the operation.
A ~LQs~m is a static group of one or more
procedures. I~ general, programs may be classified as
user programs, utility programs, and operating system
programs. A user program is a group of procedures
generated by and private to one particular user of a
25 group of users interacing with CS 10110. Utility
programs are commonly available to all users; for
- example, a compiler comprises of a set of procedures for
compiling a user language program into an S-language
~79(~3
--101--
program. Operating system programs are groups of
procedures internal to CS 10110 for allocation and
control of CS 10110 resources. Operating system programs
also define interfaces within CS 10110. Fo~ example, as
5 will be discussed further below all operands in a program
are referred to by "NA~E~. An opera~iny system program
translates op~rand ~AME into the physical locations o
the operands in MEM 10112. The NAME translation program
thus defines the interface between operand NAME ~name
space addresses) and MEM 10112 physical addresses.
~ A ~LQS~ is an independent locus of control passing
through physical, logical or vir~ual address spaces, or,
more particularly, a path of execu~ion through a series
of programs (i.e., procedures~. ~ process will generally
1~ include a user program and data plus one or more utility
programs (e.g., a compiler) and operating system programs
necessary to execute the user program.
An Q~i~~ is a uniquely identifiable portion of "data
space~ accessible to CS t 0110. An object may be regarded
20 a8 a container for information and may contain data or
procedure in~ormation or bothO An object may contain for
example, an entire pro~ram, or set of procedures, or a
single bit of data~ Objects need not be contiguously
located in the data space accessible to CS 10110, and the
in~ormation contained in an object need not be
contiguou~ly located in that object.
f `
6 3
-102-
A ~Qmal~ is a state of operation of CS ~0110 for the
purposes of CS 10110's protection mechanisms. Each
domain is defined by a set of procedures having access to
objects within that domain for ~heir execution~ Each
5 ob~ect has a single domain of execution in which it is
execute~ if it is a procedure object, or used, if it is a
data object. CS 10110 is said to be operating in a
particular domain if it is executing a procedure having
~hat domain of execution. Each object may belong to one
10 or more domains; an object belongs to a domain if a
procedure executing in that domain has potential access
to the objec~. CS 10110 may, ~or example have four
domains: User domain, Data Base Mana~ement System (DBMS)
domain, Extended Operating System (EOS) domain, and
15 Kernel Opexating System (~OS) domain. User domain is the
domain of execution of all user provided procedures, such
as user or utility procedures. DBMS domain is the domain
of exe~ution for opera~ing system procedures for storing,
retrieYing, and handling data. EOS domain is the domain
20 of execution of operating system procedures defining and
forming the user level interface with CS 10110, such as
procedures for controlling an executing files, processes,
and I/O operations. ROS domain is the domain of
execution of the low level, secure operating system which
25 manages and controls CS 1011015 physical resources.
Other embodiments of CS 10110 may have fewer or more
domains than those just deæcribed~ For example, DBMS
procedures may be incorporated into the EOS domain or EOS
9~ 6 3
-103-
domain may be divided by incorporating the I/O procedures
into an I/O domain. There is no hardware enforced
limitation on the numbe of, of boundaries between,
domains in CS 10110. Certain CS 10110 hardware functions
and structures are, however, dependent upon domains.
A ~ is defined, for purpose~ of CS lOllO's
protection mechanisms, as a combination of the current
principle (user), the current process being executed, and
the domain the process i~ currently being executed in.
In addition to principle, process, and domain, which are
identified by UIDs, subject may include a T2,g, which is a
user assigned identific~tion code used where added
security is required. For a given process, principle and
process are cons~ant but the domain is determined by the
procedure currently being executed. A process's
associated subject is therefore variable along the path
of execution of the process.
Having discussed and defined the above terms, certain
features of CS 10110 will next be briefly described.
d. ~ o~L ~ c5g~9~
CS 10110 is capable of concurrently executing two or
more progr~ms and selecting the sequence of execution of
programs to make most effective use of CS lOllO's
resources. This is referred to as multiprogramming~ In
this regard, CS 10110 may temporarily suspend execution
of one program, for example when a resource or cer~ain
information required for that program is not immediately
available, and proceed to execute another program until
l~t~9~3
-104-
the required resource or information becomes available.
For example, particular information required by a first
program may not be available in MEM 10112 when called
for. JP 10114 may, as discussed further below, suspend
execution of the first program, transfer a request for
that information to IOS 10116, and proceed to call and
execute a seco~d program. IOS 10116 would fetch the
requested information from ED 10124 and transfer it into
~EM 10112. A~ some time after IOS 10116 notifies JP
L0 10114 that the requested information is available in ME~
10112, JP 10114 could suspend execution of the second
program and resume execution of the first program.
e.
As previously described, CS 10110 is a multiple
15 language machine. Each program written in a high level
user language, such as COBOL or FORTRAN, is compiled into
a corresponding Soft (S) Language program. That is, in
terms of a conventional computer system9 each user level
language has a corresp~nding machine language,
20 classically defined as an assembly language. In contrast
to classical assembly languages, S-Languages are mid-
level languages wherein each command in a user's high
level language is replaced by, in general, two ar three
S-Language instructions, referred to as SI~s. Certain
25 SINs may be shared by two or more high level user
languages. CS 10110, as further described in following
discussions, provides a se~, or dialect, of microcode
ins~ructions (S-Interpreters) for each S-Language. S-
Interpreters interpret SI~s and provide corresponding
i:~79~3~3
-105-
sequences of microinstructions for detailed control of CS
10110. CS 10110's instruction set and operation may
therefore be tailored to each user's program, regardle~s
o~ the particular user language, so aq to most
e~ficiently execute the user's program~ Computer System
10110 may, for example, execute programs in both FORTRAN
and COBOL with comparable efficiency. In addition, a
user may wri~e a program in more than one high level user
language without loss of efficiency. For example, a user
may write a portion of his program in COBOL, but may wish
to write certain portions in FORTRAN. In such cases, the
COBOL portions would be compiled into COBOL SINs and
executed with the COBOL dialec~ S-Interpreter. The
FORTRAN portions would be compiled into FORTRAN SINs and
executed with a FORTRA~ dialect S-rnterpreter. The
15 present embodiment of CS 10110 utilizes a uniform ~ormat
for all SINs~ This ~eature allows simpler S-Interpreter
structures and increases efficiency of SIN interpretation
because it is not necessary to provide means for
interpreting each dialect individually.
2~ f. ~ L~ L~c~
Each object created for use in, or by oper~tion of, a
CS 10110 is permanently assigned a Unique Identifier
(U D~. An object's UID allows that object to be uniquely
identified and located at any time, regardless of which
25 particular CS 10110 it was created by or for or where it
is subsequently located. Thus each time a new object is
defined, a new and unique UID is allocated, much as
9~ 6 3
-106-
social secuxity numbers are allocated to individuals. A
particular piece of information contained in an object
may be ~ocated by a logical address comprising the
object's UI~, an offset from the start of the object of
S the first bit of the segment, and the length (number of
bits) of the information segment. Data within an object
may therefore be addressed on a bit granular basis. As
will be described ~urther in following discussions, UID's
are used within a CS 10110 as logical addresses, and, for
example, as pointers. Logically, all a*dresses and
pointers in CS 10110 are UID addresses and pointers. As
previously described and as described below, however,
short, temporary unique identifiers, valid only wlthin JP
10114 and referred to as Active Object Numbers are used
15 within JP 10114 to reduce the width of address buses and
amount of address information handled.
An objec~ becomes active in CS 10110 when it is
transferred from backing store CED 10124 to MEM 10112 for
use in executi~g a process. At this time, each such
20 object is assigned an Active Object ~umber (AON3. AONs
are short unique identifiers and are related to the
object's UIDs through certain CS 10110 in~ormation
ructures described below. AO~s are used only within JP
10114 and are used in JP 10114, in place of UIDs, to
reduce the required width of JP 10114's addre~s buses and
the amount of address data handled in JP 10114. As with
UID logical addresses~ a piece of data in an object may
be addressed through a bit granular AOM lo~ical address
comprising the object's AON, an offset from the start of
~i~79(~6~
-107-
the object of the first bit of the piece, and the length
of the piece.
~ he transfer o~ logical addresses, for example
pointers, between ~E~ 10112 (UIDA) a~d JP 10114 (AONs)
5 during execution of a process requires translations
between UIDs and AO~s. As will be described in a later
discussion, this translation is accompli hed, in part,
through the information structures mentioned above.
Similarly, translation of logical addresses to physical
10 addresses in ~E~ 10112, to physically access information
stored in MEM 10112, is accomplished throu~h CS 10110
in~ormation structures relating AO~ logical addresses to
MEM 10112 physical addresses.
Each operand appearing in a program is assigned a
15 ~ame when the program is compiled. Thereafter, all
reerences to the operands are through their assigned
~ames. As will be described in detail in a later
discussion, CS 10110's addressing structure includes a
mechanism for recognizing Names as they appear in an
instruction stream and Name Tables containing directions
for resolving Names to AON logical addresses. AON
logical addresses may then be evaluated, for example
translated into a MEM 10112 physical address, to provide
actual operands. The use of Names to identify operands
in the instructions stream (process) ~1~ allow~ a
complicated address to be replaced by a simple reference
of uniform format; ~2? does no~ require that an
operation be directly defined by data type in the
instruction stream; ~3) allows repeated references to an
30 operand to be made in an instruction stream by merely
9 O ~ 3
-108-
repeating the operand's Name; and, (4) allows partially
completed Name to address translations to be stored in a
cache to speed up operand re~erences. The use of ~ames
thereby substantially reduces the voIume of information
required in the instruction stream for operand references
and increases CS 10110 speed and e~ficiency by performing
operands references through a parallel operating,
underlying mechanism~
~inally, CS 10110 address structure incorporates a
seS of Architectural Base Pointers (ABPs) for each
process. ABPs provide an addressing framework to locate
data and procedure information belonging to a process and
are used, for example, in resolving Names to AON logical
addresses.
g- ~
CS 10110's protection mechanism is constructed to
prPvent a user from ~1) gaining access to or disrupting
another user's process, including data, and (2)
in~erfering with or otherwise subverting the operation of
20 CS 10110. Access rights to each particular acti~e object
are dynamically granted as a function of the currently
active subject. A subject i5 defined by a combination of
the current principle (user), ~he curren~ process beiny
executed, and the domain in which the process is
currently being executed. In addi~ion to principle~
process, and domain, subject may include a Tag, which is
a user assigned identification code used where added
security is required. For a given process~ the principle
, .
1 ~79C~63
-109--
and process are constant but the domain is determined by
the proceduxe currently being executed. A process's
associated subject is therefore variable along the path
of execution of the process.
In a present embodiment of CS l0ll0, procedures
having ~OS domain of execu~ion have access to objects in
ROS, EOS, DBMS, and User domains; procedures ha~ing EOS
domain of execution have access to objects in ~OS, DBMS,
and User domains; procedures having DBMS domain of
execution have access to objects in D8~S and User
domains; and procedures having User domain of execution
have access only to objects in User domain. A user
cannot, therefore, obtain access to objec~s in ~OS domain
of execution and cannot influence CS l0ll0's low level,
secure operating system. The user's process may,
however, call for execution a procedure having ~OS domain
of execution. At this point the process's subject is in
the KOS domain and the procedure will have access to
certain objects in ROS domain.
In a present embodiment of CS l0ll0, also described
in a later discussion, each object has associated with it
an Access Control List (ACL~ An ACL contains an Access
Control Entry (ACE~ for each subject having access to
that object. ACEs specify, for each subject, access
25 ~ights a subject has with regard to that object.
There is normally no relationship, o~her than that
defined by an object's ACL, between subjects and
objects. CS l0ll0, however, supports Extended Type
~1~79063
--11 o--
Objects having Extended ACLs wherein a user may
speci$ically define which subjects have what access
rights to the object.
In another embodiment of CS l0ll0, described in a
5 following discussion, access rights are granted on a
dynamic basis. In executing a process, a proGedure may
call a second procedure and pass an argument to the
called procedure. The calling procedure will also pass
selected access rights to that argument to ~he called
10 procedure. The passed access rights exist only for the
duration of the call.
In the dynamic access embodiment, access rights are
granted only at the time they are required. In the ~CL
embodiment, access rights are granted upon object
creation or upon specific requPst. In either embadiment,
each procedure to which arguments may be passed in a
cross-domain call has associated with it an Access
Information Array ~AIA3. A procedure's AIA s~ates what
access rights a calling procedure (subject3 must have
20 before the called procedure can operate on the passed
argument. CS l0ll0's protection mechanisms compare the
calling procedure'~ access rights to the rights required
by the called procedure. ~his ensures that a calling
procedure may no ask a called procedure to do what the
calling procedure is not allowed to do. Effectively, a
calling procedure can pass to a called procedure only the
access right~ held by the calling procedure.
.j
1~79(~63
--11 1-- ,
~ aving described the general structure and operation
and certain features of CS 10110, those and other
features of CS 10110 operation will next be described in
greater detail,
B.
CS 10110 contains certain information structures and
mechanisms to assist in efficien~ execution of
processes. These structures and mechanisms may be
10 considered as falling into three general types. The
first type concerns the processes themselves, i.e.,
procedure and data ob~ects comprising a userls process or
directly related to execution of a user's process. The
sècond type are for managementr control, and execution of
15 processes~ These structures are generally shared by all
processes active in CS 10110. The third type are CS
iOllO micromachine information structures and
mechanisms. These structures are concerned with the
eternal operation o~ the CS 10110 micromachine and are
20 privat~ to the CS 10110 micro-machine.
a. ~ sD~D~ =L:~Y_~e~l
Referring to Fig. 102, a pictorial representation of
CS 10110 (MEM 10112, FU 10120, and EU 10122) is shown
with certain information struc~ures and mPchanisms
25 depicted therein. It should be understood that these
information structures and mechanisms transcend or ~cut
across~ the boundaries between ~EM 10112, FU 10120, E~
10122, and IOS 10116. Referring to the upper portion of
Fig. 103 Process Structures 10210 contains those
79~363
--11 2--
information structures and mechanisms most closely
concerned with individual processes, ~he firs~ and third
types of information structures described above. Process
Structures 10210 reside in ME~ 10112 and Virtual
5 Processes lG212 include Virtual Processes (V~ 1 through
N. Vir~ual Processes 10212 may contain, in a present
embodiment of C5 10110, up to 256 VP's. As previously
described, each VP includes certain obj cts particular to
a single user's process, for example stack obj ects
10 previously described and further described in a following
description. Each VP also includes a Process Object
containing certain information required ~o execute the
process~ for example pointers to other process
information.
Virtual Processor State Blocks (VPSBs) 10218 include
VPSBs containing certain tables and mechanisms for
managing execution of VPs selected for execution by CS
10110 .
A particular VP is bound into CS 10110 when a ~irtual
20 Process Dispatcher, described in a following discussion
selects that VP as eligible for execution. The sPlected
VPs Process Object, as previously described, i swapped
into a VPSB. VPSBs 10218 may contain, for example 16 or
32 ~tate Blocks so that CS 10110 may concurrently execute
25 up to 16 or 32 VPs. When a VP assigned to a VP9B is to
be executed, the VP is swapped onto the informa~ion
structures and mechanisms shown in ~U 10120 and EU
10122. FU Register and Stack Mechanism (FURS~ 10214 and
EU Register and Stack Mechanism (EU~SM) 10216, shown
~79063
-11 3--
respectively in FU 10120 and EU 10122, comprise register
and stack mechanisms used in execution of VPs bound to CS
10110. These register and stack mechanisms, as will be
discussed below, are also used for certain CS 10110
5 process manageme~t functions. Procedure Objeets (POs)
10213 contain Procedure Objects (POs) l to N of the
processes executing in CS 10110.
Addressing Mechanisms (AM) 10220 are a part of CS
10110's process management system and are generally
10 associated with Computer System 10110 addressing
functions as described in following discussions. ~ID/AON
Tables 10222 is a structure for relating UID's and AON's,
previously discussed. ~emory Management Tables 10224
includes structures for (1~ relating AON logical
15 addresses and ~EM 10112 physical addresses; (2) managing
MEM 10112's physical address space; (3) managing
transfer of information between MEM 10112 and CS 10110's
backing store tED 10124) and, (4) activating objects
into CS 1011~; N~me Cache (~C) 10226 and Address
20 Translation Cache (ATC) 10228 are acceleration mechanisms
- for storing addressing in~ormation relating to the VP
currently bound to CS 10110. NC 10226, described further
below, contains information relating operand Names to AON
addresses. ATC 10228, also discussed further below,
25 contains information relating AON addresses to MEM 10112
phys i cal addr es s e s .
9~ ~ 3
-114-
Protection Mechanisms 10230, depicted below AM 10220,
include Protection ~ables 10232 and Protection Cache (PC)
10234. Protection Tables 10232 contain information
regarding access rights to each object active in CS
5 10110. PC 10234 contains protection in~ormation relating
to certain objects of the ~P currently bound to CS 10110.
Microinstruction Mechanisms 10236, depicted below PM
10230, includes Micro-code (M Code? Store 10238, FU
(Micro-code) M Code Structure 10240, and EU Micro-code (M
lD Code) Structure 10242. These structures contain
microinstruction mechanisms and tables for interpreting
SINs and controlling the detailed operation of CS 10110.
~icro-instruction Mechani~ms 10232 also provide microcode
tables and mechanisms used, in part, in operation of the.
15 low level, secure operating system that manages and
controls CS lOllO's physical resources.
~ aving thus briefly described certain CS 10110
information structures and mechanisms with the aid of
Fig, 102, those information structures and mechanisms
20 will next be described in fur~her detail in the order
mentioned above. In these descriptions it should be
noted that, in representation o~ ~EM 10112 shown in Fig.
102 and in other figures of following discussionst the
addressable memory space of ~EM 10112 is depicted.
25 Certain portions of ME~ 10112 address space hav~ been
designated as containing certain information structures
and mechanisms. These structures and mechanism~ have
real physical existence in ~E~ 10112, but may vary in
both location and volume of MEM 10112 address space they
30 occupy. Assigning position o~ a single, large memory to
;
9063
--11 5--
contain these structures and mechanisms allows these
structures and mechanisms to be recon~igured as required
for most eficient operation of CS 10110O In an
alternate embodiment, physically separate memories may be
5 used to contain the structures and mechanisms depicted in
MEM 10112, rather ~han assigned portions of a single
memory.
b.
Referring to Fig. 103, a partial schematic
representation of Process Structures 10210 is shown.
Specifically,. Fig. 103 shows a Process (P) 10310 selected
for execution, and its associated Procedure Objects (PO~)
in Process Objects (POs3 10213. P 10310 is represented
in Fig. 103 as including four procedure objects in POs
10213. It is to be understood that this representation
is for clarity of presentation; a particular P 10310 may
include any number of procedure objects. Also for
clarity of presentation, EU~S~ 10216 is not shown as
E~RSM 10216 is similar to F~RS~ 10214. EURSM 10216 will
be described in detail in the following detailed
discussons of CS 10110's structure and operation.
As previously discussed, each process includes
certain data and procedure object. As represented in
~ig~ 103 for P 10310 the procedure objects reside in POs
10213. The data objects include Static Data Areas and
stack mechanisms in P 10310. POs, for example ROS
Procedure Object (ROSPO) 10318, contain the various
9 ~ 6 3
-116-
procedure~ of the process, each procedure being a
sequence of SINs de~ining an operation to be performed in
executing the process. As will be described below9
Procedure Objects also contain certain information used
in executing the procedures contained therein. Static
Data Areas ~SDAs) are data objects generally reserved for
storing data having an existence for the duration of the
process. P 10310's stack mechanisms allow s~acking Gf
procedures for procedure calls and returns and for
10 swapping processes in and out of JP 10114. Macro-Stacks
(MAS) 10328 to 10334 are generally used to store
automatic data (data generated during execution o a
procedure and having an existence for the duration of
that procedure) A ~lthough shown as separate from the
15 stacks in P 10310, ~he SDAs may be contained with ~ASs
10 28 to 10334. Secure Stack (SS) 10336 stores, in
general, CS 10110 micro-machine state or each procedure
called. Information stored in SS 10336 allows machine
state to be recovered upon return from a called
20 procedure, or when binding (swapping) a VP into ~S 10110.
As shown in P 10310, each process is structured on a
domain basis. A P 1031~ may therefore include, for e~ch
domain,.one or more procedu~e objects containing
procedures having that domain as their domain of
25 execution, an SDA and an MAS. For example, KOS domain of
P 10310 includes ROSPO 10318, ROSSD~ 10326, and ROS~S
10334. P 10310's SS 10336 does not reside in any single
domain of P 10310, but instead is a stack mechanism
belonging to CS 10110 micromachine.
~7~)63
-117-
~aving described the overall structure of a P 10310,
the individual information structures and mechanisms of a
P 10310 will next be described in greater detail.
1. ~=
KOSPO 10318 is typical of CS 10110 procedure objects
and will be referred to for illustration in the following
discussionO Major components of ROSPO 10318 are Header
10338, External Entry Descripter (~ED) Area 10340,
Internal Entry Descripter (IED) Area 10342, S-Op Code
Area 10344, Procedure Environment Descripter (PED) 10348,
Name Table (~T~ 10350, and Access Information Array (AIA)
Area 10352D
Header 10338 contains certain information iden~ifying
PO 10318 and indicating the number of entries in EED area
10340, discussed momentarily.
EED area 10340 and IED area 10342 together contain an
Entry Descripter (ED) for each procedure in ROSPO 10318,
ROSPO 10318 is represented as containing Procedures 1, 2,
and 11, of which Procedure 11 will be used as an example
in the present discussion. EDs e~fectively comprise an
index through certain all information in KOSPO 10318 can
be located. IEDs form an index to all ROSPO 10318
procedures which may be called only from other procedures
contained in ROSPO 10318. EEDs form an index to all
25 ~OSPO 10318 procedures which may be called by procedureæ
ext~rnal to ROSPO }0318. Ex~ernally callable procedures
11~79(~63
--118--
are distinguished aid, as described in a following
dlscussion of CS 10110's protection mechanisms, in
conf irming external calling procedure's access rights.
Raferrin~ to ED 11, ED for procedure 11, three fields
5 are shown therein. Procedure Environment ~escripter
Offset (PEDO) field indicates the start, rela~ive to
s~art o~ ~OSPO 10318, of Procedure ll's PED in PED Area
10348. As will be discussed further below, a procedure's
PED contains a set of pointers for locating information
10 used in ~he execution of that procedure. PED Area 10348
contains a PED for each procedure contained in 10318. In
the present embodiment of CS 10110, a single PED may be
shared by two or more procedures. Code Entry Point (CEP)
field indicates the start, relative to Procedure Base
Pointer (PBP) which will be discussed below, of Procedure
ll's SI~ Code and SI~ Code Area 10344. Finally, ED ll's
Initial Frame Size (IFS) field indicates the required
Initial Frame Size of the ROSMAS 10334 frame storing
Procedure ll's automatic data.
PED 11, Procedure ll's PED in PED Area 10348,
contains a set of pointers for locating information used
in execution of Procedure 11. The first entry in PED 11
is a header containing information identifying PED 11.
PED ll's Procedure Base Psinter ~PBP) entry is a pointer
25 providing a fixed reference from which other information
in PO 10318 may be located. In a specific examplet
Procedure ll's CEP indicates the location, relative to
~t~90~3
-119-
PBP, of the start of Procedure ll's S-Op code in S-Op
Code Area 10344. As will be described further below, PBP
is a CS 10110 Architectural Base Pointer (ABP)~ CS
10110Is ABP's are a set of architectural pointers used in
5 CS 10110 to facilitate addressing of CS 10110's address
sp ce. PE~ ll's Static Data Pointer (SDP) en~ry points
to data, in PO 10318, specifying certain parameters of P
10310's KOSSDA 10326 r ~ame Table Pointer (NTP) entry is
a pointer indicating the location, in ~T 10350, of ~ame
10 Table Entry's (~T~'s) for Procedure ll's operands. NT
10350 and ~TE's will be described in grea~er detail in
th~ following discussion of Computer System 10110's
Addressing Structure. PED ll's S-Interpreter Pointer
(SIP) entry is a pointer, discussed in greater detail in
15 a following disc-lssion o~ CS 10110's microcode structure,
pointing to the particular S-Interpeter (SINT) to be used
in interpretlng Procedure ll ' s SIN Code.
Referring finally to AIA 10352, AIA 10352 con~ains,
as previously discussed, information pertaining to access
20 righ~s required of any external procedure calling a 10318
procedure. There is an AIA 10352 entry for each PO 10318
procedure which may be called by an external procedure.
A particular AIA entry may be shared by one or more
procedures having an ED in EED Area 10340. Each EED
25 contains certain in~orma~ion, not shown for clarity of
presentation, indicating that that procedure's
901~3
--~20--
corresponding ~IA entry must be referred to, and the
calling procedure's access rights confirmed, whenever
that procedure is called.
2.
As previously described, P 10310's stack mechanisms
include SS 10336, used in part for storing machine st te,
and MAS's 10328 to 10334, used to ~tore local data
generated during execution of P 10310's procedures. P
10310 is represented as containing an MAS ~or each CS
10110 domain. In an alternate embodiment of CS 10110, a
particular P 10310 will include MAS's only for those
domains in which that P 10310 is executing a procedure.
Referring to MAS's 10328 to 10334 and SS 10336, P
10310 is represented as having had eleven procedure
calls. Procedure 0 has called Procedure 1, Procedure 1
has called Procedure 2, and so on. Eaoh time a procedure
is called, a corresponding stack frame is constructed on
~he ~AS of the domain in which the called procedure is
executed. ~or example, Procedures 1, 2, and 11 execute
in gOS domain; ~AS frames for Procedures 1, 2, and 11
therefore are placad on gOSMAS 10334. Similarly,
Procedures 3 and 9 execute in EOS domain, so that their
stack f rames are placed on EOSMAS 10332. Procedures 5
and 6 execute in DBMS domain, 90 that their stack frames
are placed on DBMS~AS 10330. Procedures 4, 7, 8, and 10
execute in User domain with their stack frames being
placed on USERMAS 10328~ Procedure 11 is the most
79 ~ 3
-121-
recently called procedure and procedure ll's stack frame
on KOSMAS 10334 is referred to as the current frame.
Procedure 11 is the procedure which is curre~tly being
executed when VP 10310 is bound to CS 10110~
SS 10336, which is a stack mechanism of CS 10110
micromachine, contains a frame for each of Procedures 1
to 11. Each SS 10336 frame contains, in part, CS 10110
operating state for its corresponding procedure.
Referring to Fig. 104, a schematic representation of
10 a typical MAS, for example ROSMAS 10334, is shown.
ROSMAS 10334 includes Stack Header 10410 and a Frame
10412 for each procedure on ROSMAS 10334. Each ~rame
10412 includes a Frame ~eader 10414, and may contain a
Linkage Pointer Block 10416, a Local Pointer Block 10418,
15 and a Local (Automatic) Data Block 10420.
ROSMAS 10334 Stack ~eader 10410 contains at least the
following information:
(1) an offset, relative to Stack ~eader 10410,
indicating the location of Frame ~eader 10414 of ~he
20 first frame on ROSMAS 10334;
(2) a S~ack Top Offset (STO) indicating location,
relatiYe to start of ROSMAS 10334, of the top of ROfiMA~
10334; top of ROSMAS 10334 is indicated by pointer STO
pointing to the top of the last entry of Procedure 11
25 Frame 10412's Local Data Block 10420;
(3) an offset, relative to start of KOSMAS 10334,
indicaLing location of Frame ~eader 10414 of the current
top frame of ROSMAS 10334; in Fig. 104 this offset is
--`-\ r
li~79a~3
--122--
represented by Frame Pointer (FP), an ABP discussed
further below;
(4) the VP 10310ls UID;
t5) a UID pointer indicating location of certain
5 domain enviroNment information, described further in a
following discussion;
(6) a signaller pointer indicating the location of
certain routines for handling certain CS 10110 operating
system faults;
(7) a UID pointer indicating location of ~OSSDA
10326; and
t83 a frame label sequencer containing pointers to
headers of frames in other domains; these pointers are
used in executing non-local go-to operations.
ROSMAS 10334 Stack Header 10410 thereby contains
information for locating certain important points in
~OSMAS 10334's struc~ure, and for locating certain
information pertinent to executing procedures in ROS
domain.
Each Frame Header 10414 contains at least ~he
following information:
~1) offsets, relative to the Frame ~eader 10414,
indicating the locations of Frame aeaders 10414 of the
previous and next ~rames o~ ROSMAS 10334;
(2) an off9et, relative to the Frame ~eader 10414,
indicating the location of the top of that Frame 10412;
(3) information indicating the number of passed
arguments contained in that Frame lQ412;
1~79~)63
., .
-123-
~ 4) a dynamic back pointer, in UID/Offset format, to
the previous Frame 10412 if that previous Frame 10412
resides in another domain;
(5) a UID/Offs~t pointer to the environmental
S descripter Qf the procedure calling that procedure;
(6) a frame label sequence containing information
indicating the locations of other Frame ~ea~ers lU414 in
ROS~AS 10334; this information is used to locate other
frames in ~OSMAS 10334 for the purpose o~ executing local
10 go-to operations. Frame ~eaders 10414 thereby contain
information for locating certain importan~ points in
RO5MAS 10334 structure, and certain data pertinent ~o
executing the associated procedures. In addition, Frame
~eaders 10414, in combination with Stack ~eader 10410~
15 con~ain information for linking the activation reGords of
each VP 10310 MAS, and for linking together the
activation records of the individual MAS's.
Linkage Pointer Blocks 10416 contain pointers to
arguments passed from a calling procedure to the called
20 procedure. For example, Linkage Pointer Block 10416 of
Procedure ll's Frame 10412 will contain pointers to
arguments passed to Procedure 11 from Procedure 10. The
use of linkage pointers in CS 10110's addressing
structure will be discussed further in a following
25 discussion of CS 10110's Addressing Structure. Local
Data Pointer Blocks 10418 contain poin~ers to certain of
the associated procedure's local dataO Indicated in Fig.
104 is a pointer, Frame Pointer (FP), pointing between
~ - .
7~ 06 3
-124-
top most Frame 10412's ~inkage Pointer Block 10416 and
Local Data Pointer Block 10418. FP, described ~ur~her in
following discussions, is an ABP to ~AS Frame 10412 of
the process's current procedure.
Each Frame 10412's Local (Automatic) Data Block 10420
contains certain of the associated procedure's automatic
data.
As described a~ove, at each procedure ~all a MAS
frame is cons~ructed on top of the MAS of the domain in
10 which the called procedure is executed. For example,
when Procedure 10 calls Procedure 11 a Frame ~eader 10414
for Procedure 11 is constructed and placed on ROSMAS
10334~ Procedure ll's linkage pointers are then
generated, and placed in Erocedure ll's Linkage Pointer
15 Block 10416. ~ext Procedure ll's local pointers are
generated and placed in Procedure ll's Local Pointer
Block 10~18. Finally, Procedure ll's local data is
placed in Procedure ll's Local Data Block 104200 During
this operation, USERMAS 10328ls frame label sequence is
20 updated to include an entry pointing to Procedure ll's
Frame ~eader 10414. KOS~AS 1033~ ' s Stack ~eader 10410 is
updated with respect to STO to the new top of ROSMAS
10334. Procedure 2's Frame ~eader 10414 is updated with
respect to ofset to Frame ~eader 10414 of Procedure 11
25 Frame 10412, and with respect to frame label sequence
indicating location of Procedure ll's Frame Header
10414. As Procedure 11 is then the current procedure, FP
is updated to a point between Linkage Pointer Block 10416
and Local Pointer Block 10418 of Procedure ll's Frame
30 10412. Also, as will be discussed below, a new frame is
-
11~79~63
-125 -
constructed on SS 10336 or Procedure 11. CS 10110 will
then proceed to execute ~rocedure 11. During execution
of Procedure 11, any further local data generated may be
placed on the top of Procedure ll's Local Data Block
10420. The top o~ stack o~fset information in Procedure
ll's Frame ~eader 10414 and in KOS~AS 10334 Stack ~eader
10410 will be updated accordingly.
~ AS's 10328 to 10334 thereby provide a per domain
stack mechan~sm for storing data pertaining to individual
10 procedures, thus allowing stacking of procedures without
loss of this dataO Although structured on a domain
basis, MAS's 10328 to 10334 comprise a unified logical
stack structure threaded together through information
stored in MAS stack and frame headers.
As described above and previously, SS 10336 is a CS
10110 micromachine stack structure for storing, in part,
CS 10110 micromachine state for each stacked VP 10310
procedure. Referring to Fig. 105, a partial schematic
representation of a SS 10336 Stack Frame 10510 is shown.
20 SS 10336 Stack Header 10512 and Frame ~eaders 10514
contain informatio~ similar to tha~ in ~AS S~ack Headers
10410 and Frame ~eaders 10414. Again, the information
contained therein locates certain points within SS 10336
structure, and threads together SS 10336 with MAS's 10328
to 1~334.
SS 10336 Stack Frame 10510 contains certain
information used by the CS 10110 micromachine in
executing tha VP 10212 procedure with which this frame is
~7~ ~6 3
-126-
associated. Procedure Pointer Block 10516 contains
certain pointers lncluding ABPst used by CS 10110
micromachine in locating information within VP 10310's
information structures. Micro-Routine Frames ~RFs)
5 10518 together comprise ~icro-Routine 5tack (MRS) 10520
within each SS 10336 Stack Frame 10510. MRS Stack 10520
is associated with the internal operation of CS 10110
microroutines executed during execution of the VP 10212
procedure associated with the Stack Frame 10510. SS
10 10336 is thus a dual function CS 10110 micromachine
stack. Pointer Block 10516 entries effectively de~ine an
interface between CS 10110 micromachine and the current
procedure of the current process. MRS 10520 comprise a
stack mechanism for the internal opera ions of CS 10110
15 micromachine.
~ aving briefly described Virtual Processes 10212,
FURSM 10214 will be described next. As stated above,
EURS~ 10216 is similar in operation to FURSM 10214 and
will be described in following detailed descriptions o
20 CS I0110 structure and operation.
3~ ~B~Y~ LbL r~b5~=t~9~
Referring again to Fig. 103, FURS~ 10214 includes CS
10110 micromachine information struc~ures used internally
to CS 10110 micromachine in executing the procedures of a
p 10310. When a VP, for example P 10310, is to be
executed, certain information regarding that VP is
transferred from the Virtual Processes 10212 to FURSM
1~79063
--1 27--
10214 for use in executing that procedure. In this
respect, FURSM 10214 may be regarded as an acceleration
mechanism for the current Virtual Process 10212.
~VRSM 10214 includes General Register File (GRF)
10354, ~icro Stack Pointer R~gister Mechanism (~ISPR)
10356, and Return Control Word Stack (RCWS) 10358. GRF
10354 includes Global Registers (GRs) 10360 and Stack
Registers (SRs) 10362. GRs 10360 include Architectural
Base Registers (ABRs~ 10364 and Micro-Control Registers
(MCRs) 10366. Stack Re~isters 10362 include Micro-Stack
(MIS) 10368 and Monitor Stack (~OS) 10370.
Referrin~ first to GRF 10354, and assuming for
example that Procedure 11 of P 10310 is curren~ly being
executed, GRE 10354 primarily contains certain pointers
to P 10310 data used in execution of Procedure 11. As
previously disussed, CS 10110's addressing structure
includes certain Architectural Base Pointers (ABP's) for
each procedure. ABPs proYide a framework ~or excessing
CS 10110's address space. The ABPs of each procedure
20 include a~Frame Pointer ~FP), a Procedure Base Pointer
(PBP), and a Static Data Pointer ~STP). As discussed
above with reference to ROSPO 10318, these ABPs reside in
the procedure's PEDs. When a procedure is called, these
ABP's are trans~erred from that procedure's PED ~o ABR's
25 10364 and reside therein ~or the duration of that
procedure. As indicated in Fig~ 103, FP points between
Linkage Pointer Block 10416 and Local Pointer ~locks
10418 of Procedure 11's Frame 10412 on ROSMAS 10334~ PBP
points to the reference point from which the elements of
30 ROSPO 10318 are located. SDP ~oints to ~OSSDA 1032~. If
9 ~6 3
-128-
Procedure 11 calls, for example, a Procedure 12,
Procedure ll's ABPs will be transferred onto Procedure
Pointer Block 10516 o~ SS 10336 9tack Frame 10510 for
Procedure 11. Upon return to Procedure 11, Procedure
s 11 ' s ABPs will be transferred ~rom Procedure Pointer
Block 10~16 to ABR' 10364 and execution of Procedure 11
resumed.
MCRs 10336 contain certain pointers used by CS 10110
micromachine in executing Procedure 11. CS 10110
micromachine pointers indicated in Fig. 103 include
Program Counter (PC), Name Table Pointer (NTP), S-
Interpreter Pointer (SIP), Secure Stack Pointer (SSP),
and Secure Stack Top Offset tSSTO). NTP and SIP have
been previously described with reference to KOSPO 10318
and reside in ROSPO 10318. NTP and SIP are transferred
into MCR's 10366 at start of execution of Procedure 11.
PC, as indicated in Fig. 103, is a pointer to the
Procedure 11 SIN currently being executed by CS 10110.
~ pc is initially generated from Procedure ll's PBP and CEP
and is thereafter incremented by CS 10110 micromachine as
Procedure ll's SI~ sequences are executed. SSP and SSTO
are, as described in a following discussion, generated
from information contained in SS 10336's Stack ~eader
10512 and Frame ~eaders 10514. As indicated in Fig~ 103
SSP points to start of SS 10336 while SSTO indicates the
current top frame on SS 10336, whether Procedure Pointer
Bloc~ 10516 or a MRF 10518 o~ MRS 10520, by indicating an
offset relative to SSP. If Procedure 11 calls a
subsequent procedure, the conten~s of ~CR's 10366 are
-
~79 ~ ~ 3
-129-
transferred into Procedure ll's Procedure Pointer Block
10516 on SS 10336, and are returned to MCR's 10366 upon
return to Procedure 11.
Registers 10360 contain ~urther pointers, described
in following detailed discussions of CS 10110 operation,
and certain registers which may be used to contain the
current procedure's local data.
Referring now to S~ack Registers 10362, MIS 10368 is
an upward extension, or acceleration, of MRS 10520 of the
current procedure. As previously stated, MRS 10520 is
used by CS 10110 micromachine in executing certain
microroutines during execution of a particular
procedure. MIS 10368 enhances the efficiency of CS 10110
micromachine in executing the~e microroutines by
1~ accelerating certain most recent MRFs 10518 of that
procedure's MRS 10520 into FU 10120. MIS 10368 may
contain, for example, up to the eight most recent ~RFs
10518 of the current procedures ~RS 10520. As various
microroutines are called or returned from, ~RS 10520
~RFIs 10518 are transferred accordingly between SS 10336
and MIS 10358 so that MIS 10368 always contains at least
the top ~RF 10518 of MRS 10520, and at most eight MRFs
10518 of MRS 10520. ~ISPR 10356 is a CS 10110
micromachine mechanism for maintaining ~IS 10368. MISPR
103S6 contains a Current Pointer, a Previous Pointer, and
a Bottom Pointer. Current Pointer points to the top-mos~
MR~ 10518 on MIS 10368. Previous Pointer points to the
previous MRF 10518 on MIS 10368, and Bottom Pointer
points to the bottom-most ~RF 10518 on MIS 10368. MISPR
10356's Current, Previous and Bottom Pointers are updated
~lt~90~3
-130-
as MRFs 10518 are transferred between SS 10336 and MIS
10368. If Procedure 11 calls a subsequent procedure, all
Procedure 11 ~RFs 1051~ are transferred from MIS 10368 to
Procedure ll's MRS 10520 on SS 10336. Upon return to
Procedure 11, up to seven of Procedure ll's MR~s 10518
frames are returned from SS 10336 to MIS 10368.
Referring to MOS 10370, MOS 10370 is a stack
mechanism used by CS 10110 micromachine for certain
microroutines for handling fault or error conditions~
These microroutines always run to completion, so that MOS
10370 resides entirely in FM 10120 and is not an
extension of a stack residing in a P 10310 in MEM 10112.
MOS 10370 may contain, for example, eight frames. If
~ more than eight successive fault or error conditions
occur, this is regarded as a major ~ailure of CS 10110.
Control of CS 10110 may then be transferred to DP 10118.
: As will be described in a following discussion,
diagnostic programs in DP 10118 may then be used to
diagnose and locate the CS 10110 faults or errors. .In
other embodiments of CS 10110 ~OS 10370 may contain more
or f~wer stack frames, depending upon the degree of sel~
diagnosis and correction capability desired for CS 10110.
RCWS 10358 is a two-part stack mechanism. A first
part operates in parallel with MIS 10368 and a second
part operates in parallel with MOS 10370~ As previously
described, CS 10110 is a microcode controlled system.
RCWS is a stack for storing the current ~icroinstruction
9 ~6 3
-131-
being executed by CS 10110 micromachine when~the current
procedure is interrupted by a fault or error condition,
or when a subse~uent procedure is called. That portion
of RCWS 10358 associated with MIS 10368 contains an entry
for each MRF 10518 residing in MIS 10368. These RCWS
10358 entries are transferred between SS 10336 and ~IS
10368 in parallel with their associated MRFs 10518. When
resident`in SS 10336, these RCWS 10358 entries are stored
within their associat~d MRFs 10518~ That portion of RCWS
10358 associated with MOS 10370 similarly operates in
parallel with ~OS 10370 and, like MOS 10370, is not an
extension of an MEM 10112 resident stack.
In summary, each process active in CS 10110 exists as
a separate, complete~ and s lf-contained entity, or
15 Virtual Process, and is structurally organized on a
domain basis. Each Virtual Process includes, besides
procedure and data objects, a set of MAS's for storing
local data of that processes procedures. ~ach Virtual
Process also includes a CS 10110 micromachine stack, 5S
20 10336, for storing CS 10110 micromachine state pertaining
to each stacked procedure of the Virtual Process. CS
10110 micromachine include~ a set of information
structures, register 103Ç0, MIS 10368, MOS 10370, and
RCWS 10358, u~ed by CS 10110 micromachine in execu~ing
25 the Virtual Process's procedures. Certain of these CS
10110 micromachine information structures are shared with
the currently executing Virtual Process, and thus are
effectively acceleration mechanisms for the current
Virtual Process, while others are completely in~ernal to
30 CS 10110 micromachine.
1179063
-132-
A primary eature of CS 10110 is that each process'
macrostacks and secure stack resides in MEM 10112. CS
10110's macrostack and secure stack are therefore
effectively unlimited in depthO
Yet another feature of CS 10110 micromachine is the
use of GRF 10354r GRF 10354 is, in an embodiment of CS
10110, a unitary register array containing for example,
256 registers~ Certain portions, or address locations,
of GRF 10354 are dedicated to, respectively, GRs 10360,
10 ~IS 10368, and ~OS 10370. The capacities of GR 10360,
MIS 10368? and MOS 10370, may therefore be adjuste~, as
re~uired for optimum CS 10110 efficiency, by re~ssignment
of GRF 10354's address space. In other embodiments of CS
10110, GRs 10360, MIS 10368, and MOS 10370 may be
implemented a functionally separate registers arrays.
Having briefly described ~he structure and operation
of Process Structures 10210, VP State Block 10218 will be
described next below.
C.
~ L.5~ h~ b~C=le-l
Referring again to Fig. 102, VP State Blocks 10218 is
used in management and control of processes. VP State
Blocks 10218 contains a VP State Block for each Virtual
Process (VP) selected for execu~ion by CS 10110. Each
25 such VP State Block contains at least the following
information:
(1) the state, or identification number of a VP;
~ :~
79~163 `
-13~-
(2) entries identifying the particular prinaiple and
, particular process of the VP;
(3) an AON pointer to that VP's secure stack (e.g.,
SS 10336);
~4) the AON's of that VP's MAS stack objects (e.g.,
MAS's 10328 to 10334); and,
(5~ certain information used by CS 10110's ~P
Management System.
The information contained in each VP State Block
thereby defines the curr nt state of the asociated VP.
A Process is loaded in~o CS 10110 by building a
primitive access record and loading-this access record
into CS 10110 to appear as an already existing VP. A VP
~ is created by creating a Process Object, including
pointers to macro and secure-stack objects created for
that VP, micromachine state entries, and a pointer ~o the
user's program. CS 10110's ROS then generates Macro- and
Secure-Stack Objects with headers for that process and,
as described further below, loads protection informatio~
regarding that process' objects into Protection
Structures 10230. CS 10110's ROS then copies this
primitive machine state record into a vacant VPSB
selected by ~S 10110's VP Manager, thus binding the newly
created VP into CS 10110. At that time a ROS Initializer
procedure completes creation of the VP for example by
calling in the user's program through a compiler. The
newly creatd VP may then be executed by CS 10110.
Having briefly described VP State Blocks 10218 and
creation of a VP, CS 10110's Addressing Structures 10220
30 will be decribed next below.
~g ~ ~ 3
-134-
D. ~
As previously described, the data space acces~ible to
CS 10110 is divided into segments, or ~ontainers,
referred to as objects. I~ an embodiment of CS 10110,
the addressable da~a space of each object has a capacity
of 232 bits of information and i5 structured into 218
pages with each page containi~g 214bits of in~ormation.
Referring to FigO 106A, a schematic representation o
CS 10110 ~ 5 addressing structure is shown. Each object
created for use in, or by operation of, a CS 10110 is
permanently assigned a uni~ue identifier ~UID). An
obJect's UID allows an object to be uniquely identified
and located at-any future point in time. Each UID is an
80 bit number~ so that the total addressable space of all
CS 10110's includes 28 objects wherein each object may
contain up to 232 bits o~ information. As indicated in
Fig. 106, each 80 bit UID is comprised of 32 bits of
Logical Allocation Unit Identifier tLAUID) and 48 bits of
Object Serial Number (OS~). LAUIDs are associated with
individual CS 10110 systems. LA~IDs identi~y the
particular CS 10110 system generating a particular
obje~t. Each LAUID is comprised o~ a Logical Allocation
25 Unit Group Number (LAUGN) and a Logical Allocation Unit
Serial Number (LAUSN). LAUG~s are assigned to individual
CS 10110 systems and may be guaranteed to be uni~ue to a
- ;
~9 ~ 6 3
-135-
particular system. ~ particular system may, however, be
assigned more than one LAUGN so that there may be a time
varying mapping between LAUGNs and CS 10110 systems.
LAUSNs are assigned within a particular system and, while
LAU5Ns may be unique within a par~icular system, LAUSNs
need not be unique between sys~ems ~nd need not map onto
the physical structure of a particular system.
OS~s are associated with indiv dual objects created
by an LAU and are genPrated by an ~rchitectural Clock in
each CS 10110. Architectural clock i5 defined as a 64
bit ~inary number representing increasing time~ Least
significant bit of architectural clock represents
increments of 600 picosecondst and most significant bit
represents increments of 127 years. In the present
embodiment of CS 10110, certain most significant and
least significant bits of architectural clock time are
disregarded as generally not required prac~iceO Time
indicated by architectural clock is measured relative to
an arbitrary, fixed point in time. This point in time is
- 20 the same for all CS 10110s which will ever be
constructedO All CS 10110s in existence will therefore
indicate the same architectural clock time and all UIDs
generated will have a common basis. The use of an
architectural clock for generation of OSNs is
advantageous in that it avoids the possibility of
accidental duplication of OSNs i~ a CSC 10110 fails and
is subsequently reinitiated.
i~7~063
-~36-
As stated above, each ob~ect generated by or for use
in a CS 10110 is uniquely identified by its associated
UID. ~y appending Offset (O) and Length (L) information
to an object's UID, a UID logical addres is generated
5 whi~h may be used to locate particular segme~ts of data
residing in a particular objectO As indicted in Fig.
106, O and L fields of a UID logical address are each 32
bits~ O and L fields can therefore indicate any
particular bit, out of 232 lbits, in an object and thus
10 allow bit granular addressing of information in objectsO
As indicated in Fig. 106 and as previously described,
each object active in CS 10110 is assigned a shor~
temporary unique identifier valid only within JP 10114
and referred to as an Active Object Number (AON~.
15 Because fewer objects may be active in a CS 10110 than
may exist in a CS 10110's address space, AO~'s are, in
the present embodiment of CS 10110, 14 bits in length. A
particular CS 10110 may therefore contain up to 214
active objects. An object's AON is used within JP 10114
in place of that object's UID~ For example, as discussed
above with reference to process structures 10210, a
procedure's FP points to start o~ that procedure's frame
on its process' MAS. When that FP is residing in SS
10336, it is expressed as a UID. When that procedure is
25 to be executed, FP is transferred from SS 10336 to ABR's
10364 and is translated into the corresponding AON.
Similarly, when that procedure is stacked, FP is returned
to SS 10336 and in doing so is translated into the
30 corresponding UID. Again, a particular data segment in
~ `~
il~i'9~3
`137-
an object may be addressed by means of an AON logical
address comprising the object's AON plus associated 32
bit Ofset ~O) and Length ~L) fields.
Each operand appearing in a process i5 assigned a
5 Name and all references to a process's operands are
through those assigned Names. As indica~ed in Fig. 106B,
in the present embodiment o~ CS 10110 each Name is an 8,
12, or 16 bit number. All Names within a particular
process will be of the same length. As will be described
in a following discussion, Names appearing during
execution of a process may be resolved, through a
procedure's Name Table 10350 or through Name Cache 10226,
to an AON logical address. As described below, an AON
logical address corresponding to an operand Name may then
15 be evaluated to a MEM 10112 physical address to locate
the operand re~erred to.
The evaluation of AO~ logical addresses to ME~ 10112
physical addresses is represented in Fig. 10~C. An AON
logical address's L ~ield is not involved in evaluation
of an AON logical address to a physical address and, for
purposes of clarity of presentatio~, is therefore no~
represented in FigO 106C. AON logical address L field is
to be understood to be appended to the addresses
represented in the various steps of the evaluation
25 procedure shown in Fig. 106C.
As described above, objects are 232 bits structured
into 2 18 pages with each page containing a 214 bits o~
79~3
-1 3 8
data~ MEM 10112 is similarly physically structured into
frames with, in the present embodîment of CS 10110, each
frame containing 214 bits of da~a. In other embodiments
of CS 1011d, both pages and frames may be of different
5 sizes but the translation o~ AON logical addresses to ME~
10112 physical addresses will be similar to that
described momentarily.
~ An AO~ logical address O field was previously
described as a 32 bit num~er representing the start,
10 relative to start of the object, of the addressed data
segment within the object. The 18 mo~t significant bits
of O ~ield re~resent the number (P) of the page within
the object upon which.the irst bit of th~ addressed data
occurs. The 14 least significant bits of O field
15 represent the offset (Op), rela~ive to the start of the
page, within that page of the firs~ bit of the addressed
data~ AON logical address O field may thereforet as
indicated in Fig. 106C, be divided into an 18 bit page
~P~ field ~nd a 14 bit offset within page (~ ) ~ield.
20 Since, as described abover MEM 1011Z physical frame size
is equal to object page size, AON logical address Op
field may be used directly as an offset within frame ~O~)
field of the physical address. As will be described
below, an AON lo~ical address AO~ and P ields may then
25 b~ related to the frame number (~N) of the MEM 10112
frame in which that page resides, through Addressing
Mechanisms 10220.
~79
-139-
~aving briefly described the relationships between
UIDs, UID Logical Addresses, ~ames, AON~, AON Log~cal
Addresses, and ~E~ 10112 Physical Addresses, Addressing
Mechanisms 10220 will be described next belowO
2. ~
Referring to Fig. 107, a schematic rapresentation of
Computer System 10110's Addressing Mechanisms 10220 is
shown. As previously described, Addressing MechanismS
10220 comprise UID/AON Tables 10222~ ~emory Mana~ement
lO Tables 10224, Name Cache 10226, and Address Translation
Unit 10228.
UID/AON Tables 10222 relate each ob~ect's UID to its
assigned AON and include AOT Hash Table (AOT~T) 10710,
Active Object Table (AO~) 10712, and Active Object
15 TabIe Annex (AOTA) 10714.
. An AO~ corresponding to a particular UID is
determined through AOT~T 10710. The UID is hashed to
provide a UID index into AOTHT 10710, which then provides
the corresponding AON. AOTHT 10710 is effectively an
20 acceleration mechanism of AOT 10712 to, as just
describedt provide rapid translat~on o~ UIDs to AONs.
AONs are used as indexes into AOT 10712, which provides a
corresponding AO~ En~ry (AO~E). An AO~E as described in
following detailed discussions of CS 10110, includes,
25 among other information, the UID corresponding to ~he AON
indexing the AO~E. In addition to providing translation
9 ~6 3
~140-
between AONs and UIDs, the UID of an AOTE may be compared
to an original UID to determine the correctness of an AON
from AOTHT 10710.
Associated with AOT 10712 is AOTA 10714. AOTA 10714
is an extansion o AOT 10712 and contains certai~
information pertaining to active objects, for example the
domain of execution of each active procedure object.
Having briefly described CS 10110ls meehanism for
relating UIDs and AONsr CS 10110's mechanism for
resolving operand Names to AO~ logical addresses will be
described ne~t below.
3. ~
Referring first to Fig. 103 t each procedure object in
a VP~ for example ROSPO 10318 in VP 10310, was described
15 as containing a ~ame Table (NT) 10350. Each NT 10350
contains a Name Table Entry (NTE) for each operand whose
Name appears its procedure. Each NTE contains a
description o~ how to resolve the corresponding Name to
an AO~ Logical Address, including fetch mode information,
20 type of data referred to by that Name, and length of the
data segment referred toO
Referring to Fig. 108, a representation of an NTE is
shown. As indicated, this NTE contains seven information
fields: Flag, Base (B), Predisplacement (PR), Length (L),
25 Displacement (D), Index (I), and Inter-element Spacing
(IES). Flag Field, in part, contains information
describing how the remaining field of the NTE are to be
interpreted, type of information referred to by the NTE,
and how that information is to handled when fetched ~rom
75~i3
-141-
ME~ 10112. L Field, as previously described, indicates
length~ or number of bits in, the data segment.
Function~ o~ the other NTE fields will be described
during the following discussions.
In a present em~odiment of CS 10110, there are five
types of ~TE: ~1) base ~B) is not a ~ame, address
resolution is not indirect; ~2) B is not a ~ame, address
resolution is indirect; ~3) B is a Name, address
resolution is indirect; (4) B is a Name, address
10 resolution is indirect. A fifth type is an NTE selecting
a particular element from an array of elements. These
five types of NTE and ~heir resolution will be described
below, in the order mentioned.
In the first type, B is not a ~lame and address
15 resolution is not indirect, B Field specifies an ABR
10364 containing an AON plus offset (AON/0) Pointer. The
con~ents of D Field are added to the O Field of this
pointer, and the result is the AON Logical Address of the
operand. In the second type, B is not a Name and address
20 resolution is indirect, 8 Field again specifies an ABR
10364 containing an A~/O pointer. The contents of PR
Field are added to the O Field of the AON/O pointer to
provide an AON Logical Address o~ a Base Pointer. The
Base Pointer ~ON Loyical Address is evaluated~ as
2S described below, and the Base Pointer fetched from MEM
10112. The contents of D Field are added to the O Field
of the Base Pointer and the result is the AON Logical
Address of the operand.
79 ~6 3
-142-
NTE types 3 and 4 correspond, respe~tively to NTE
types l and 2 and are resolved in the same manner except
that B Field contains a Name. The B Field ~ame is
resolved through ano~her ~E to obtain an AON/O pointer
5 which is used in place of the A~ 10364 pointers referred
to in discussion of types 1 and 2.
The fi~th type of NTE is used in references to
el~ments of an array. These array NTEs are resolved in
the same manner as ~TE types 1 t~rough 4 above to pro~ide
10 an AO~ Logical Address of the start of the array. I and
IES Fields provide additional information to locate a
particular element in the array. I Field is always ~ame
which is resolved to obtain an operand value representing
the particular element in the array. IES Field provides
information regarding spacing between elements of ~he
array, that is the number of bits between ad~acent
element of the array. IES Field may contain the a~tual
IES value, or it may contain a Name which is resolved to
an AON Logical Address leading to the inter-element
spacing value. The I and IES values, obtained by
resolving the I and IES Fields as just describ~d, are
multiplied together ~o determine the offse~, relative to
the start of the array, of the particular elemen~
referred to ~y the MTE. ~his within array offset is
added to the O Field of the AON Logical Address of the
start of the array to provide the AO~ Logical Address of
the element.
6 3
-143-
In the current embodiment of CS 10110, certain NTE
fields, for example B, D, and ~lag fields, always con~ain
literals. Certain other fields, for example, IES, D,
PRE, and L fields, may contain either literals or names
5 to be resolved~ Yet other fields, for example I field,
always contain names which must be resolved.
Pas~ing of arguments from a caIling procedure to. a
called procedure has been previously discussed with
reference to Virtual Processes 10212 bove, and more
specifically with regard to MAS's 10328 to 10334 o~ VP
10310. Passing of arguments is accomplished through the
calling and called procedure's Name Tables 10350. In
illustration, a procedure W(a,b,c) may wi~h to pass
arguments a, ~, and c to procedure X(u,v,w), where
arguments, v and w correspond to arguments a, b, and c.
At compilation, NTEs are generated for arguments a, b,
and c in ProcPdure W's procedure object, and ~TEs are
generated ~or arguments u, v and w in Procedure X's
procedure object. Procedure X's ~TEs ~or u, v, and w are
20 constructed to resolve to point to pointers in Linkage
Pointer Block 10416 of Procedure X's ~rame 10412 in MAS.
To pass arguments a, b, and c ~rom Procedure W ~o
Pr~cedura X, the NTEs of arguments a, b, and c are
resolved t AON Logical Addresses (i~e., AON/O formj.
25 Arguments a, b, and c's AON Logical Addresses are khen
translated to corresponding UID addresses which are
placed in Procedure X's Lin~age Pointer Block 10416 at
those places pointed to by Procedure X's NTEs for u, v,
and w. When Procedure X is executed, the resolution of
.. ;
79(~6~
-144-
Procedure X's NTEs for u, v, and w will be resolved to
locate the pointers, in Procedure X's Linkage Pointer
Block 10416 to arguments a, b, and c. When arguments are
passed in this manner, the data type and length
information are obtained from the called proce~ure's
NTEs, rather than the calling procedure's ~TEs. This
allows the calling procedure to pass only a portion of,
for example, arguments a, b, or c, to the called
procedure and thus may be regarded as a feature of CS
10 10110's protection mechanisms.
~ aving briefly described resolution of Names to
AON/Offset addresses, and having previously described
translation of UID addresses to AON addresses, the
evaluation of AON addresses to ~EM 10112 physical
15 addresses will be described next below.
4.
Referring again to Fig. 107, a partial schematic
representation of CS 101101 S ~emory Management Table
20 10224 is shown. Memory ~ash Table (M~) 10716 and Memory
Frame Table (MFT) 10718 are concerned with ~ranslation of
AON addresses into ME~_10112 physical addresses and will
be discussed ~irst. Working Set Matrix (WSM) 10720 and
Virtual Memory Manager Request Queue (VMMRQ) 10722 are
25 concerned with management of MEM 10112's available
physical address base and will be discussed second.
Active Object Request Queue (AORQ) 10728 and Logical
~1~79~63
-145--
Allocation Unit Directory (LAUD) 10730 are concerned with
locating inactive objects and management of which objects
are active in CS 10110 and will be discussed las~.
Translation of AO~O Logical Addresses to MEM 10112
physical addresses was previously discussed with
reference to Fig. 106C. As stated in that discussion,
objects are divided into pages. Correspondingly, the
AON/O Lo~ical Address' O Field is divided into an 18 bit
page number (P) Field and a 14 bit offset within a page
(Op) Field. MEM 10112 i5 structured into frames, each of
which in the present embodiment of CS 10110 is equal to a
page of an object. An AON/O address' Op Field may
therefore be used directly as an offse~ within frame (Of)
of the corresponding physical addresc. The AON and P
15 fields of an AO~ address must, however, be translated
into a MEM 10112 frame represented by a corresponding
Frame Number (FN).
Referring now to Fig. 107, an AO~ address' AON and P
Fields are "hashed" to generate an M~T index which is ~
20 used as an index into M~T 10716. Briefly, ~hashing" is a
method of indexing, or locating, information in a table
wherein indexes to the information are generated from the
information itself through a "hashing function". A
hashing function maps each piece of information to the
25 corresponding index generated from it through the ha~hing
function. M~T 10716 then provides the corresponding FN
of the MEM 10112 frame in which that page is stored. FNs
are used as indexes into MFG 10718, which contains, for
each FN, an entry describing the page stored in that
30 frame. ~his information includes the AON and P of the
.J
-146-
page stored in that MEM 10112 frame. An FN from ~T
10716 may therefore be used as an index into MFT 10718
and the resulting AON/P of ~FT 10718 compared to the
original AON/P to confirm the correctness of the FN
obtained from M~T 10716. M~T 10716 is an effectively
acceleration mechani~m o~ ~FT 10718 to provide rapid
~ranslation of AON address to ME~ 10112 physical
addresses.
MFT 10718 also stores "used" and "modified"
information for each page in ~EM 10112. This information
indicates which page frames stored therein have been used
and which have been modified~ This information is used
by CS 10110 in determining which frames may be deleted
from MEM 10112, or are free, when pages are to be wri~ten
into MEM 10112 from backing store (ED 10124). For
example, if a page's modified bit indicates that that
page has not been written into, it is not necessary to
write that page back into backing store when it is
deleted from ME~ 10112; instead, that page may be simply
erased.
Referring finally to ATU 10228, ATU 10228 is an
accelera~ion mechanism for M~T 10716. AON/O addresses
are used directly, without hashing, as indexes into ATU
10228 and ATU 10228 correctly provides corresponding FN
and O outputs. A CS 10110 mechanism, described in a
following detailed discussion of CS 10110 operation,
9~3
-l 47--
continually updates the contents o ATU 10228 so that ATU ` --~
10228 contain the FN's and Op (Of ) of the pages most
frequently referenced by the curren~ proceæs. If ATU
10228 does not contain a corresponding entry ~or a given
5 AON input, an ATU fault occurs and the FN and O
informa~ion may be obtained directly from MHT 10716.
Referring now to WS~ 10720 and VMMRQ 10722, a~
previously stated these mechanisms are concerned with the
management of MEM 10112's available address space. For
10 example, if M~T 1071~ and ~F~ 10718 do not contain an
entry for a page referenced by ~he current procedure, an
M~T/~IFT fault occurs and the reference pase must be
etched from backing store (ED 10124) and read into ME~
10112. W~M 10720 contains an entry for each page
lS resident in MEM I0112. These entries are accessed by
indexes comprising the Virtual Processor Number (VPN) of
the virtual process making a page reference and the P of
the page being referenced. Each WS~ 10720 entry contains
2 bits stating whether the particular page is part o~ a
20 VPIs working set, that is, used by that VP, and whether
that page has been re~erenced by that VP. This
information, together with the information contained in
that MFT 10718 entries described above, is used by CS
lOllO's Virtual Memory ~anager (VMM) in transferring
25 page~ into and out o MEM 10112.
CS lOllO's VMM maintains VM~RQ 10722, which is used
by YMM to control transfer of pages into and out of MEM
10112. VMMRQ 10722 includes Virtual Memory Request
Counter (VMRC) 10724 and a Queue of Virtual Memory
.
~79
-148-
Request Entries (VMREs) 10726~ As will be discussed
momentarily, VMRC 10724 tracks the number of currently
outstanding re~uest ~or pages. Each VMRE 10726 describes
a particular page which has been requested. Upon
5 occurrence o~ a M~T/~FT (or page) fault, VMR~ 10724 i~
incremented, which initiates operation of CS 10110's VM~,
and a VMRE 10726 is placed in the queue. Each V~RE 10726
comprises the VPN of the pro~ess requesting the page and
the AON/O of the page reques~ed. At this time, the VP
10 making the request is swapped out of JP 10114 and another
VP bound to JP 10114. VMM allocates MEM 10112 frame to
contain the requested pa~e, using the previously
described inormation in ~FT 10718 and WSM 10720 to
select this frame. In doing so, VMM may discard a page
currently resident in MEM 10112 for example, on the basis
of being the oldest page, an unused page, or an
unmodi~ied pa~e which does not have to be written back
into backing store. V~M then requests an I/O operation
to transfer the requested page into the frame selected by
20 the VM~. While the I/O operation is proceeding, VM~
generates new entries in ~T 10716 and MFT 10718 for the
requested page, cleans the frame in ~EM 10112 which is to
be occupied by that page, and suspends operation. IOS
10116 will proceed to execute the I/O operation and
25 writes the requested page directly into MEM 10112 in the
frame specified by VMM. IOS 10116 then notifies CS
10110's VMM that the page now resides in memory and can
be referenced. At some later time, that VP requesting
that page will resume execution and repeat that
~79 ~ 3
-149-
reference. Going first to ATU 10228, that VP will take
an ATU 10228 ~ault since VP 10212 has not yet been
updated to contain that page~ The VP will then go to ~T
10716 and MFT 10718 for the required information and,
concurrently, WSM 10720 and ATU 10228 will be updatPd.
Tn regard to the above operations, each VP active in
CS 10110 is assigned a Page Fault Frequency Time Factor
(PFFT) which is used by CS 10110's VMM to adjust that
VP's working set so that the interval between successive
10 page faults for that VP lies in an optimum time range.
This assists in ensuring CS 10110's VMM is operating most
efficiently and allows CS 10110's VMM to be tuned as
required.
The above discussions have assumed that the page
15 being referenced, whether from a UID/O address~ an AON/O
address, or a ~ame, is resident in an object active in CS
10110. While an object need not have a page in MEM 10112
to be active, the objec~ must be active to have a page in
ME~ 10112. A VP, however, may reference a page in an
20 object not active in CS 10110. I~ such a reference is
made, the object must be made active in CS 10110 before
the page can be brought into MEM 10112. The result is an
operation similar to the page fault operation described
above. CS 10110 maintains an Active Object Manager
(AOM), including Active Object Request Queue (AORQ)
10728, which are similar in operation to CS 10110's VM~
and VMMRQ 10722~ CS 10110's AOM and AORQ 10728 operate
in conjunctian with AOT~T 10710 and AOT 10712 to locate
inactive objects and make them active by assigning them
9(~63
--150--
AON's and generating entries for them in AOT~T 10710, AOT
10712, and AOTA 10714.
Before a particular object can be made acti~e in CS
10110, it must first be located in backing store ~ED
5 10124)~ All objects on backing store are located through
a Logical Allocation Unit Directory (LAUD) 10730, which
is resident in backing store. An LAU~ 10730 contains
entries for each object accessible to thP particular CS
10110. Each LAUD 10730 entry contains the information
10 necessary to generate an AOT 10712 entry for that
objec~ An LAUD 10730 is accessed through a UID/O
address contained in CS 10110's V~. A reference to an
LAUD 1~730 resuIts in MEM 10112 frames being assigned to
that LAUD 10730, and LAUD 10730 being transferred into
15 MEM 10112. If an LAUD 10730 entry exists for the
referenced inactive objec~, the LAUD 10730 en~ry is
transferred into AOT 10712. At the next reference to a
page in that objectr AOT 10712 will provide the AON for
that object but, because the page has not yet b~en
20 transferred into MEM 10112, a page fault will occur.
This page fault will be handled in the manner described
abo~e and the referenced page transferred into ~EM 1011~.
~ aving brie~ly described the structure and operation
o~ CS 10110's Addressing Structure, including the
25 relationship between UIDs, Names, AONs, and Physical
Addresses and the mechanisms by which CS 10110 manages
9 ~ 3
-151-
the available address space of ME~ 10112, CS 10110's
protection structures will be described next below.
E.
Referring to Fig. 109, a schematic representation o~
5 Protection Mechanisms 10230 is shown. Protection Tables
10232 include Active Primitive Access ~a~rix (APAM)
10910, Active Subject Number Hash Table (ASN~T) 1091~,
and Active Subject Table (AST) 10914~ Those por~ions of
Protection ~echanism 10230 resident in FU 10120 include
lQ ASN Register 10916 and Protection Cache (PC) 10234.
As previously discussed, access rights to objects are
arbitrated on the basis of subjects. A subject has been
defined as a particular combination of a Principle,
Process, and Domain (PPD), each of which is identified by
15 a corresponding UID. Each object has associated with it
an Access Control List (ACL) 10918 containing an ACL
Entry (ACLE) for each subject having access rights to
that object.
When an object becomes active in CS 10110 (i.e., is
20 assigned an AON) each ACLE in that object's ACL 10918 is
written into APAM 10910. Concurrently, each subjec~
having access rights ~o that object, and for which there
is an ACLE in that objec~'s ACL 10918, is assigned an
Active Subject Number (AS~). These ASNs are written into
25 ASNHT 10912 and their corresponding PPDs are written into
AST 10914. Subsequently, the ASN of any subject
re~uesting access to that object is obtained by hashing
~lt~9~63
-152-
the PPD of that subject to obtain a PPD index into ASN~T
10912. ASNHT 10912 will in turn provide a corresponding
ASN. An ASN may be used as an index into AST 10914~ AST
10914 will provide the corresponding PPD, which may be
5 compared to an original PPD to confirm the accuracy of
the ASN.
As described above, APAM 10910 contains a~ ACL 10918
for each object active in CS lOllOo The access rights of
any particular active subject to a particular active
10 object are determined by using that subject's AS~ and
that object's AON as indexes into APAM 10910O APAM 10910
in turn provides a 4 bit output defining whether that
subiect has Read (R) Write (W) or Execu~e (E) rights with
respect to that object, and whether that particular entry
is Valid (V).
ASN Register 10916 and PC 10234 are effectively
acceleration mechanisms of Protection Tables 10232. ASN
Register 10916 stores the ASN o~ a currently active
subiect while PC 10234 s~ores certain access right
20 information ~or objects being used by the current
process. PC 10234 entries are indexed by ASNs from ASN
register 10916 and by a mode input from JP 10114. Mode
input defines whether the current procedure intends to
read, write, or execute with respect to a par~icular
25 objec~ having an entry in PC 10234~ Upon receiving ASN
and mode inputs, PC 10234 provides a go/nogo output
indicating whether that subject has the access rights
9 ~ ~ 3
-153-
required to execute the intended operation with respect
to that object.
In addition to the above mechanism, each procedure to
which arguments may be passed in a cross-domain call has
5 associated with it.an Access Information Array (AIA)
10352, as discussed with reference to Vir~ual ProcesseS
10212. A procedure's AIA 10352 states what access rights
a calling procedure (subject) must have to a particular
object (argument) before the called procedure can operate
10 on the passed argument. CS lOllO's protection mechanisms
compare the calling procedures access rights to the
rights required by the called procedure. This insures
the calling procedure may not ask a called procedure to
do what the calling procedure is not allowed to do.
15 Effectively, a calling procedura can pass to a called
procedure only the access rights held by the calling
procedure.
Finally, PC 10234, APAM 10910~ or AST 10914 faults
(i.e., misses) are handled in the same manner as
20 described above with reference to page faults in
discussion o~ CS lOllO's Addressing Mechanisms 10220. As
such, the handling of protection misses will not be
discussed further at this point.
~aving briefly described struc~ure and operation of
25 CS lOllO's Protection Mechanisms 10230, CS lOllO's Micro-
Instruction Mechanisms 10236 will be described next
below.
-
79 ~ 3
-154-
~. ~ (Fig. 110)
As previously described, CS 10110 is a multiple
language machine. Each program written in a high level
user language is compiled into a corresponding S-Language
5 program containing instructions expressed as SINs. CS
10110 provides a set, or dialect, of microcode
instructions, referred to as S-Interpreters (SIN~s) for
each S-Language. SI~Ts interpret S~Ns and provide
corresponding se~uences of microinstructions ~or detailed
10 control of CS 10110.
Referring to Fig. 110, a partial schematic
representation of CS lOllO's Micro-Instruction Mechanisms
10236 is shown. At system initialization all CS 10110
microcode, including SIWTs and all machine assist
15 microcode, is transerred from backing store to ~icro-
Code Control Store (mCCS) 10238 in ~E~ 10112. The Micro-
Code is then transferred from mCCS 10238 to FU Micro-Code
Structure (FUmC) 10240 and EU ~icro-Code Structure (EUmC)
10242. EUmC 10242 is similar in s~ruc~ure and operation
20 to FUmC 10240 and thus will be described in following
detailed descriptions o~ CS lOllO's structure and
operation. Similarly, CS 10110 machine assist microcode
will be described in following detailed discussionsO The
present discussion will concern CS lOllO's S-Interpreter
25 me~hanisms.
CS lOllO's S-Interpreters (SINTs) are loaded into S-
Interpret Ta~le (SITT) 11012, which is represented in
~ig. 110 as containing S-Interpreters 1 to N. Each SIT
f~
79~63
-155-
contains one or more sequences of micro-code; each
sequence of microcode corresponds to a particular SIN in
that S-Language dialect. S-Interpreter Dispatch Table
(SDT) 11010 contains S-Interpreter Dispatchers (S~s) 1 to
N. There is one SD for each SINT in SIT~ 11012, and thus
a SD for each S-Language dialect. Each SD comprises a
set of pointersO Each pointer in a particular SD
corresponds to a particular SIN of that SD's dialect and
points to the corresponding sequence of microinstructions
10 for interpreting that SI~ in that dialect's 9IT in SITT
11012. In illustration, as previously discussed when a
parkicular procedure is being execu~ed the SIP for that
procedure is transferred into one of mCR's 10366. That
SIP points to the start of the SD for the SIT which is to
15 be used to interpret the SINs of that procedure. In Fig.
110, the SIP in mCRs 10366 is shown as pointing to the
start o SD2. Each S-Op appearing during execution of
that procedure is an offset, relative to the start of the
selected S~, pointing to a corresponding SD pointer.
20 That SD pointer in turn points to the correspondin~
sequenc~ of microinstructions for interprPting that SIN
in the corresponding SIT in SITT 11012~ ~5 will be
described in following discussions, once the start of a
micrccode se~uence for interpretin~ an SIN has been
25 selected, CS 10110 micromachine then proceeds to
sequentially call the microinstructions of that sequence
from SITT 11012 and use those microinstructions to
control operation o~ CS 10110.
-156-
G. ~mmaxv o~-~e~t~in=5=~*~-~e**u~eY=3~
~ he above Introductory Overview has described ~he
overall structure and operation and certain ~eatures of
CS 101, that is, CS 10110. The above Introduction has
further described the structure and operation and further
features of CS 10110 and, in particular, the physical
implementation and operation of CS 10110's information,
control, a~d addressing mechanism~. Certain of these CS
10110 ~eatures are summarized next below to brie1y state
the basic concepts of these features as implemented in C5
10110. In addition, possible alternate embodiments of
certain of these concepts are described.
First, CS 10110 is comprised of a plurality of
independently operating processors, each processor having
a separate microinstruction control~ In the present
embodiment o~ CS 10110, these processors include FU
: 10120, EU 10I22, MEM 10112 and IOS 10116. Other such
independently operating processors, for example, special
20 arithmetic processors such as an array processor, or
multiple FU 10120'sr may be added to the present CS
10110 .
.In this regard, MEM 10112 is a multiport processor
having one or more separate and independent ports to each
25 processor in CS 10110. All communications between CS
10110's processors are through MEM 10112, so that MEM
10112 operates as the central communications node o~ CS
~79C~3
-157-
10110, as well as performing memory operations. Further
separate and independent ports may be added to ~EM 10112
as further processors are added to CS lOllOo CS 10110
may therefore be described as comprised of a plurality of
separate, independent processors, each having a Qeparate
microinstruction control and haviny a separate and
independent por~ to a central communications and memory
node which in itself is an independent processor having a
separate and independent microinstruction control. ~g
10 will be further described in a ~ollowing detailed
description of ~EM 10112, ME~ 10112 itself is comprised
of a plurality of independently operating processors,
each performing memory related operations and each having
a separate microinstruction control. Coordination of
operations between CS lOllO's processors is achieved by
passing "messages" between the processors, for example,
SOP's and descriptors.
CS lOllO's addressing mechanisms are based, first,
upon UID addressing of objects~ That is, all information
20 generated for use in or by operation of a CS 10110, for
example, data and procedures, is structured into objects
and each object is assigned a permanent UID. Each UID is
unique within a particular CS 10110 and between all CS
lOllO's and is permanently associated with a particular
25 object. The use of UID addressing provides a permanent,
unique addressing means which is common to all CS
lOllO's, and to other computer sys~ems using CS lOllO's
UID addressing.
9~3
-158-
Effectively, UID addressing means that the address
(or memory~ space of a particular CS 10110 includes ~he
address space of all systems, for example disc drives or
other CS 10110sj to which that partic~lar CS 10110 has
5 access. UID addressing allows any process in any CS
10110 to obtain access to any object in any CS 10110 to
which it has physical acces~ r for example, another CS
1~110 on the other side of the world. This access is
constrained only by CS 10110's protection mechanismO In
10 al~ernate embodim~nts of CS 10110, certain UIDs may be
set aside for use only within a particular CS 10110 and
may be uni~ue only within that particular CS lOllOo
These reserved UIDs would, however, be a limited group
known to all CS 10110 systems as not having uniqueness
15 between systems, so that the unique object addressing
capability of CS 10110's UID addressing is preserved.
As previously stated, AONs and physical descriptors
are presently used for addressing within a CS 10110,
effectively as shortened UIDs. In alternate embodiments
20 of CS 10110, other forms of AONs may be used, or AONs may
be discarded entirely and UIDs used for addressing within
as well as between CS 10110s.
CS 10110's addressing mechanisms are also based upon
the use of descriptors within and between CS 10110so
25 Each descriptor includes an AON or UID field to identify
a particular objectr an offset field to specify a bit
granular offset within the object, and a length field to
spe~ify a particular number of bits beginning at the
specified offset. Descriptors may also include a type,
30 or format field identifying the particular format of the
~79~ ~ 3
-159-
data referred to by the descriptor. Physical descriptors
are used for addressing ME~ 10112 and, in this ca~e, the
AON or UID field is replaced by a frame number field
referring to a physical location in ME~ 10112.
As stated above, descriptors are used for addressing
within and between the separate, independent processors
(F~ 10120, E~ 10122, MEM 10112, and IOS 10116) comprising
CS 10110, thereby providing commonl system wide bit
granular addressing which includes format information.
In particular, MEM 10112 responds to the type information
fields of descriptors by performing formatting operations
to provide requestors with data in the format specified
by the requestor in the descriptor. ME~ 10112 also
accepts data in a format specified in a descriptor and
reformats that data into a format most efficiently used
by ME~l 10112 to store the data.
As previously described, all operands are referred to
in CS 10110 by ~ames wherein all Names within a
particular S-Language dialect are of a uniform, fixed
size and format. A R value specifying Name size is
pro~ided to FU 10120, at each change in S-Language
dialect, and is used by ~U 10120 in parsing ~ames from
the instruction stre~m. In an alterna~e embodiment o~ CS
10110, all Names are the same size in all S-~anguage
dialec~s, so that R values, and the associated circuitry
in FU 10120's parser, are not required.
~7~ ~ 6 3
-160-
' `'~!~'~ ' '' 'i
Finally, in descriptions of CS lOllO's use o~ SOPs,
FU 10120's microinstruc~ion circuitry was described as
storing on~ or more S-Interpreters S-Interpreters are
set~ of sequences .of microinstructions for interpreting
5 the SOP~ of various S-Language dialects and providing
corresponding se~uences of microinqtxuctions to control
. C8 10110. In an alternate embodiment of. CS 10110, these
S-Interpreters tSITT 11012) would be s~ored in MS~
- 10112. FU 10120 would receive SOPs from the instruction
stream and, using one or more S-Interpreter ~ase Pointers
lthat is, architectural base pointers pointing to the
SITT 11012 in ME~ 10112), address the SITT 11012 stored
in MEM 10112. ~E~ 10112 would respond by providing, ~rom
the SITT 11012 in MEM 10112, sequences of
15 microinstructions to be used directly in controlling CS
10110. Alternately, the SI~T 11012 in MEM 10112 could
provide conventional instructions usable by a
conventional CPU, for example, Fortran or machine
language instructions. This, for example, would allow ~U
~ 10120 to be replaced by a conventional CPU, such as a
Data General Corporation Eclipse~.
Having briefly summarized certain features o~ CS
10110, and alternate embodiments of certain of these
featurest the structure and operation of CS 10110 will be
described in detail below.
9~63
-161-
2.
~=~
Having previously described the overall structure and
operation of CS 10110, the structure and operation of CS
5 10110's major subsystems will next be individually
described in further detail. As previously discussed, CS
10110's major subsystems are, in the order in which they
will b~ described, MEM 10112, FU 10120, EU 101~2, IOS
10116, and DP 10118. Individual block diagrams of MEM
10 10112, FU 10120, E~ 10122, IOS 10116, and DP 10118 are
shown in, respectively, Figures 201 through 205. Figures
201 through 205 may be assembled as shown in Fig. 206 to
construct a more detailed block diagram of CS 10110
corre~ponding to that shown in Fig. 101. For the
LS purposes of the following descriptions, it is assumed
that FigsO 201 through 205 have been assembled as shown
in Fig. 206 to construct such a block diagram. Further
diagrams will be presented in following descriptions as
required to convey structure and operation of CS 10110 to
20 one of ordinary skill in the art.
As previously described, MEM 10112 is an intelligent,
priortizing memory having separate and independent ports
MIO 10128 and MJP 10140 to, respectively, IOS 10116 and
JP 10114. MEM 1~112 is shared by and is accessible to
25 bot~ JP 10114 and IOS 10116 and is the primary memory of
CS 10110. In addition, MEM 10112 is the primary path for
information transferred between the external world
(through IOS 10116) and JP 10114.
91)63
-162~
As will be described further below, ME~ 10112 is a
two-level memory providing fast access to data stored
therein. ME~ 10112 first level is comprised of a large
set oE random access arrays and ~EM 10112 second level is
5 comprised o~ a high speed cache whose operation is
generally transparen~ to memory users, that is JP 10114
and IOS 10116. Information stored in ~EM 10112, in
either level, appears to be bit addressable to both JP
10114 and IOS 10116. ~n ~ddition~ ~EM 1011~ presents
10 simple interaces to both JP 10114 and IOS 10116. Due to
a high degree of pipe lining (concurrent and overlapping
memory operations) ME~ 10112 interfaces to both JP 10114
and IOS iO116 appear as if each ~P 10114 and IOS 10116
have ~ull access to MEM 10112. This feature allows data
15 transfer rates of up to, for example, 63.6 megabytes per
second from ~EM 10112 and 50 megabytes per second to ME~
10112.
In the ~ollowing descriptions, certain terminology
used on those descriptions will be int~oduced first,
followed by description of ~E~ 10112 physical
organization. Then MEM 10112 port structures will be
described, ollowed by descriptions of ME~ 10112's
control organization and control flow. Next, ME~ 10112's
inter~aces to JP 10114 and IOS 10116 will be described.
~ollowing these overall descriptions the major logical
structures of MEM 10112 will be individually described,
starting at MEM 10112's inter~aces to JP 10114 and IOS
1~79()63
-163--
10116 and proceeding inwardly to ~ 10112's first (or
bulk) level of data stored. Finally, certain features of
MEM 10112 microcode con~rol structure will be described.
A.
a~ ak~E~
Certain terms are used throughout the following
descriptions and are defined here below for reference by
the reader.
A word is 32 bits of data
A byte is 8 bits of data
A block is 128 bits of data ~that is, 4 words).
A block is always aligned on a block boundary, that is
the low order 7 bits of logical or physical address are
zero (see Chapter 1, Sections A.f and D. Descriptions of
15 CS 10110 Addressing).
The term aligned refers to the starting bit address
of a data item relative to certain address boundaries. A
starting bit address is block aligned when the low order
? bits of starting bit address are equal to zero, that is
20 the starting bit address falls on a boundary between
adjacent blocks. A word align starting bit address means
that the low order 5 bits of starting bit address are
zero, the starting bit address points to a boundary
batween adjacent words. A byte aligned starting bit
25 address means that the low order 3 bits of starting bit
address are zero, the starting bit address points to a
boundary betveen adjacent bytes.
6 3
-164-
Bit granular data has a starting bit address ~alling
within a byte, but not on a by~e boundary, or the address
is aligned on a byte boundary but the length of the data
is bit granular, that is not a multiple of 8 bits.
S b. ~
Referring ~o Fig. 201, a partial block diagram of MEM
10112 is shown. Major functional units of MEM 10112 are
Main Store Bank (~SB) 20110, including ~emory Arrays
(M~'s) 20112, Bank Controller (BC) 20114, Memory Cache
(MC) 20116, including Bypass Write File (~YF) 20118,
Field Isolation Unit (FIU) 20120, and Memory Interface
Controller (MI~) 20122.
MSB 20110 comprises MEM 10112's ~irst or bulk level
of storage. MSB 20110 may include from one to, for
example, 1~ MA 20112's. Each MA 20112 may have a storage
capacity, for example, 256 R-byte, 512 ~-byte, 1 M-byte,
or 2 M-bytes of storage capacity. As will be described
~urther below, ~A 20112's of different capacities may be
used together in MSB 20110. Each MA 20112 has a data
input connected in parallel to Write Data (WD) ~us 20124
and a data output connected in parallel to Read Data (RD)
Bus 20126. MA's 20112 also have control and address ports
connected in parallel to address and con~rol ~ADCTL).Bus
20128. In particular, Data Inputs 20124 of Memory Arrays
20112 are connected in parallel to Write Data (WD) Bus
2~126, and Data Outputs 20128 of Memory Arrays 20112 are
connec ed in parallel to Read Data (RD) ~us 201300
11~7~)63
--165--
Control Address Ports 20132 of Memory Arrays 20112 are
connected in parallel to Address and Control (ADCTL) Bus
20134.
Data Output 20136 of Bank Controller 20114 is
connected to WD Bus 20126 and Data Input 20138 of BC
20114 is connected to RD Bus 20130~ Control and Address
Port 20140 o~ BC 20114 is connected to ADCTL Bus 20134.
RC 20114's Data Input 20142 is connected to ~C 20116's
Data Output 20144 through Store Back Data (SBD) Bus
20146. BC 20114's Store Back Address Input 20148 is
connected to MC 20116 Store Back Address Output 20150
through Store Back Address (SBA~ Bus 20152. BC 20114's
Read Data Output 20154 is connected to ~C 20116' Read
Data Input 20156 through Read Data Out (RDO) Bus 20158.
BC 20I14's Control Port 20160 is connected to Memory
Control (MCNTL) Bus 20164.
MC 20116 has Output 20166 connected to MIO Bus 10131
through MIO Port 10128, and Port 20168 connected to MOD
Bus 10144 through MJ~ Port 10140. rontrol Port 20170 of
MC 20116 is connected to MCNTL Bus 20164. Input 20172 o~
BYF 20118 is connected to IO~ Bus 10130 through MIO Port
10128, and Output 20176 is connected to SBD Bus 20146
through Bypass Write In (BWI) Bus 20178.
Finally, FIU 20120 has an Output 20180 and an Input
. 25 20182 connected to, respectively, MIO 8us 10129 and IO~
Bus 10130 through ~IO PoLt 10128. Input 20184 and Port
20186 are connected to, respectively, JPD BU5 10142 and
MOD Bus 10144 through ~JP Port 10140. Control Port 20188
is connected to MC~TL Bus 20164. Referring ~inally to
MIC 20122, MIC 20122 has Control Port 20190 and Input
1~7~63
~166--
20192 connected to, respectively, IOMC BU5 10131 and IOM
Bus 10130 through MIO Port 10128. Control Port 20194 and
Input 20196 are connected, respectively, to JPMC Bus
10147 and Physical ~escriptor (~D) Bus 10146 through MJP
Port 10140. Control Port 20138 is connected to MCNTL ~us
20164.
c.
Referring first to ME~ 10112's interface to IOS
10116, this interface includes MIO Bus 101~9, IO~ Bus
10130, and IOMC Bus 10131. Read and Write Addresses and
data to be written into ~EM 10112 are transferred from
IOS 10116 to MEM 10112 through IOM Bus 10130. Data read
from ~EM 10112 is transferred to IOS 10116 through MIO
Bus 10129. IOMC 10131 is a Bi-directional Control bus
lS between MEM 10112 and IOS 10116 and, as described further
below, trans~ers control signals between ~E~ 10112 and
IOS 10116 to control transfer of data between ~E~ 10112
and IOS 10116.
~E~ 10112's interace to JP 10114 is ~JP-Port 10140
and includes JPD Bus 10142, MOD Bus 10144, PD Bus 10146,
and JPMC Bus 10147. Phy ical descriptors, that is ME~
10112 physical r ad and write addresses, are transferred
from JP 10114 to MEM 10112 through PD Bus 10146. S Ops,.
that is sequences of S Instruc~ions and operand names,
are transferred from ~EM 10112 to JP 10114 through MOD
Bus 10144 while data to be written into ME~ 10112 from JP
10114 is transferred from JP 10114 to ME~ 10112 through
JPD Bus 10142. JP~C Bus 10147 is a By-directional
6 3
-167-
Control bus for transferring command and control signals
between ME~ 10112 and JP 10114 for controlling ~ransfer
of data between MEM 10112 and JP 10114. As will be
described further below, MJP Port 10140, and in -
particular MOD Bus 10144 and PD Bus 10146, is generallyphysically organized as a single port that operates as a
dual port. In a first case, MJP Port 10140 operates as a
Job Processor Instruction (JI) Por~ for transferring S
Ops from MEM 10112 to JP 10114. In a second case, MOD
1014~ and PD 101~6 operate as a Job Processor Operand
tJO) Port for transfer of operands, from MEM 10112 to JP
10114, while JPD Bus 10142 and PD Bus transfer operands
from JP 10114 to MEM 10112.
Referring to MSB 20110, MSB 20110 contains MEM
10112's first, or bulk, level of storage capacity. MSB
20110 may contain from one to, for example, 16 MA's
20112. Each MA 20112 contains a dynamic, random access
memory array and may have a storage capacity of, for
example 256 Rilo-bytes, 512 Rilo-bytes, 1 Mega-bytes, or
20 2 Mega-bytes. ME~ 10112 may therefore have physical
capacity of up to, for example r 16 Mega-bytes of bulk
storage. As will be described further below. MA 20112's
of different capacity may be used together in MSB 20110,
for example, four 2 Mega-byte MA 20112's and four 1 ~ega-
25 by~e MA 20112's.
79~63
--168--
BC 20114 controls operation of MAI s 20112 and is thepath for transfer of data to and from MA's 20112. In
addition, BC 20114 performs error detection and
correction on data transferred into and out of ~IA's
5 20112, re~reshes data stored in ~AIs 20112, and, during
refresh operations, performs error detection and
correction of data stored in ~A' s 20112.
MC 20116 comprises MEM 10112's second, or cache,
le~el o~ storage capacity and contains, for example 8
Kilo-bytes of high speed memory. MC 20116, including BYF
20118, is also the path for data transfer between ~SB
20110 (through BC 20114) and ~P 10114 and IOS 10116. In
general, all read and write operations between JP 10114
and IOS 10116 are through MC 20116. IOS 10116 may,
however, per~orm read and write operations of complete
blocks by-passing MC 20116. Block write operations from
IOS 10116 are accomplished through BYF 20118 while block
read operations are performed through a data transfer
path internal to ~C 20116 and shown and described below.
All read and wri~e operations between MEM 10112 and JP
10114, however, must be performed through the cache
internal to MC 20116, as will be shown and described
further below.
As also shown and described below, FIU 20120 includes
write data registers ~or receiving data to be written
into ~qEM 10112 ~rom JP 10114 and IOS 10116, and circuitry
for manipulating data read from ~SB 20110 so that ~EM
10112 appears as a bit addressable memory. FIU 20120, in
9 ~6 3
-169-
addition to providing bit addressability of M~M 10112,
performs right and left alignment of data, zero fill of
data, sign extension operations, and other da~a
manipulation operations d~scribed further below. In
performing these data manipulation operations on data
read from MEM 10112 to JP 10114, MOD Bus 10144 is used as
a data path internal to ~EM 10112 for transferring of
data ~rom MC 20116 to FIU 20120,and from FIU 20120 to MC
20116~ That is, data to be transferred to JP 10114 is
read from MC 20116, trans~erred through MOD Bus 10144 to
FIU 20120, manipulated by FI~ 20120, and transferred from
FIU 20120 to JP 10114 through MOD Bus 1014~.
~ IC 20122 contains circuitry controlling operation of
MEM 10112 and, in particular, controls MEM 10112's
inte~face with JP 10114 and IOS 10116. MIC 20122
receives MEM 10112 read and write request, that is read
and write addresses through PD Bus 10146 and IOM Bus
10130 and control signals through JPM~ Bus 10147 and IOMC
Bus 10131, and provides control signals to BC 20114, MC
20116, and FIU 20120 through MC~TL Bus 20164.
~ aving described the overall structure and operation
of ~EM 10112, the structure and operation o~ ME~ 10112's
Port, MIO Port ~0128, and MJP Port 10140, will be
described next, ~ollowed by descriptions of MEM 10112's
control structure and the control and flow o~ ~EM 10112
read and write requests.
~79 ~6 3
-170-
d- ~:2L~ C~ C~kC~
~ E~ 10112 port structure is designed to provide a
simple interface to JP 10114 and IOS 10116. While
providing fast and flexible operation in servicing MEM
10112 read and write requests from JP 10114 and IOS
10116. In this regard, ~E~ 10112, as will be described
further below, may handle up to 4 read and write requests
concurrently and up to, for example, a 63.6 M-byte per
second data rate~ In addition MEM 10112 is capable of
10 performing bit granular addressing, block read and write
operations, and data manipulations, such as alignment and
filling, to enable JP 10114 and IOS 10116 to operate most
efficiently.
ME~ 10112 effectively services requests from three
ports. These ports are ~IO Port 10128 to IOS 10116,
hereafter referred to as IO Port, and JI and JO Ports,
described above, to JP 10114. These three ports share
the entire address base of MEM 10112, but IOS 10116, for
example, may be limited from making full use o MEM
20 10112's address space. Each port has a different set of
allowed operations~ For example, JO Port can use a bit
granular addres~es but can reference only 32 bits o~ data
on each request. JI Port can make read reques~s only to
word align 32 bit data items. IO Port may reference bit
25 granular data, and, as described further below, may read
or write up to 16 bytes on each read or write request~
The characteristics of each of ~hese ports will be
discussed next below.
9~ ~ 3
-171-
1~ ~ .
IOS 10116 may acce~s MEM 10112 in either of two
mode~. The first mode is block transfers by-passing or
through the cache in ~C 20116, and the second is non-
block transfer through the cache and MC 20116.
Block by-passes may occur for both read and write
operationsO A read or write operation is eligible for a
block by-pass if the data is on block boundaries, is 16
bytes long, and the read or write request is not
accompanied by a control signal indicating that an
encache (load into MC 20116's cache) operation is to be
performed. A by-pass operation takes place only if the
block address, that i5 the physical address of the block
in ME~ 10112 does not address a currently encached block,
that is the block is not present in MC 20116's cache~ If
the block is encached in MC 2011~lS cache, the read or
write transfer is to MC 20116's cache.
Partial block references, that is non-full block
trans ers will go through MC 20116's cache. If a cache
miss occurs, that is the reference da~a is not present in
MC 20116's cache, ME~ 10112's control structures transfer
the data to or from ~SB 20110 and update ~C 20116's
cache. It shollld be noted that partial blocks may be as
short as one byte, or up to 15 bytes long. A starting
byte addres~ may be anywhere within a block, but the
partial block's length may not cross a block boundary.
~79 ~ 6 3
-172-
Bit length transfers, that is transfers of data items
having a length of 1 to 16 bits and not a multiple of a
byte, or where address is not on a byte boundary, go
through MC 20116's cache. These o~erations may cross
byte, word, or block boundaries but may not cross page
boundaries. These specific operations requested by IO
port determines whether a read or write request is a
partial block or bit length transfer.
2. -~9LIg_~5a~ c~r~i~L~5~
All read or write re~uests from JO Port must go
through MC 20116's cache; by-pass operations may not be
performed. The data transferred between MEM 10112 and JP
10114 is always 32 bits in length but, of the 32 bits
passed, from zero to 32 bits may be valid data. JP 10114
determines the location of valid data within the 32 bits
by re~erring to certain FIU specification bits provided
as part of the read or write request. As will be
described further below, ~IU speci~ication bits, and
other control bits, are provided to MIC 20122 by JP 10114
20 through JPMC Bus 10147 when each read or write request i5
made.
While MEM 10112 does not perform block by-pass
operations to JP 10114, MEM 10112 may perform a cache
read-through operation. ~uch opsrations occur on a JP
25 10114 read request wherein the requested data is not
present in MC 20116's cache. If the JP 10114 read
request is for a full word, which is word aligned, ~EM
.
-
~1~79~63
-173-
10112's Load Manager, discussed below, transfers the
requested data directly to JP 10114 while concurrently
loading the requested data into MC 20116's cache. This
operation is referred to as a "hand-off n operation.
These operations may also be performed by IO Port for 16
bit half words aligned on the right hand half word of a
32 bit word, or if a full block is handed left and loaded
into MC 20116's cache.
3. ~5 _s~ k~
All JI Port re~uests are satisfied through MC 20116's
cache; MEM 10112 does not per~orm by-pass operations to
JI Port. JI Port requests are always read requests for
full-word aligned words and are handed off, as described
above, if a cache miss o curs In most other respects,
JI Port requests are similar to JO Port requestsr
Having described the overall structure and operation
of MEM 10112, including MEM 10112's input and output
ports to JP 10114 and IOS 10116, ~EM 10112's control
structure will be described next below~
e~
~g. :2~
Referring to Fig. 207, a more detailed block diagram
of MIC 20116 is shown. Fig. 207 will be referred to in
conjunction with Fig. 201 in the following discussion of
MEM 10112lS control structure.
1. ~9~9~
Referring firs~ to Fig. 207, MC~TL Bus 20164 i
represented as including MCNTL-BC Bus 20164A, MCNTL-~C
Bus 20164B, and MCNTL-FIU Bus 20164C. Bu~es 20164A,
il~79~3
--17 4--
20164B, and 20164C are branches of MCNTL Bus 20164
connected to, respectively, BC 20114, MC 20116, and FIU
2~120. ~lso represented in Fig. 207 are PD Bus 10146 and
J~MC BUS 10147 to JP 10114 t and IOM Bus 10130 and IOMC
Bus 10131 to IOS 10116.
JO Port Address Register (JOPAR) 20710 and JI Port
Address Regis~er (JIPAR) 20712 have inputs connected from
PD ~us 10146. IO Port Address Register (IOPAR) 20114 has
an inpu~ connected from IO~ Bus 10130. Port Control
Logic (PC) 20716 has a bi-directional input/outputs
connected from JPC 10147 and IOMC Bus 10131. By-pass
Read/Write Control Logic ~BR/WC) 20718 has a bi-
directional input/output connected from IOMC Bus 10131.
Outputs of JOPAR 20710, JIPAR 20712, and IOPAX 20714.
are connected to inputs of Port Request Multiplexer
~PRMUX) 20720 through, re~pectively, Buses 20732, 20734,
20736. PRMUX 20720's output in turn is connected to Bus
20738. Branches of Bus 20738 are connected to lnputs of
Load Pointers (LP) 20724, ~iss Control (~ISSC) 20726, and
Request Manager (RM) 20722, and to Buses MCNTL-~C 20164B
and ~CNTL-FIU 20164C.
Outputs of PC 20716 are connected to inputs of JOPAR
20710 r JIPAR 20712 ~ IOPAR 20714 ~ P~MUX 207~0, and LP
20724 through Bus 20738. Bus 20740 is connected between
an input/output of PC 20716 and in input~output of RM
20722.
~9~63
--175--
An output of BR/WC 20718 is connected to MCNT3:-MC Bus
20164B through Bus 20742. Inputs of BR/WC 20718 are
connected from outputs of R~ 20722 and Read ~ueue (RQ)
20728 through, respectively, Buses 20744 and 20746
RM 20722 has outputs connected to MCNTL-BC Bus
- 5 20164A, MCNTL-FIU Bu~ 20164C, and input of MISSC 20726,
and an input of LP 20724 through, respectively, Buses
20748, 20750, 20752, an.d 20754. MISSC 20726's output is
connected to MCNTL BC Bus 20164A. Outputs of LP 20724
are connected to ~qCNTL-MC Bus 20164E~ and to an input of
L~ 20730 through, respectively, Buses 20756 and 20758.
RQ 20728 ' s input is connected f rom MCNTL-MC Bus 20164B
through Bus 20760 and RQ 20723 has outputs connected to
an input of LP 20724, through ~us ~û762, and as
previously described to an input of BR/WC 20718 through
Bus 20746. Finally, Llq 20730's output is connected to
MC~TL-MC Bus 20164B through Bus 20764.
H~ving described the structure of MIC 20716 with
reference to Fig. 207, and having previously aescribed
the structure of MEM 10112 with reference to Fig. 201,
~EM 10112 ' s control structure op~ration will next be
described ~ith reference to both f igures 201 and 207.
2. ~: 3~=~
Referring f irst to Fig. 207, JOPAR 20710, JIPAR
20712, and IOPAR 20714 are, as previously described,
connected from PD Bus 10146 ~rom JP 1011~ and IO~q Bus
10130 from IOS 10116. JPAR 20710, JIPAR 20712, and IOPAR
20714 receive read and write request addresses from JP
10114 and IOS 10116 and store these addresses for
1~79~63
--17 6 -
subsequent service by ~EM 10112. As will be described
furthex belo~, these address inputs ~rom JP 10114 and IOS
10116 include FIU information specifying what data
manipulation operations must be performed by FIU 20120
before requested da~a is transferred to the requestor or
written into MEM 10112, information regarding the
destination data read from MEM 10112 is to be provided
~o, information regarding the type of operation to be
performed by MEM 10112, and informa~ion regarding operand
length. Request address information received and stored
in JOPAR 20710, JIPAR 20712, and IOPAR 20714 is re~ained
therein until MEM 10112 has initiated service of the
corresponding reques~s. ME~ 10112 will accept further
request address information into a given port register
only a ter a previous request into that port has been
serviced or aborted. Address information outputs from
JOPAR 20710, JIPAR 20712, and IOPA~ 20714 is transferred
through PRMUX 20720 to Bus 20738 and ~rom there to RM
20722, ~C 20116, and F~U 20120 as ser~ice of individual
requests is initiated. As will be described below, this
address information will be transferred through PRM~X
20720 and Bus 20738 to LP 20724 for ~se in servicing a
cache miss upon occurrence of a ~C 2U116 miss.
PC 20716 receives command and control signals
pertinent to each re~uested memory operation from JP
10114 and IOS 10116 through JPMC Bus 10147 and IOSC ~us
10131. PC 20716 includes request arbitration logic and
7~)63
-177-
port ~tate logic. Request arbitration logic determines
the se~uence in which IO, JI, JO ports are serviced, and
when each port is to be serviced. In determining the
sequence of port service, request arbitration logic uses
5 present port state information for each port rom the
port state logic, information from JPMC ~us 10147 and
IOMC Bus 10131 regarding each incoming request, and
inormation from R~ 20722 concerning the present state of
operation of MEM 101120 Port state logic selects each
10 particular port to be serviced and, by control ~ignals
through Bus 20738, enables transfer of each port's
request address information from JOPAR 20710, JIPAR
20712, and IOPAR 20714 through PR~UX 20720 to Bus 20738
for use by the remainder of MEM 10112's control logic in
15 servicing the selected port. In addition to request
information received from J~ 10114 and IOS 10116 through
JPMC Bus 10147 and IOMC Bus 10131, port state logic
utilizes information from RM 20722 and, upon occurrence
of a cache miss, rom LM 2073û (for clarity of
20 presentation, this connection is not represented in Fig.
207) . Port state logic also controls various por~ state
flag signals, for exampl~ port availability signals,
signals indicating valid re~uests, and signals indicating
that various ports are waiting service
RM 20722 controls execution of servlce for each
request. R~ 20722 is a microcode controlled "micro-
machine" executing programs called or by requested ;SEM
10112 operations. Inputs of RM 20722 include re~uest
address information from IOPAR 20714, JIPAR 20212, and
79~f~3
-178-
JOPAR 20210, including information regarding the type of
MEM 10112 operation to be performed in servicing a
particular request, interrupt ~ignals from other MEM
10112 control element~, and, ~or example, start signals
from PC 20716's request arbitration logic. RM 20722
5 provide~ control signals to FIU 20120, MC 20116, and most
other parts of MEM 10112's control structure.
Referring to Fig. 201, MC 20116's cache is, for
example, an 8 Kilo-byte, four set associative cache used
to provide rapid access to a subset of data stored in MSB
10 20110. The subset of MSB 20110 data stored in MC 20116's
cache at any time is the data most rece~tly used by J2
10114 or IOS 10116. MC 20I16's cache, described further
below, includes tag store comparison logic for
determining encached addresses, a data store containing
15 corresponding encached data, and registers and logic
necessary to up-date cache contents upon occurrence of a
cache miss. Registers and logic for servicing cache
misses includes logic for determining the least recently
used cache entry and registers for capture and storage of
20 inormatio~ regarding missed cache references, for
example modify bi~s and replacement page numbers~ Inputs
to MC 20116 are provided from RM 20722, LM 20730
(discussed further below), FIU 20120, MSB 20110 (through
BC 20114), LP 20724 (described further below) and address
25 information from PRMUX 20720~ Outputs of MC 20116
include data and go to FIU 20120 (through MOD Bus 10144),
~7~ ~ 6 3
-179-
the data requestors (JP 10114 and IOS 10116)~ and a MC
20116 Write Back ~ile (described further below).
As previously described, FIU 20120 includes logic
necessary to make MEM 10112 appear bit addressableO In
addition, FIU 20120 includes logic for performing certain
data manipulation operations as re~uired by the
requestors ~JP 10114 or IOS 10116). Data is transferred
into FIU 20120 rom ~C 20116 through that portion o MOD
Bus 10144 internal to MEM 10112, is manipulated as
required, and is then ~ransferred to the requestor
through ~OD Bus 10144 or ~IO Bus 10129. In the case of
writes requiring read-modify-write of encached data, the
data is transferred back to MC 20116 through MOD Bus
10144 after manipulation. In general, data manipulation
operations include locating requested data onto selected
MOD Bus 10144 or ~IO Bus 10139 lines and filling unused
bus lines as specified by the requestor. Data inputs to
FIU 20120 may be provided from MC 20116 or JP 10114
throu~h MOD Bus 10144 or from IOS 10116 through IOM Bus
10130. Data outputs from FIU 20120 may be provided to ~C
20116, JP 10114, or IOS 10116 through these same buses.
Control information is provided to FI~ 20120 from RM
20722 through Bus 20748 and MCNTL-FIU Bus 20164C.
Address information may be provided to FIU 20120 from
JOPA~ 20710, JIPAR 20712, or IOPAR 20714 through PRMUX
20720, Bus 20738, and MCN~L-FIU Bus 20164C.
~1~79~63
--1 80--
Returning to Fig. 207, ~ISSC 20726 i5 used in
handling MC 20116 misses. In the event of a re~uest
referring to data not in MS 20116's cache, MISSC 20726
stores block address of the reference and type of
5 operation to be performed, this information being
provided from an address register in MC 20116 and from RM
20722. MISSC 20726 utilizes this information in
generating a command to BC 20114, through MCNTL-BC Bus
20164A, for a data read from MSB 20110 to obtain the
10 referenced daca. BC 20114 places this command in a
queue, or register, and subsequently executes the
commanded read operation. MISSC 20726 also ~enerates an
entry into RQ 20728 (described ~urther below~ indicating
the type of operation to be performed when referenced
15 data is subsequently read from ~qSB 20110.
` RQ 20728 is, ~or example, a three-level deep ~ueue
storing information indicating operatlons associated with
data being read from MSB 20110. Two kinds of operation
may be indicated: block by-pass reads and cache loads.
20 Xf a cache load is specified, ~hat is a read and store to
MC 20116's cache, is indicated, RM 20722 is interrupted
and forced to place other ME~ 10112 operations in idle
until cache load is completed. A block by-pass read
operation results in by-pass read control (described
25 ~elow) assuming control of the data from MSB 20110.
Input~ to RQ 20728 are control signals from RM 20752,
MISSC 20726, and BC 201141 RQ 20728 provides control
'.;
7~6
--1 81--
outputs to LP 20724 (described below) LM 20730 (described
below) RM 20722, and by-pass read control (described
below) .
LP 20724 is a set of registers for storing
5 information necessary for servicing ~qC 20116 misses that
result in order to load ~lC 20116's tag store. LM 20730
uses this information when data stored in MSB 20110 and
read from MSB 20110 to service a MC 20116 cache miss,
becomes available through BC 20114. Inputs to LP 20724
10 include the address of the missing referencet provided
from JOPAR 2071û, JIP~R 20712, or IOPAR 20714 throu~h
PRMUX 20720 and Bus 20738, commands from RM 20722, and a
control signal from RQ 20728. hP 20724 outputs include
addresses of missed references to MC 20116, through Bus
15 20756 and M~CTL-MC 20164B, and command signals to LM
20730 and BR/WC 20718.
L~ 20730, referred to above, controls loading of MC
20116's cache with data from MSB 20110 after occurrence
of a cache miss. RQ 2072B, referred to above, indicates,
20 for each data read ~rom ~SB 20110, whe~her the data read
i~ the result of a MC 20116 cache miss. If the data is
read from MSB 20110 as a result of a cache miss, L~q 20730
proceeds to issue a sequence of control signals for
loading the data from M5B 20110 and its associated
25 address into MC 20116's cache. This data is transf erred
into ~IC 20116's cache data store while the block address r
from LP 20724 is transferred into the tag store
~7~6~63
--1 82--
(described in the following discussion) of MC 20116's
cache. I~ the transfer of data into ~C 20116 ' s cache
replaces data previously resident in that cache, and that
previous data is "dirty", that is has been written into
so as to be ~iferent from an original copy of the data
S stored on MSB 20110, the modi~ied data resident in ~C
20116's cache must be written back in~o MSB 20110. This
operation is performed through a Write Back File
contained in MC 20116 and described b~low. In the event
of such an operation, LM 20730 initiates a write back
operation by ~C 20116 and BC 20114, also as described
below.
As will be described further in a following
description~ all ~C 20116 cache load operations are full
4 word blocks. A request resulting in a MC 20116 cache
15 miss may re5ult in a "hand-off", that is a read operation
of a full 4 word block. Handoff operations also may be
of slngle 32 bit words wherein a 32 bit word aligned word
is transferred from JP 10114 or a 16 bit operand aligned
on the right half-word is transferred from IOS 10116. In
20 such a handoff operation, LM 20730 will send a valid
request signal to the requesting port and a handoff
operation will be performed Otherwise; a waiting signal
will be sent to the re~uesting port and the request will
re-enter the priority queue of PC 2071~ for subsequent
execution. To accomplish these operations, LM 20730
receives input from RQ 20728, (not shown in Fig. 207 for
79~
-l 83-
clarity of presentation) and LP 20724. L~ 20730 provides
outputs to port state logic of PC 20716, to MC 20116, ~C
20116's Write Back File and MC 20116's Write Back Address
Register and to BC 20114~
Referring to Fig. 201, as previously discussed IOS
20116 may request a full block write operation directly
to MSB 20110. Such a by-pass write request may be
honored if the block being transferred is not encached in
MC 20116's cache. In such a case, R~ 20722 will initiate
10 the transfer setting up By-Pass Write Control logic in
BR/WC 20718, and may then pass control of the operation
over to BR/WC 20718's By-Pass Write Control logic for
completion. By Pass Write Control may then accept the
remaining portion of the data block from IOS 10116,
generating appropriate hand shaking sisnals through IOMC
Bus 10131, and load the data block into BYF 20118 and MC
20116. MISSC 20726 will provide a by-pass write command
to BC 20114, through ~CTL-PC Bus 20164A. BC 20114 will
then tansfer the data block from B~F 20118 and into MA's
20 20112 and MSB 20110~
As previously described, BYF 20118 receives data rom
IOM Bus 10130 and provides data output to BC 20114
through BWY Bus 20178 and SBD Bus 20146. BYF 20118 is
capable of simultaneously accepting data from IOM Bus
10130 while reading data out to BC 20114. Control o~
writing data into B~F 20118 is pro~ided from BR/WC
20718's By-Pass Write Control logic.
i l~79
-184-
IOS 10116 may, as previously described, request a
full block read operatlon by-passing MC 20116lS cache.
In such a case, BR/WC 20718's by-pass read control
handles data transfer ~o IOS 10116 and generates required
hand ~haking signals to IOS 10116 through ~OMC Bus
10131. The data path for by-pass read operations is
through a data path internal to MC 20116, rather than
through B~F 20118. This internal data path is RDO Bus
20158 to MIO Bus 10129~
As previously descri~ed, BC 20114 manages all data
transfers to and from ~A's 20112 in MSB 20110. BC 20114
receives requests for data transfers from RM 20722 in an
internal queue register. All data transers to and from
MS8 20110 are full block transers with block aligned
addresses. On data write operations, BC 20114 receives
data from BWF 20118 or from MC 20116's Write Back File
and ~ransfers the data into MA's 20112. During read
operations, BC 20114 fetches the data block from ~A's
20112 and places the data block on RDO 8us 20158 while
signalling to M~C 20122 that the data is available. As
described above, MIC 20122 tracks and controls transfer
of data and BY~ 20118, ~C 20116, and ~C 20116's Write
Back File, and directs data read from ~SB 20110 to the
appropriate destination, MC 20116's Data Store, JP
10114, or IOS 10116.
In addition to the above operations, BC 20114
controls re~resh of MA's 20112 and performs error
detection and correction operations. In this regard, BC
20114 performs two error detection and correction
~79 ~6 3
-185-
aperations In the firs~, BC 20114 detects single and
double bit errors in data read from MSB 20110 and
corrects single bit errors. In the second, BC 20114
re~ds data stored in MA's 20112 during refresh operations
and performs single bit error detection. Whenever an
error is detected, during either read operations or
refresh operations, BC 20114 makes a record of that error
in an error log contained in BC 20114 (described further
in a following description). Bo~h JP 10114 and IOS 10116
10 may read BC 20114's error log, and information from BC
20114's error log may be recorded in a CS 10110
maintenance log and to assist in repair and trouble
shooting of CS 10110. BC 20114's error log may be
addressed directly by RM 20722 and data from BC 20114's
15 error log is transferred to JP 10114 or IOS 10116 in the
same manner as data stored in MSB 20110.
Referring finally to MA's 20112, each MA 20112
contains an array of dynamic semiconductor random access
memories. Each MA 20112 may contain 256 Rilo-bytes, 512
20 ~ilo-by~es, 1 Mega~bytes, or 2 ~ega-bytes of data
storage. The storage capacity of each MA 20112 is
organized as segments of 256 Rilo-bytes each. In
addressing a particular MA 20112, BC 20114 selects that
particular MA ~0112 as will be described further ~elow.
25 8C 20114 concurrently select~ a segment within that MA
20112, and a block of four words within that segment.
Each word may comprise 39 bits of information, 32 bits of
data and 7 bits of error correcting code. The full 39
bits of each MA 20112 word are transferred between BC
11 ~9 ~6 3
-186-
20114 and MA's 20112 during each read and write
operation. ~aving briefly described the general
structure and operation of MEM 10112, certain types of
operations which may be performed by ME~ 10112 will be
described next below.
f- ~5:!31~ t f3.~L~
MEM 10112 may perform two general types of
operation. The first type are data transfer operations
and ~he second type are memory maintènance opera~ions.
Data transfer operations may include read, write, and
read and set~ Memory maintenance operations may include
read error log, repair block, and flush cacheO Except
during a flush cache operation, the existence of MC 20116
and its operation is invisible to the requestors, that is
JP 10114 and IOS 10116.
A MEM 10112 read operation transfers data from MS
10112 to a requestor, either JP 10114 or IOS 10116. A
read data transfer is asynchronous in that the requestor
cannot predict elapsed time between submission of a
memory operation request and return of requested data.
Operation of a requestor in MEM 10112 is coordinated by a
requested data available signal transmitted from MEM
10112 to the requestor.
A ME~ 10112 write operation transers data from
either JP 10114 or IOS $0116 to ME~ 10112. During such
operations, JP 10114 is not required to wait for a signal
from MEM 10112 that data provided to MEM 10112 from JP
~7~
-187-
10114 has been acceptedO JP 10114 may transfer data to
MEM 10112's JO Port whenever a JO Port available signal
~rom MEM 10112 is present; read data is accepted
immediately without further action or waiting required o
JP 10114~ Word write operations from IOS 10116 are
p~rformed in a similar manner. On block write
operations, however, IOS 10116 is required to wait for a
data taken signal from MEM 10112 before sending the 2nd,
3rd and 4th words of a block.
MEM 10112 has a capability to perform "lock bit~
operations~ In such operations, a bit granular read of
the data is performed and the entire operand is
transmitted to the requestor. At the same time, the most
significant bit of the operand, that is the Lock Bit r is
set to one in the copy of data stored in MEM 10112. In
the operand sent to the requestor, the lock bit remains
at its previous value, the value before the current read
and set opera~ion. Test and set opera~ions are performed
by performing read and set operations wherein the data
item length is specified to be one bito
As previously described, MEM 10112 performs certain
maintenance operations, including error detection. M~M
10112lS Error Log in BC 2011~ is a 32 bit register
containing an address field and an error code field. On
a first error to occur, the error type and in some cases,
such as ERCC errors on read data stored in MSB 20110, the
address o~ the data containing the error are stored in BC
20114's Error Log Register. ~n interrupt signal
~79 ~6 3
-188-
indicating detection of an error is raised at the same
that information regarding the error is stored in the
Error Log. If multiple errors occur before Error Log i~
read and reset, the information regarding the first error
will be retained and will remain valid. The Error Log
code field will, however, indicate that more than one
error has occurred
JP 10114 may request a read Error Log operation
referred to as a "Read Log and Reset" operation. In this
operation, ME~ 10112 reads the entire con~ents of Error
Log to JP 10114, resets Error Log Register, and resets
the interrupt signal indicating presence of an error.
IOS 10116 r as discussed further below, is limited to
reading 16 bits at a time from MEM 10112. It therefore
requires two read operations to read Error Log. First
read operation to IOS 10116 reads an upper 16 bits of
Error Log data and does not reset Error Log. The second
read operation is performed in the same manner as a JP
10114 Read Log and Reset operation, except that only the
low order 16 bits of Error Log are read to IOS 10116.
~ EM 10112 performs repair block operations to correct
parity or ERCC errors in data stored in MC 20116lS Cache
or in data stored in ~A's 20112. In a repair block
procedure, parity bits for data stored in MC 20116's
Cache, or ERCC check bits of data stored in MA's 20112,
are modified to agree with the data bits of data stored
therein. In this regard, repaired uncorrectible errors,
such as two bit errors of data in MA's 20112, will have
good ERCC and parity values. Until a repair block
g~3
-189-
operation is performed, any read request directed to bad
data, that is data having parity or ERCC check bits
indicating invalid data, will be flagged as invalid.
Repair block operations therefore allow such data to be
read as valid, for example to be used in a data
correction operation. Errors are ignored and not logged
in BC 20114's Error Log in repair block operations. A
write operation into an area containing bad data may be
accomplished if ~E~ 10112's internal operation does not
require a read-modified-write procedure. Only byte
ali~ned writes of integral byte length data residing in
MC ~0116 and word aligned writes of integral word leng~hs
of data in MSP 20110 do not require read-modified-write
operation9 By utilizing such write operations, it is
15 therefore possible to overwrite bad data by use of normal
write operations before or instead of repair block
operations.
MEM 10112 performs a cache flush operation in event
of a power failure, that is when MEM 10112 goes into
20 battery back-up operation~ In such an event, only MA's
20112 and BC 20114 xemain powered. Before JP 10114 and
IOS 10116 lose power, JP 10114 and IOS 10116 must
transfer to MEM 10112 any data, including operating
state, to be saved. This is accomplished by using a
25 series o~ normal write operati~ns. ~fter conclusion of
these write operations, both JP 10114 and IOS 10116
transmit a flush cache request to MEM 10112. Upon
9~
--190- '
receiving two flush cache requests, MEM 10112 flushes MC
201161S Cache so that all dirty data encached in ~C
20116's Cache is transferred into MA's 20112 before power
iS 109t. If only JP 10114 or IOS 10116 is operating, DP
10118 will detect this fact and will have transmitted an
enabling signal (FLUS~O~ to ~E~ 10112 during system
initializaticn. FLUSHOK enables MEM 10112 to per~orm
cache flush upon receiving a single flush cache request.
After a cache flush operation, no further MEM 10112
operations are possible until DP 10118 resets a power
failure lock-out si~nal to enable MEM 10112 to resume
normal operation~
Having described ~EM 10112's overall structure and
operation and certain operations which may be performed
by ~EM 10112, ~EM 10112's inter~aces to JP 10114 and IOS
10116 will be described next belo~
g- ~_
As previously described, MJP Port 10140 and MIO Port
20 10128 logically function as three independent ports.
These ports are an IO Port to IOS 10116, a JP Operand
Port to JP 10114 and a JP Instruction Port to JP 10114.
Referring to ~igs. 209, 210, and 211, diagramic
representa~ions of IO Port 20910~ JP Operand (JPO) Port
21010, and JP Instruction (JPI) Port 21110 are shown
respectively.
IO Port 20910 handles all IOS 10116 re~uests to ME~
10112, including transfer of both instructions and
1~7~
--191--
operands. JPO Port 21010 is used for read and write
operations of operands, for ,exa~ple numeric values, to
and from JP 10114~ JPI Port 21110 is used to read SINs,
that is SOPs and operand NA~Es, from MEM 10112 to J~
10114. Memory service re~uests to a particular port are
serviced in the order that the requests are provided to
the Port. Serial order is not maintained between
requests to different ports, but ports may be serviced in
the order of their priority. In one embodiment of the
present invention, IO Port 20910 is accorded highest
priority, followed by JPO Port 21010, and lastly by JPI
Port 21110, with requests currently contained in a port
having priority over incoming requests. As described
above and will be described in more detail in ~ollswing
descrip~ions, MEM 10112 operations are pipelined. This
pipelining allows interleaving of reques~s from IO Port
20910, JPO Port 21010, and JPI Port 21110, as well as
overlapping service of requests at a particular port. By
overlapping operations it is meant that one operation
servicing a particular port begins be~ore a previous
operation servicing that port has been comple~ed.
1. ~
Re~erring ~irst to Fig. 209, a diagramic
representation of IO Port 20910 is shown. Signals are
transmitted between IO Port 20910 and IOS 10116 throush
MIO Bus 10129, IOM Bus 10130, and IOMC Bus 10131. MIO
9 ~ ~ 3
-192-
Bus 10129 is a unidirectional bus having inputs from ~C
20116 and FIU 20120 and dedicated ~o transfers of da~a
and instructions from ~E~ 10112 to IOS 10118. IO~ Bus
10130 is likewise a unidirectional bus and is dedicated
to the transfer, from IOS 10118 to MEM 10112, of read
addresse , write addresses, and data to be written into
ME~ 10112. IOM Bus 10130 provides inputs to BYF 20118,
FIU 20120 r and MIC 20122. IOMC Bus 10131 is a set of
dedicated signal lines for the exchange of control
10 signals between IOS 10118 and MEM 10112.
~ eferring first to MIO Bus 10129, MIO Bus 10129 is a
36 bit bus receiving read data inputs from MC 20116's
Cache and from FIU 20120 . A single read operation from
~EM 10112 to IOS 10116 transfers one 32 bit word (or 4
15 by~es) of data (MIO(0-31)) and ~our bits of odd parity
(MIOP~0-3)), or one parity bit per byte.
Referring next to IOM Bus 10130, a single transfer
from IOS 10116 to ME~ 10112 includes 36 bits of
information which may comprise either a memory request
20 comprising a physical address, a true length, a~d command
bits. These memory requests and data are multiplexed
onto ~OM 10130 by IOS 10116.
Data transfers from IOS 10116 to MEM 10112 each
comprise a single 32 bit data word (IO~(0-31)) and four
25 bits of odd parity (IOMR(0-3)) or one parity bit per
byte. Such data transfers are received by either BYF
20118 or FIU 20120.
1 ~ 79 06 3
-193-
Each IOS 10116 memory request to MEM 10112, as
described above, an address field, a length field, and an
operation code field. Address and length fields occupy
the 32 IOM Bus 10130 lines used for transfer of data to
s MEN 10112 in IOS 10116 write operations~ Length field
includes four bits of informa~ion occupying bits ~IOM(0-
3)) o~ IOM Bus 10130 and address field contains 27 bits
of information occupying bits (IOM(4-31)) of IOM Bus
10130~ Together, address and leng~h ~ield specify a
physical starting address and true length of the
particular data item to be written into or read from ME~
10112. Operation code field specifies the type of
operation to be performed by MEM 10112. Certain basic
operation codes comprise 3 bits of information occupying
bits (IOMP (32-36)) of IO~ Bus 10130; as described
above. These same lines are used for transfer of parity
bits during data transfers. Certain operations which may
be re~uested of ~EM 10112 by IOS 10116 are, together with
their corresponding command code fields, are;-
o00 = read,
001 = read and set,
010 = write,
011 = error,
100 = read error log (~irst half),
101 = read error log (second half) and reset,
110 = repair block, and
111 = flush cache.
- . ~
~7~ ~ 6 3
-194-
Two further command bits may specify further
operations to be performed by ME~ 10112. A first command
bitt indicates to ~EM 10112 during write operations
whether it is desirable to encache the data being written
into MEM 10112 in MC 20116's C che. IO5 10116 may set
this bit to zero if reuse of the data is unlikely,
thereby indicating ~o MEM 10112 that ~EM 10112 should
avoid enchaching the data. IOS 10116 may set this bi~ to
one if the data is likely to be reused, thereby
indicating to ~EM 10112 that it is preferable to encache
the data. A second command bit is referred to a CYCLE.
CYCLE command bit indicates to MEM 10112 whether a
particular data transfer is a single cycle operation,
that is a bit granular word, or a four cycle operation,
that is a block aligned block or a byte aligned partial
block.
IOMC 10131 includes a set of dedicated lines for
exchange of control signals between IOS 10116 and MEM
101I2 to coordinate operation of IOS 10116 and MEM
10112. A first such signal is Load IO Request (LIOR)
: from IOS 10116 to ~EM 10112. When IOS 10116 wishes to
load a memory request into MEM-10112, IOS 10116 asserks
LIOR to MEM 10112. IOS 10116 must assert LIOR during the
same system cycle during whioh the memory request, that
is addre s, length, and command code fields, are valid.
If LIOR and IO Port Available (IOPA) signals, described
below, are asserted during the same clock cyle, MEM
10112's port is loaded from IOS 10116 and IOPA is
-
~79 ~ 3
-195-
dropped, indicating the request has been accepted. If a
load of a request is attempted and IOPA is not asserted,
MEM 10112 remains unaware of the request, LIOR remains
active, and the request must ~hen be re~eated when IOPA
is asserted.
IOPA is a signal from MEM 10112 to IOS 10116 which is
asserted by MEM 10112 when ~EM 10112 is available to
accept a new reques~ from IOS 10116. IOPA may be
assPrted while a pre~ious request from IOS 10116 is
completing operation if the address, length, and
operation code fields of the previous request are no
longer required by ~EM 10112, for example in servicing
bypass operations.
IO Data Taken (TIOMD) is ~ signal from MEM 10112 to
15 IOS 10116 indicating that MEM 10112 has accepted data
~rom IOS 10116 . IOS 10116 places a first data word on
IOM Bus 10130 on the next system cloc~ cycle after a
write request is loaded; that is, LIOR has been asserted,
a memory re~{uest presented, and IOPA dropped. MEM 10112
then takes that data word on the clock edge beginning the
next system clock cycle. At this poi~t, MEM 10112
asserts TIO~D to indicate the data has been accepted. On
a single word operations TIOMD is not used by IOS 10116
as a first data word is always accepted by MEM 10112 if
IO Port 20910 was available. On block operations, a
first data word i~ always ~aken but a delay may occur
between acceptance of irst and second words. IOS 10116
- ~ /
30 ~ 3
-196-
is re~uired to hold the second word valid on IOM Bus
10130 until ~EM 10112 responds with TIOMD to indicate
that the block operation may proceed.
Data Available for IO (DAVXO) is a signal asserted ~y
MEM 10112 to IO5 10116 indicating that data requested by
IOS 10116 is available. DA~IO is asserted by ~E~ 10112
during the system clock cycle in which MEM 10112 places
the requested data on MIO Bus 10129. In any single word
type transf er, DAVIO is active for a single system clock
transfer. In block type transf ers, DAVIO is normally
active f or four consecutive system clock cycles. Upon
event of a single cycle "bubble" resulting from detection
and correction of an ERCC error by BC 20114, DA~IO will
remain high for four non-consecutive system clock cycles
and with a single cycle bubble, a non-assertion, in DAVIO
corresponding to the detection and correction of the
error.
IO Memory Interrupt (I~INT~ is a signal asserted by
ME~ 10112 to IOS 10116 when BC 20114 places a record of a
detected error in BC 20114's Error Log, as described
above.
Previous MIO Transfer Invalid (P~IOI) signal is
similarly a signal asserted by ~EM 10112 to IOS 10116
regarding errors in data read from MEM 10112 to IOS
10116. If an uncorrectible error appears in such data,
that is an error in two or more data bits, the incorrect
data is read to IOS 10116 and PMIOI signal asserted by
~'79(:~63
--1 g7--
MEM 10112. Correctible, or single bit, errors in data do
not result in assertion of PMIOI. ~EM 10112 will assert
PMIOI to IOS 10116 of the next system clock cycle
following ME~ 10112's assertion of DAVIO~
Having described MEM 10112's interface to IOS 10116,
S and certain operations which IOS 10116 may request of MEM
10112, certain MEM 10112 operations within the capability
of the interface will be dessribed next. First, operand
trans~ers, for example of numeric data, between ~EM 10112
and IOS 10116 may be bit granular with any length from
one to sixteen bits. Operand transfers may cross
boundaries within a page but may not cross physical page
boundaries. As previously described, ~IO Bus 10129 and
IOM Bus 10130 are capable of transferring 32 bits of data
at a time. The least significant 16 bits of these buses,
that is bits 16 to 31, will contain right justified data
during operand transfers 7 The contents o~ the most
significant 16 bits of these buses is generally not
deined as MEM 10112 generally does not perform ~ill
oerations on read operations to IO Port 20910, nor does
IOS 10116 fill unused bits during write operations.
During a read or write operation, on~y those data bits
indicated by length field in the corresponding memory
request are of significance. In all cases r however,
parity must be valid on all 32 bits o~ MIO Bus 10129 and
IOM Bus 10130.
~79
--198-
Referring to Fig. 204, IOS 10116 includes Data
Channels 20410 and 20412 each of which will be described
` furth~r in a followin~ detailed de cription of IOS
10116. Data Channels 20410 and 20412 each possess
5 particular characteristics defining certain IO Port 20910
operations. Data Channel 20410 operates to read and
write block aligned full and partial blocks, Full blocks
have block aligned addresses and lengths of 16 bytes.
Partial blooks have byte aligned addresses and lengths o
lO 1 to lS bytes; a partial block transfer must be within a
bloc!s, thak is not cross block boundaries. A full 4 word
block will be transferred between IOS 10116 and MEM 10112
in either case, but only those blocks indicated by length
of field in a corresponding ME~ 10112 request are of
15 actual significance in a write operationO Non-addressed
bytes in such operations may contain any information so
long as parity is valid for the entire data transfer.
Data Channel 20412 preferably reads or writes 16 bits at
a time on double byte boundaries. Such reads and writes
20 are right justified on MIO Bus 10129 and IOM Bus 10130.
The most significant 16 bits of these buses may contain
any information during sucb operations so long as parity
is valid for the entire 32 bits. Data Channel 20412
operations are slmilar to IOS 10116 operand read and
25 write operations with double byte aligned addresses and
lengths o~ 16 bits. Finally r instructions, for example
controlling IOS 10116 operation, are read from ME~i 10112
`~
~7~ ~ ~ 3
-199-
to IOS 10116 a block at a time. Such operations are
identical to a full block data read.
~aving described the operating characteristics of IO
Port 20910, the operating characteristics of JPO Port
21010 will be described next.
2. a:sL~ D~- -LiD~
Referring to Fig. 210, a diagramic representation of
JPO Port 21010 is shown~ As previously described, JPO
Port 21010 is utilized for transfer of operands, for
examp}e numeric data, between MEM 10112 and JP 10114.
JPO Port.21010 includes a request input (address, length~
and operation information) to MIC 20122 from 36 bit PD
Bus 10146, a write data input to FIU 20120 from 32 bit
15 JPD Bus 10142, a 32 bit read data output from MC 20116
and FIU 20120 to 32 bit MOD Bus 10144, and bi-directional
control inputs and outputs between MIC 20122 and JPMC Bus
10147.
Re~erring first to JPO Port 21010's read data output
to ~OD Bus 10144, MOD Bus 10144 is used by JPO Port 21010
to transfer data~ for example operands, to JP 10114. MOD
Bus 10144 is also utilized internal to MEM 10112 as a bi-
directional bus to transfer data between ~C 20116 and FIU
20120~ In this manner, data may be transferred from MC
2~116 to FIU 20120 where certain data format operations
are performed on the data before the data is transferred
to JP 10114 through MOD Bus 10144. Data may also be used
to transfer data from FIU 20120 to MC 20116 after a data
format operation is performed in a write operation. Data
-- ;
l~t790~
-200-
may also b~ transferred directly from MC 20116 to JP
10114 through MOD Bus 10144. Internal to MEM 10112, MOD
Bus 10144 is a 36 bit bus for concurrent trans~er of 32
bits of data, ~OD ~us 10144 bits (~OD(0-31))l and 4 bits
of odd parity, 1 bit per byte, MOD Bus 10144 bits
(MODP(0-3)). External to ME~ 10112, MOD Bus 10144 is a
32 bit bus, comprising bits (~OD(0-31)); parity bits are
not read to JP 10114.
~ Data is written into ME~ 10112 through JPD Bus 10142
to FIU 20120. As just described, data format operations
may then be performed on this data before it is
transferxed from FI~ 20120 to MC 20116 through MOD Bus
10144~ In such operations, JPD Bus 10142 operates as a
32 bit bus carrying 32 bits of data, bits (JPD (0-31)),
with no parity bits. JO Port 21010 generates parity for
JPD Bus 10142 data to be written into ~E~ 10112 as this
data is transferred ~nto MEM 10112,
Memory requests are also transmitted to MEM 10112
from JP 10114 through JPD Bus 10142, which operates in
this regard as a 40 bit bus. Each such re~uest includes
an address field, a length field, an FIU field specifying
data formating operations ~o be per~ormed, operation code
field, and a destination code field specifying
destination of da a read from ~EM 10112. Address field
includes a 13 bit physical page number field, (JPP~(0-
12)), an~ a 14 bit physical page offset field, (JPPO(0-
13)). Length field includes 6 bits of len~th
~9
-201- .
information, (JL~G(0-5)~,. and expresses true length of
the data item to be written to or read from ~EM 10112.
~S ~PD Bus 10142 and ~OD Bus iO144 are each capable of
transferring 32 bits o~ data in a single ~EM 10112 read
or write cycle, 6 bits of length information are required
to express true length. As will be described in a
following description, JP 10114 may provide physical page
offset and length information directly to MEM 10112,
per~orms logical page number to physical page number
translations, and may perform a Protec~ion ~echanism
10230 check on the resulting physical page number. As
such, ~EM 10112 expects to receive (JPP~(0-12)~ later
than (JPPO(0-13)) and (~LNG~0-5)). (JPPO(0-13)) and
(JLNG(0~5)) should~ however, be valid during the system
clock cycle in which a JP 10114 memory request is loaded
into MEM 10112.
Operation code field provided to ME~ 10112 from JP
10114 is a 3 bit code, (JMC~D(0 2)) specifying an
operation to be ~ormed by M~M 10112. Certain operations
which JP 10114 may request of MEM 10112, and ~heir
corresponding operation codes, are:
000 = read;
001 = read and set;
010 = write;
25. 011 = error;
100 = error;
101 = read error log and reset;
110 = repair block; and,
111 = flush cache.
" .
7~3
-202-
Two bit FIU field, (JF~U(0-1)) specifies data
manipulation operations to be performed in execu~ing read
and write operations. Among the data manipulation
operations which may be requested by JP 10114, and their
FIU fields, are:~
00 = ri~ht justified, zero fill;
01 = right justified, sign extend;
10 = left justify, zero fill; and,
11 = left justify, blank fill.
For write operations, JPO Port 21010 may respond only
to the most significant bit of FIU field, that is the FIU
field bit specifying alignment~
Finally, destination field is a two bit ~ield
specifying a JP 10114 destination ~or data read from ~EM
10112. This field is ignored for write operations ~o MEM
10112. A first bit of destination field, JPMDST,
identifies the destination to be FU 10120, and the second
~ield, EBMDST, specifies EU 10120 as the destination.
JPMC.Bu~ 10147 includes dedi~ated lines for exchange
of control signals between JPO Port 21010 and JP 10}14.
Among these control signals i8 Load JO Request ~LJOR),
which is asserted by JP 10114 when J~ 10114 wishes to
load a reque~t into MEM 10112. LJOR is asserted
concurrently with presentation of the memory request to
MEM 10112 through PD Bus 10146. JO Port Available (JOPA)
is asserted by MEM 10112 when JPO Port 21010 is available
to accept a new memory request from JP 10114. I~ LJOR
and JOPA are asserted concurrently, MEM 1011~ accepts the
memory request from JP 10114 and MEM 10112 drops JOPA to
indicate ~hat memory request has been accepted. As
~7~63
-20 3-
previously discussed, MEM 10112 may assert JOPA while a
previous request is being executed and the PD Bus 10146
information, that is the memory re~uest prev.iously
provided concerning the previous request, is no longer
s required.
If JP 10114 submits a memory request and JOPA is not
asserted by ~EM 10112, MEM 101}2 does not accept the
request and JP 10114 must resubmit that request when JOPA
is asserted. Because, as described above, JPPN field of
a memory request from JP 10114 may arrive late compared
to the other fields of the request, ME~ 10112 will delay
loading of JPPN field ~or a particular request until the
next system clock cycle after the request was initially
submitted. MEM 10112 may al50 obtain this JPPN field at
the same time it is being loaded in~o the port register
by by-passing the port register.
JP 10114 may abort a memory re~uest upon asserting
Abort JP ~equest (ABJR). ABJR will be accepted by ME~
10112 during system clock cycle after accepting memory
request from JP 10114 and ~BJR will result in
cance-llation of the requested operation. ~ single ABJR
linP is provided for both JPO Port 21010 and JPI Port
21110 be~ause, as described in a following description,
ME~ 10112 may accept only a single re~uest from JP 10114,
to either JPO Port 21010 or to JPI Port 21110, during a
single system clock cycle.
,
il79~63
-204-
~ pon completion of an operand read operation
requested through JPO Port 21010 M~M 10112 may assert
either o~ two data available signals to JP 10114. These
signals are data available for FA(DAVFA) and data
available for EB~DAVEB). As previously describe~, a par~
of each read re~uest from JP 10114 includes a destination
field specifying the intended destination of the
requested data. As will be described further below, MEM
10112 tracks such destination information for read
requests and returns destination information with a
corresponding information in the form of DAVFA and
DAVEB. DAVFA indicates a destination in FU 10120 while
DAVEB indicates a destination in EU 10122. MEM 10112 may
also~assert signal zero filled (2FILL) specifying whether
read data for JPO Port 21010 is zero filled. ZFILL is
valid only when DAVEB is asserted.
~ or JPO Port 21010 write request, the associated
write data w~rd should be valid on same system clock
cycle as the request, or one system clock cycle later~
~ JP 10114 asserts Load JP Write Data (LJWD) during the
system clock cycle when JP 10114 places valid write data
on JPD.Bu~ 10142.
As previously discussed, when MEM 10112 detects an
error in servicing a JP 10114 request MEM 10112 places a
record o~ this error in MC 20116~s Error Log. When an
entry is placed in Error Log ~or either JPO Port 21010 or
IO Port 20910, MEM 10112 asserts an interrupt flag signal
. .
1~79063
--2~5--
indicating a valid Error Log entry is present. DP 10118
dete~ts this f lag signal and may direct the f lag signal
to either JP 10114 or IOS 10116 " or both O IOS 10116 or
JP 10114, as selected by ~P 10118, may ~hen read and
5 re~et Error Log and reset the f lag . ~he interrup~ f lag
signal is not necessarily directed to the requestor, JP
10114 or IOS 10116, whose request resulted in the error.
If an uncorrectible ME~ 10112 error, that is an error
in two or more bits o~ a single data word, is detected in
a read operation the incorrect data is read to JP 10114
and an invalid data signal asserted. A signal, Previous
MOD Transfex Invalid tPMODI), is asserted by ME~ 10112 on
the next system clock cycle f ollowing Pither DA~IFA or
9AVEBo PMODI is not asserted for single bit errors,
instead the data is corrected and the corrected data read
to JP-~10114~
~aving described JPO Port 21010 ' s structure, and
characteris~ics, JPI Port 21110 will be described next
below .
3.
~L _,
Referring to Fig. 211, a diagramic representation of
JPI Port 21110 is shown. JPI Port 21110 includes an
address input from PD Bus 10146 to E'IU 20120, a data
output to MOD Bus 10144 from ~qC 20116, and bi-directional
control inputs and outputs f rom MIC 20122 to JPMC Bus
10147. As previously described, a primary function of
JPI Port 21110 is the transf er of SOPs and operand NA~qEs
from MEM 10112 to JP 10114 upon request from JP 10114.
79~63
-206-
JPI Port thereby performs only read operations wherein
each read operation is a transfer of a single 32 bit word
having a word aligned addressO
Referring to JPI Port 21110 input ~rom PD Bus 10146,
read requests to ~EM 10112 by JP 10114 for SOPs and
operand NAMEs each comprise a 21 bit word address. As
described above, each JPI Port 21110 read operation i5 of
a single 32 bit word. As such, the ~ive least
significant bits of address are ignored by MEM 10112.
For the same reason, a JPI Port 21110 request to MEM
10112 does not include a length field, an operation code
field, an FIU field, or a destination code field.
Length, operation code, and FIU code ~ields are not
required since JPI Port 21110 performs o~ly a single type
of operation and dçstination code field is not required
because destination is inherent ln a JPI Port 21110
request.
The 32 bit words read ~rom ME~ 10112 in response to
JPI P~rt 21110 requests are transferred to JP 10114
through MC 20116's 32 bit output to MOD Bus 10144. As in
the case of JPO 21010 read outputs to JP 10114, JPI Port
21110 does not provide parity 1nformation to JP 10114.
Control signals exchange betwPen JP 10114 and JPI
Port 21110 through JPMC Bus 10147 include Load JI Request
(LJIR) and JI Port Available (JIP~), which operate in the
same manner as discussed with reference to JPO Port
21010. As previously described, JPO Port 21010 and JPI
~1~79Q~3
-207-
Port 21110 share a single Abort JP Request (ABJR)
command. Similarly, JPO Port 21010 and JPI Port 21110
share Previous MOD Transfer Invalid (PMODI) from MEM
10112. As described above, a ~ ort 21110 request does
not include a destination ~ield as destination is
implied. MEM 10112 does, however, provide a Data
Available Signal ~DAVFI) to JP 10114 when a word read
~rom ME~ 10112 in response to a JPI Port 21110 request is
present on MOD Bus 10144 and valid.
Having described the overall structure and operation
o~ ~E~ 10112, and the structure and operation of MEM
10112's interface to JP 10114 and IOS 10116~ the
structure and operation of FIU 201~0 MEM 10112 will next
be described in further detail.
h. ~ 2~--2~ ~Ql. ~
As previausly described, FIU 20120 performs certain
data manipulation operations, including those operations
necessary to make MEM 10112 bit addrqssable. Data
manipula~ion operations may be performed on data being
written into ~E~ 10112, for example, JP 10114 through JPD
Bus 10142 or ~rom IOS 10116 through IOM Bus 10130. Data
manipulations oparations may al50 be performed on data
being read from MEM 10112 to JPD 10114 or IOS 10116. In
case of data read to JP 10114, MOD Bus 10144 is used both
as a MEM 10112 internal bus, in trans~erring data from ~C
20116 to FIU 20120 for manipulation, and to transf er
.
~ .,
llt7~63
-208-
manipulated data ~rom ME~ 10112 to JP 10114. In case ofdata read to IOS 10116, MOD Bus 10144 is again used as
ME~ 10112 internal bus to read data ~rom MC 20116 to FIU
20120 ~or subse~uent manipulation. The manipulated data
.. 5 is then read from FIU 20120 to IOS 10116 through MIO Bus
10129.
Certain data manipulation operations which may be
performed by FIU 20120 have been previously described.
In general, a data manipulation operation consists of
four distinct operations, and FIU 20120 may manipulate
data in any possible manner which may be achieved through
performin~ any combination of these operations. These
four possible operations are selection of data to be
manipulated, rotation or shifting of that data, masking
of that data, and transfer of that manipulated data to a
selected destination. Each ~IU 20120 data input will
comprise a thirty-two bit data word and, as described
above, may be selected from input provided from JPD Bus
10142, MOD Bus 10144, and IOM Bus 10130. In certain
cases, an FIU 20120 data input may comprise two thirty-
two bit words, for example, when a cross word operation
is performed generating an ou~put comprised of bits from
each of two different thirty-two bit words. Rota~ion or
shifting of a selected thirty-two bit data word enables
bits within a selected word to be repositioned with
respect to word boundaries. When used in conjunction
with the masking operation, described momentarily,
rotation and shifting may be reiterably performed to
~79 ~ 3
-209-
trans~er any selected bits in a word to any selected
locations in that word. As will be described further
below, a maskiny opera~ion allows any selected bi~s of a
word to be affectively erased, ~hus leaving only certain
other selected bits, or certain selected bits to be
for~ed to predetermined values. A masking operation may
be performed, for example, to zero fill or sign extend
portions of a thirty-two bit word. In conjunction with a
rotation or shifting operation, a masking operation may,
for example, select a single bit of a thirty-two bit
input word, position that bit in any selected bit
location, and force all other bits of that word to zero.
Each output o~ FIU 20120 is a thirty-two bit.data word -
andr as described above, may be transferred on to ~OD Bus
10144 or onto MIO Bus 10129.. As will be described helow,
selection of a particular sequence of the above four
operations to be performed on a particular data word is
determined by control inputs provided ~rom MIC 20122.
These control inputs from ~IC 20122 are decoded and
executed by microinstruction.control logic included
within FIU 20120.
Referring to Fig. 230, a partial block diagram of FIU
: 20120 is shown. As indicated thereint FIU 20120 includes
Data Manipulation Circuitry (~MC) 23010 and FIU Control
Circuitry (FI~C) 23012. Data Manipulation Circuitry
23010 in turn includes FIUIO circuitry (FIUIO) 23014,
Data Shifter (DS) 23016, Mas~ Logic (MSK) 23018, and
Assembly Register (AR) logic 23020. Data manipulation
~î 90~3
--210--
circuitry 23010 will be described first followed by FIUC
23012. In descrbing data manipulation circuitry 23010,
FI~IO 23014 will be described ~irst, followed by DS
23016, MS~ 23013, and AR 23920, in that order.
Referring to FIUXO 23014, FIUIO 23014 comprises FIU
20120's data input and output circuitry. Job Processor
Write Data Register (JWDR) 23022, ~o 9ystem Write Data
Register (IWDR) 23024, and Write Input Data Register
(RIDR) 23026 are connected from, respectively, JP~ Bus
10142, IOM Bus 10130, and MOD Bus 10144 for receiving
data word inputs from, respectively~ JP 10114, IOS 10116,
and M<: 2nll6. JWD~ 23022, IWDR 23024 and RI~R 23026 are
each thirty-six bit registers comprised, for example, of
SN74S374 registers Data words ~ransferred into IWDR
23024 and RIDR 23026 are each, as previously described,
comprised of a thirty-two data word plus four bits of
parity. Data inputs from JP 10114 are, however, as
previously described, thirty-two bit data words without
parity. Job Processor Parity Generator (JPPG) 23028
associated with JWDR 23022 is. connected from JPD Bus
10}42 and generates four bits of parity for each dat~
input to JWDR 23022. JWDR 23022's thirty-six bit input
thereby comprises thirty-two bits of datai directly from
JPD Bus 10142, plus a corresponding four bits of parity
25 from JPPG 23028.
?
~79 ~ ~ 3
-211
Data woxds, thirty-two bits of data plus four bits of
parlty, are transferred into JWDR 23022, IWDR 23024, or
RIDR 23026 when, respectively, input enable signals Load
~WD ~LJWD), Load IWD (LIWD) or Load RID (LRID) are
S asserted. LJWD is pro~ided from Fa 10120 while LIWD and
LRID are provided from ~IC 20122.
Data words resident in JWDR 23022, IWDR 23024, or
RIDR 23026 may he selected and transferred onto FIU
20120's Internal Data (IB) Bus 23030 by output enable
10 signals JWD Enable Output (JWDEO) r IWD Enable Output
(IWDEO), an RID Enable Output (R~DEO). JWDEO, IWDEO, and
RDIEO are provided from FIUC 23012 described below.
As will be described further below, ma~ipulated data
words from DS 23016 or AR 23020 will be transferred onto,
lS respectively, Data Shifter Output (DSO) Bus 23032 or
Assembly Resister Output (ASYRO) Bus 23034 for subsequent
transfer onto ~OD Bus 10144 or ~IO Bus 10129. Each
manipulated data word appearing on DSO Bus 23032 or ASYRO
Bus 23034 will be comprised o~ 32 bits of data plus 4
bits of parity. Manipulated data words present on DSO
Bus 23032 may be transferred onto MOD Bus 10144 or MIO
Bus 10129 through, re~pectively, DSO Bus ~o MOD Bus
Driver Gate (DSMOD) 23036 or BSO BUS To ~IO Bus Driver
Gate (DS~IO) 23038. Manipulated data words present on
ASYRO Bus 23034 may be transferred onto MOD Bus 10144 or
MIO Bus 10129 through, respectively, ASYRO Bus To MOD 8us
Driver Gate (ASYMOD) 23040 or ASYRO Bus To MIO Bus Driver
Gate (ASYMIO) 23042. DS~OD 23036, DS~IO 23038, ASYMOD
/
..
,
-
~ 9 ~6 3
- -212-
23040, and ASYMIO 23042 are each comprised of, for
example, SN74S244 drivers. A manipulated data word on
DSO Bus 23032 be transferred through DSMOD 23036 to MOD
Bus 10144 when driver gate enable signal Driver Shift To
~OD (DR~S~F~OD) to DSMOD 23036 is asserted. Similarly, a
manipulated data word on DSO Bus 23032 will be
transferred through ~S~IO 23038 to MIO Bus 10129 when
driver gate enable signal Drive Shift Through ~IO Bus
(DRVSHFMIO) to DSMIO 23038 is asserted. Ma~ipulated data
words present on ASYRO Bus 23034 may be transferred onto
MOD Bus 10144 or MIO Bus 10129 when~ respectively, driver
gate enable signal Drive Assembly To Mod Bus (D~VASYMOD)
to ASYMOD 23040 or Driv~ Assembly To MIO Bus (DRVASYMIO)
to ASY~IO 23042 are asserted. DRVS~FMOD, DRVSHFMIO,
DRVASYMOD, and DRVASYMIO are provided, as described
below, from FIUC 23012.
Registers IARM 23044 and BARMR 23046, which will be
described further in a following description of DP 10118,
are used by ~P 10118 to, respectively, write data words
onto IB 23030 and to Read data word~ ~rom MOD Bus 10144,
for example manipulated data words from ~IU 20120. Data
word written into IARMR 23044 from DP 10118, that is 32
bits of data and 4 bits of parity, will be transferred
onto IB Bus 23030 when register enable output signal IARM
enable output (IARMEO) from FIUC 23012 is asserted.
Similarly, a data word present on MOD ~us 10144,
comprising 32 bits of data plus 4 bits of parity, will be
written into BARMR 23046 when load enable signal Load
- ` :
9 ~ 63
-213-
BARMR (LDBARMR) to BARMR 23046 is asserted by MIC 20122.
A data word written into BA~MR 23046 from MOD Bus 10144
may then subsequently be read to DP 10118. IARMR 23044
and BARMR 23046 are similar to JWDR 23022, IW9R 23024,
and IR~R 23026 and may.be comprised, for example, of
SN74S299 registers.
~ eferring finally to IO Parity ChPck Circuit (IOPC)
23048, IOPC 23048 is connected from IB Bus 23030 to
receive each data word, that is 32 bits of data plus 4
bits of parity, appearing on IB Bus 23030. IOPC 23048
confirms parity and data validity of each data word
appearing on IB Bus 23030 and, in partioular, determines
validity of parity and data of data words written into
FIU 20120 from IOS 10116. IOPC 23048 generates output
Parity Error (PER), previously discussed, indicating a
parity error in data words from IOS 10116.
Referring to DS 23016, DS 23016 includes Byte Nibble
Logic (BYNL) 23050, Parity Rotation Logic (PRL) 23052,
and Bit Scale Logic (BSL) 23054. BY~L 23050, PRL 23052,
and BSL 23054 may respectively be comprised of, for
example, 25S10 shifters. BYNL 23050 is connected from IB
Bus 23030 ~or ~eceivin~ and shifting ~he 32 data bits of
a data word selected and transferred onto IB Bus 23030.
PRL 23052 is a 4 bit register similarly connected from IB
Bus 23030 to receive and shift the 4 parity bits of a
data word selected and ~ransferred onto IB Bus 23030.
Outputs of BYNL 23050 and P~L 23052 are both connected
onto DSO Bus 23032, thus providing a 36 bit FIU 20120
~79~63
-214-
data word output directly from BYNL 23050 and PRL 23052.
BYNL 23050's 32 bit data output is also connected to BSL
23054's input. BSL 23054's 32 bit output is in turn
provided to M5R 23018.
As previously described, DS 23016 prforms data
manipulation operations involving shi~tin~ of bits within
a data word. In general, data shift opera~ions perform d
by DS 23016 are rotations wherein data bits are right
shi~ted, with least significant bits of data word being
- 10 shifted into most significant bit position and most
significant bits being translated towards least
significant bit positions. DS 23016 rotation operations
are performed in two stages. First stage is performed by
BYNL 23050 and PRL 23052 and comprises right rotations on
a nibble basls (a nibble is de~ined as 4 bits of data).
That is, BYNL 23050 right shifts a data word by an
integral number of 4 bit increments. A right rotation on
a nibble by nib~le ~asis mayr for example, be performed
when RM 20722 asserts FLIP~A~F previously described.
FLIP~AL~ is asserted for IOS 10116 half word read
operati~ns wherein the request data resides in the most
significant 16 bits of a data word rom ~C 20116. BYNL
23050 will perform a right rotation of 4 nibble~ to
transfer the desired 16 bi~s of data into the least
significant 16 bits of BYNL 23050's output. Resultin~
BYNR 23050 output, together P~L 23052's parity bit output
would then be transferred through DSO 23050 to MIO Bus
10129. In addition to performing data Ahifting
3 ~79(~63
-215-
operations, DS 23016 may transfer a data word, that is
the 32 bits o data, directly to MSR 23018 when data
manipulation to be performe~ does not require data
shifting, that is shifts of 0 bi~s may be performed.
Because data bits are shifted by 8YNL 23050 on a
nibble basis, the relationship between the 32 data bits
of a word and the corresponding 4 parity bits may be
maintained if parity bits are similarly right rotated by
an amount corresponding to right rotation of data bits.
This relationship is true if the data word is shifted in
multiples o~ 2 nibbles, that is 8 bits or l byte. PRL
23052 right rotates the 4 parity bits of a data word by
an amount corresponding to right rotation of the
corresponding 32 data bits in BY~L 23050~ Right rotated
outputs of BYNL 23050 and ~RL 2305~ therefore comprise a
valid data word having 32 bits of data and 4 bits of
parity wherein ~he parity bits are oorrectly related to
the data bits. A right rotated data word output from
BY~L 23050 and PRL 23052 may be transferred onto DSO Bus
23032 for subsequent ~ransfer to MOD ~us 10144 or ~IO Bus
10129 as described above. DSO 23032 is used as F~U
20120's output data path ~or byte write operations and
Nrotate read" operations wherein the re~uired
manipulation of a particular data word requires only an
integral numer of right rotations by bytes. Amount of
right rotation of 32 bits of data i~ ~YNL 23050 and 4
bits of parity in PRL 23052 is controlled by input signal
shift (S~PT) (0-2) to BYNL 23050 and PRL 23052. As will
~J
90G3
--21 6--
be described below, S~ (0-2) is generated, together
with SHFT (3-4) controlling BSL 23054, by FIUC 23012.
BYNL 23050 and PRL 23052, like BSL 23054 described below,
are parallel shift lo~ic chips and entire rotation
operation o~ BY~L 23050 and PRL 23052 or ~SL 23054 may be
- performed in a single clock cycle.
Second stage o rotatlon is performed by BSL 23054
which, as described above, receives the 32 data bits of a
data word from BY~L 23050. BSL 23054 performs right
rotation cn a bit by bit basis with the shift amount
being selectable between 0-3 bits. Therefore, BSL 23054
may rotate bits through nibble boundaries. BYNL 23050
and BSL 23054 there~ore comprise a data shifting circuit
capable of performing bit-by-bit right rotation by an
amount from 1 bit to a full 32 bit right rotation.
Referring now to MSK 23018, MSR 23018 is comprised of
5 32 bit Mask Word Generators ~MWG's) 23056 to 23064.
~SR 23018 generates a 32 bit output to AR 23020 by
selectively combining 32 bit mask word outputs of ~W~'s
23056 to 23064. Each mask word generated by one of MWG's
23056 to 23064 is effectively comprised a bit by bit
combination of a set of enabling bits and a pre-
determined 32 bit mask wordr generated by FIUC 23012 and
MIC 20122. MWG's 23058 to 23064 are each comprised of
for example, open collec~or NAND gates for performing
~hese functions, while NWG 23056 is comprised o a PRO~.
~1~79~63
` --21 7 -
As just described, outputs of MWG's 23056 to 23064
are all open collector circuits so that any selected
combination of mask word outputs from ~WG's 23056 to
23064 may be ORed together to comprise the 32 bit output
of ~S~ 23018.
. MWG 23056 to MWG 23064 generate, respectively, mask
word outputs Locked Bit Word (LBW) (0-31), Sign Extended
Word (SEW) (0-31), Data ~ask Word (DMW) (0-31), Blank
Fill Word (BWF) (0-31), and Assembly Register Output
(ARO) ~0-31). Referring firs~ to ~WG 23064 and ARO (0-
31), the contents of Assembly Register (ASYMR) 23066 in
AR ~3020 are passed through MWG 23064 upon assertion of
enabling signal Assembly Output Register (ASYMOR)o ARO
(0-31) is thereby a copy o~ the contents of ASYMR 23066
and MWG 23064 allows the contents of A~YMR 23066 to be
ORed with the selected combination of LBW (0-31), S~W (0-
31), DMW (0-31), or BFW (0-31).
DMW (0-31) from MWG 23.060 is generated by ANDing
enable Input Data Mask (DMSR) (0 31~ with the 32 bit
output of DS 23016~ DMS~ (0-31) is a 32 bit enabling
word generated, as described below, by FIUC 23012. FIUC
23012 may generate 4 different DM5R (0-31) patternsO
Referring to Fig. 231, the 4 DMSKs (0-31) which may be
generated by FIUC 20132 are shown. DMS~A (0-31) is shown
in Line A of Fig. 231. In DMS~A (0-31) all bits to the
left of but not including a bit designated by Left Bit
Address ~LBA) and all bits to the right of and not
including a bit designated by Right Bit Address (RBA) are
~7g~63
-218-
0. All bits between, and including, those bits
designated by LBA and RBA are 1'sO DMSKB ~0-311 is shown
in Line B o Fig. 231 and is DMSgA (0-31) inverted.
DMSRC ~0-31) and D~SRD (0-31) are shown, respectively, in
Lines C and D of Fig. 231 and are comprised of, ..
respectively, all 0's or all l's. As stated above DMSR
(0-31) is ANDed with the 32 bit output of DS 23016. As
such, DMSKC (0-31) may be used, for example, to inhibit
DS:23016's output while DMS~D (0~31) may be used, for
example, to pass DS 23016's output to A~ 23020. DMSRA
(0-31) and DMSKB (0-31) may be used, for example, to gate
selected portions of DS 23016's output to ~R 23020 where,
for example, the selected portions of DS 23016's output
may be ORed with other mask word outputs MS~ 23018.
Referring next to MWG 230~2, MWG 23062 generates BFW
(0-31j. BFW (0-31) is used in a particular operation
wherein 32 bit data words containing 1 to 4 ASCII blanks
are requieed to be genPrated wherein 1 bit/byte contains
a logic one and remaining bits contain logic zeros. In
this case, the ASCII blank by~es may contain logic l's in
bit positions 2, 10, 18, and 26.
Referring again to Fig. 231, Line E therein shows 32
bit right mask (RMS~) (0-31) which may be generated by
FIUC 23012. In the most general case, RMS~ contains
zeros in all bit positions to the left of and including a
bit position designated by RBA. When used in a blank
fill operation, bit positions 2, 10, 18, and 26 may be
selected to contain logic l's depending upon those byte
positions containing logic l's, that is in those bytes
63
~219-
containing ASCII blanks~ these bytes to the right of RBA
are determined by R~S~ ~0-31). R~SK (0-31) is enabled
through MWG 23062 as BWF tO-31) when MWG 23062 is enabled
by blank fill (BL~RFILL) provided from FIU 23012.
As described above, MWG's 23058 to 23064 and in
particular MWG's 23060 and MWG 23062 are NAND gate
operations. Therefore, the outputs of MWGs 23056 through
23064 are active low signals. The in~erted output of
AS~MR 23066 is used as an output to ASYRO 23034 to invert
these outputs to active high.
MWG 23058, generating SEW (0-31), is used in
generating sign extended or filled words. In sign
extended words, all bit spaces to the left of the most
significant ~it of a 32 bit data word are filled with the
sign bit of the data contained therein, the left most
bits of the 32 bit word are filled with l's or O's
depending on whether that word's sign bi~ indicates that
the data contained therein is a po~itive or negative
number.
Sign Select ~ultiplexor (SIGNSEL) 23066 is connected
to receive the 32 data bits of a word present on IB Bus
23030. Sign Select (SGNSEL) (0-4) to SIGNSEL 23066 is
derived from SBA (0 4), that is from SaA Bus 21226 from
PRMUX 20720. As previously described, SBA (0-4) is
2S Starting Bit Addre~s identifying the first ox most
significant bit of a data word. When a data word
contains a signed number, most significant bit contains
sign bit of that number. SGNSEL (0-4) input to SIGNSEL
23066 is used as a selection input and, when SIGNSEL is
79(:P63
--220--
enabled by Sign Extend (SIGNEXT) from FIU 23012, selects
the sign bit on IB Bus 23030 and provides that sign bi~
as an input to MWG 23058.
Sign bit input to MWG 23058 is ~NDed with each bit of
left hand masls (LMSR) (0-31) from FIUC 23012. Referring
again to Fig~, 231, LMSK ~0-31) is shown on Line ~
thereof. LMSK (0-31) contains all 0's to the right of
and including the bit space identified by LBA and l's in
all bit spaces to the left of that bit space identified
by LBA. SEW (0-31~ will therefore contain sign bit in
all bit spaces -to the left of the most significant bit of
the data word present on output of ~qW~ 23058.- The data
word on IB Bus 23030 may then be passed through DS 23016
and subjected to a DMSR operation wherein all bits to the
left of the most signi~icant bit are forced to 0. SEW
(0-31) and. DMW (0-31) outputs of ~WG's 23058 and 23060
may then be ORed to provide the desired find extended
word outputO
LBW (0-31), provided by MWG 23056, is used in locked
bit operations wherein the most significant data bit of a
data word is in MEM 10112 forced to logic 1. SIGNSEL (0-
4) is an address input to ~WG 23056 and, as previously
descxibed, indicates most significant da~a bit of a data
word present on an B Bus 23030. MWG 23056 is enabled by
input Lock (LOC~) from FIUC 23012 and the resulting LBW
(0-31) will contain a single logic 1 in the bit space of
the most significant data bit of the data word present on
IB Bus 23030. The data word present on IB Bus 23030 may
9 ~ 3
-221-
then be passed through DS 23016 and MWG 23060 to be ORed
with LBW (0~31) so that that data words most significant
data bit is forced to lo~ic 1.
Referring to AR 23020, AR 23020 includes ASYMR 23066,
which may be comprised for exam~le of a S~74S175
registers, and A~sembly Regis~er Parity Generator (ASYPG)
23070. As previously described~ ASYMR 23066 is connected
from MSK 23018 32 bit output. A 32 bit word present on
MSK 23018's output will be transferred into ASY~R 23066
when ASYMR 23066 is enabled by Assembly Register Load
(ASY~LD) from MIC 20122. The 32 bit word generated
through DS 23016 and ~5R 23018 will then be presen~ on
ASYRO Bus 23034 and may, as described above, then be
transferred onto MOD Bus 10144 or MIO Bus 10129. ASYPG
23070 is connected from ASYMR 23066 32 bit output and
will generate 4 parity bi~s for the 32 ~it word presently
on the 32 data lines of ASYRO Bus 23034. ASYPG 23070's 4
bit parity output is bused on the 4 parity bit lines of
ASYRO Bus 23034 and accompany the 32 bit data word
present thereon.
~ a~ing described structure and operation of Data
Manipulation Circuitry 23010, FIUC 23012 will be
described next below.
Re~erring again to Fig. 230, FIUC 23012 provides
pipelined microinstruction control of FIU 20120. That
is, control signals are received ~rom MIC 20122 during a
first clock cycle and certain of the control signals are
decoded by microinstruction logic to generate further
~79~63
-222-
FIUC 23012 control signals, Durins the second clock
cycle, control signals received and generated during
first clock cycle are provided to DMC 23010, some of
which are further dècoded to provide yet other control
slgnals to control operation of FIUC 23012. FI~C 23012
includes Initial Decode Logic ~IDL) 23074, Pipeline
Registers (PPLR) 23072, Final Decoding Logic (FDL) 23076,
and Enable Signal Pipeline Register (ESPR) 23098 with
~ Enable Signal Decode Logic (ESDL) 23099.
IDL 23074 and Control Pipeline Register (CPR) 23084
o PPLR 23072 are connected from control outputs of MIC
20122 to receive control signals therefrom during a first
clock cycle as described above. IDL 23074 provides
outputs to control pipeline registers Right Bit Address
Register (RBAR) 23086, Left Bit Address Register (LBAR)
23088 and Shift Register (SHFR) 23090 o~ PPLR 23072~ CPR
23084 and S~FR 23050 provide control outputs direstly to
DMC 23010. As described above these outputs control DMC
23010 during second clock cycle.
CPR 23084, RBAR 23086, and LBAR 23088 provide outputs
to FDL 23076 during second clock cycle and FDL 23076 in
turn provides certain outputs directly to DMC 23010.
ESPR 23098 and ESDL 23039 receive enable and control
signals from MIC 20122 and in turn provide enable and
control signals to DMC 23010 and certain other portions
of ME~ 10112 circuitry.
63
-223--
IDL 23074 and FDL 23076 may be comprised, for
example, of PROMs. CPR 23084, RBAR 23086r LBAR 23088,
S~FR 23090~ and ESPR 23098 may be comprised, for example,
of 5N74S194 registers. ESDL 23099 may be comprised of,
i~or example, compatible decoders, such as logic gates.
Rei~erring first to IDL 2307~, IDL 23074 perforTns an
initial decoding of circuitry control signals ~rom MIC
2012~ and provides further control signals used by FIUC
23012 in controlling FIU 20120. IDL 23074 is comprised
of read-only memory arrays Right Bit Address Decoding
Logic (RBADL~ 23078, Left Bit Address Decoding Logic
(LBADL) 23080, and Shift Amount Decoding Logic (S~FAMTDL)
23082. RBADL 23û78 receives, as address inputs, Final
Bit Address (FBA) (9--4), Bit Length Number (BLN) (0-4),
and Starting Bit Address (SBA) (0-4). FBA, BI,N and SBA
define, respectively, the final bit, length, and starting
bit of a re~uested data i~em as previously discussed with
reference to PR~qUX 20720. RBADL 23078 also receives chip
select enable signals Address Translation Chip Select
(ATCS~ 00, 01, 02, 03, 04, and 15 from NIC 20122 and, in
particular, Rll 20722. When FIU 20120 is required to
execute certain MSK 23û18 operations, inputs FBA (0-4),
BLN (0-4~, and SBA (0-4~, toge~her with an ATCS input,
are provided to ~BADL 23078 from ~IC 201~2. RBADL 23078
in turn provides output RBA (Right Bit Address) (0-4),
which has been described above with reference to DMS~t (0-
31) and R~SSR (0-31). LBADL 23080 is similar to RBADL
23078 and is provided with inputs BL~ (0-4), FBA (0-4),
i~'79~3
-224-
S8A (0-4), and ATCS 06, 07, 08, 09, and 05 from ~IC
20122. Again, for certain ~SR 23018 operations, LBADL
23080 will generate Left Bit Address ~LBA) (0-4), which
has been previously discussed above with reference to
DMS~ (0-31) and LMSR (0-31).
~BA ~0-4) and LBA ~0-4) are, respectively,
transferred to RBAR 23086 and LBAR 23088 at start of
second clock cycle by Pipeline ~oad Enable signal PIPELD
provided from ~IC 20122. RBAR 23086 and LBAR 23088 in
turn respectively provide outputs Register Rlght Address
(RRAD) (0-4) and Register Left Address ~RLAD) ~0-4) as
address inputs to Right Mask Decode Logic (R~SRDL) 23092,
Left ~ask Decode Logic ~rMSKDL~ 23094, and FDL 23076 at
start of second clock cycle. R~AD ~0-4j and RLAD ~0-4)
correspond respe~tively to RBA (0-4) and LBA (0-4).
RMSKD~ 23092 and L~lS~DL 23094 are ROM arrays, having,
as just described, RRAD (0-4) and RLAD ~0-4) as,
respectively, address inpu~s and ~ask Enable (~ISKENBL)
from CPR 23084 as enable inputsO Together, RMSKDh 23092
20 and LMSKDL 23094 generate, respectively, RMSR (0-31) and
LMSK ~0-31) to MSK 23018. R~SK (0-31) and L~SR (0-31)
are provided as inpu~s to Exclusive Or/Exclusive Nor
gating (XOR/XNOR) 23096. XOR/X~OR 23096 also receives
enable and selection signal Out Mask (OUTMSR) ~rom CPR
25 23084O RMSR ~0031) and L~Sg ~0-31) inputs to XOR/XNOR
23096 are used, as selected by OUTMSK from CPR 23084, to
generate a selected DMSK ~0-31) as shown in Fig. 231.
D~SR ~0-31) output of XOR/X~OR 23096 is provided, as
described above, to ~SK 23018.
11~;'9(~63
--225--
Referring again to IDL 23074, S~FA~qTBL 23082 deco~es
certain control inputs f rom ~qIC 20122 to generate,
through SHFR 23090, control inputs SE~FT (0-4) and SGNSEL
(0-4) to, respectively, DS 23016, SIGNSEL 23068 and ~WG
230560 Address inputs to the PROMs comp~ising S~FA~q~3L
23082 include FBA (0-4), SBA (0-4), and FLIPHALF
(FLIPEIALF~ from MIC 20122. ~BA (0-4) and SBA (0-4) have
been descr ibed above . FLIPHALF is a control signal
indicating that, as described above, tha~ 16 bits of data
re~uested by IOS 10116 resides in the upper half o~ a 32
bit data word and causes those 16 bits to be transf erred
to the lower hal~ of FIU 20120 i s output data word onto
MIO Bus 1012~. MIC 20122 also provides chip enable
signals ATCS 10, 11, 12, 13, and 14. Upon receiving
these control inputs from ~qIC 20122, SHFAMTDL 23082
generates an output shift amount (SHF~MT) (0-4) which,
together with SBA (0-4) from MIC 20122, is transferred
into S~IF~ 23090 by PIPELD at start of second clock
cycle. S~FR 23090 then provides corresponding outputs
SaFT (0-4) and SIG~SEL (0-4). As described above,
SIG~SEI, (0-4) are provided to SIG~SEL 23068 and ~qWG 23056
- and MS~ 23018. SHFT (0-4) is provided as SEIFT ~0-2) and
SEIFT (3-4) to, respectively, BY~L 23050 and BSL 230S4 and
DS 23 016 .
Referring to CPR 23084, as described above certain
control signals are provided directly to FIU 20120
circuitry without being decoded by IDL 23074 or FDL
23076. Inputs to CPR 23084 include Sign Extension
79{~63
-226-
(SIGNEX~) and Lock (LOCK) indicating, respectively, that
FIU 20120 is to perform a sign extension operation
through MWG 23058 or a lock bit word operation through
MWG 23056. CPR 23084 provides corresponding outputs
SIGNEXT and LOCR to MSK 23018 to select these
operations. Input Assembly Output Register (ASYMOR) and
Blank Fill (BLANKFILL) are passed through CPR 23084 as
ASYMOR and BLANKFILL to, respectively, MWG 23064 and MWG
23062 to select the output of ASYMR 23066 as a mask or to
indicate that MSR 23018 is to generate a blank filled
word through MWG 23062. Inputs OUTMSX and MSRENBL ~o CPR
23084 are provided, as discussed above, as enable signals
OUT~IS~ and ~SKE~BL to, respectively, EXOR/ENOR 23096 and
R~SSEtDL 23092 and Ll!qSKBL 23094 and generating RMSR ~0-31),
LMSK (0-31), and DMSR (0-31) as described above.
Referring finally to ESPR 23098 and ES~L 23099, ESPR
23098 and PPLR 23072 together comprise a pipeline
register and ESDL 23099 decoding logic for providing
enable signals to FIU 20120 and other ME~ 10112
circuitry. ESPR 23098 receives inputs Drive MOD Bus
(DRVMOD) (0-1), Drive MIO Bus (~RVMIO) (0-1), and Enable
Register (ENREG) (0-1) from MIC 20122 as previously
described. DRVMOD (0-1), DRVMIO (b-l), and ENREG (0-1)
are transferred into ESPR 23098 by PIPELD as previously
described with reference to PPLR 23072. ESPR 23098
provides corresponding outputs to ESDL 23099, which in
turn decodes DRVMOD (0-1), DRVMIO (0-1), and ENREG (0-1)
to provide enable signals to FIU 20120 and other MEM
- " ~
-227-
10112 circuitry~ Outputs DRVSHFMOD, DRVASYMOD,
DRVSHFMIOr and DRVASY~IO are provided to DSMOD 23036,
DSMIO 23038, ASYMOD 23040, ASYMIO 23042, and FIUIO 23014
to control transfer of FIU 20120 manipulated data words
onto ~OD Bus 10144 and MIO Bus 10129. Outputs IARMEO,
JWDEO, IWDEO, and RIDEO are provided as output enable
signals to IARMR 23044, JWDR 23022, IWDR 23024, and RIDR
23026 to transfer ~he contents of these registers onto I~
Bus 23030 as previously described. Outputs DRVCAMOD,
D~VAMIO, DRVBYMOD, and DRVBYMIO are provided to ~C 20116
for use in controlling transfer of information onto MOD
Bus 10144 and MIO Bus 10129.
~aving described the structure and operation of MEM
10112 above, the structure and operation of FU 10120 will
be described next below.
. B.
As has been previously describéd, FU 10120 is an
independently operating, microcode controlled machine
comprising, together with EU 10122r CS 10110~s
micromac.hine for executing user's programs. Principal
functions of FU 10120 include: (1) Fe~-ching and
interpreting instructions, that is SINs comprising SOPs
and Names, and data from MEM 10112 for use by FU 10120
and EU 10122; (2~ Organizing and controlling flow and
execution of user programs; (3) Initiating EU 10122
operations; (4) Performing arithme~ic and logic
operations on data; ~5) Controlling transfer of data from
79(~6
-228-
FU 10120 and FU 10122 to MEM 10112; and, (6) ~laintaining
certain stac~ register mechanisms. Among these stack and
register mechanisms are Name Cache (NC) 10226, Address
Translation Cache (ATC) 10228, Protection Cache ~PC)
10234, Architec~ural Base Registers (~BRs) 10364, ~icro-
Control Registers (mCRs~ 10366, Micro-Stack (~IS) 10368,
Moni~or Stack (~OSJ 10370 of General Registe~ File (GR~
10354, Micro-Stack Pointer Registe Mechanism (MISPR)
10356, and Return Control Word Stack (RC~S) 10358~ In
addition to maintaining these FU 10120 resident stack and
register mechanisms, FU 10120 generates and maintains, in
whole or part, certain ~EM 10112 residen data
structures. Among these ~EM 10112 resident data
structures are Memory ~ash Table (M~T) 10716 and ~emory
Frame Table ~MFT) 10718, Working Set Matrix (WSM) 10720,
Virtual Memory Management Request Queue (VMMRQ) 10721,
Active Object Table (AO$) 10712, Active Subject Table
(AST) 10914, and Virtual Processor State Blocks (VPSBs)
10218. In addition, a primary function of FU 10120 is
the generation and manipulation of logical descriptors
which, as previously described, are the basis of CS
10110's internal addressing structure. Aq will be
described further below, while FU 10120lS internal
structure and operation allows FU 10120 to execute
arithmetic and logic operations, FU 10120's structure
includes certain features to expedite generation and
manipulation of logical descriptors.
- J
9~63
-229
Referring to Fig. 202, a partial block diagram of FU
10120 is shown. To enhance clarity of presentation,
certain interconnections within FU 10120, and between FU
10120 and EU 10122 and MEM 10112 are not shown by line
connections but, as described further below, are
otherwise indicated, such as by common signal names.
;lajor functional elements of FU 10120 include Descriptor
Prot essor (DE5P) Z0210, MEM 10112 Interface Logic
(MEMINT) 20212, and Fetch Unit Control Logic (FUCTL)
20214. DSP 20210 is, in general, an arithmetic and logi
unit for generating and manipulating en~ries for MEM
10112 and FU 10120 resident stack mechanisms and caches 9
as described above, and, in particular, for generation
and manipulation of logical descriptors. In addition, as
stated above, DSP 20210 IS a general purpose Central
Processor Unit (CPU) capable of performing certain
arithmetic and logic functions.
DESP 20210 includes AON Processor (AONP) 20216,
Offset Processor (OFFP) 20218, Leng~h Processor (LENP)
20220. OFFP 20218 comprises a general, 32 bit CPU with
additional structure to optimize generation and
manipulation of offse~ fields of logical descxiptors~
AONP 20216 and LENP 20220 co~prise, respectively,
processors for generation and manipulation of AON and
leng~h fields of logical descriptors and may be used in
conjuction with OFFP 20218 for execution of certain
arithmetic and logical operations. DESP 20210 includes
GRF 10354, which in turn include Global Registers (GRs)
10360 and Stack Registers (SRs) 10362. As previously
9 ~ 3
-230-
described, GR's 10360 includes ABRs 10364 and mCRs 10366
while SRs 10362. includes MIS 10368 and MOS 10370.
MEMINT 20212 comprises FU 10120's interface to ~EM
10112 ~or providing Physical De~criptors (physical
addresses) to ~EM 10~12 to read SINs and data from and
write data to MEM 10112. MEMINT 20212 includes, among
other logic çircuitry, MC 10226, ATC 10228, and PC 10234.
FUCTL 20214 controls fetching of SI~s and data from
MEM 10112 and provides sequences of microinstructions for
control of FU 10120 and EU 10122 in response to SOPs.
FUCTL 20214 provides Name inputs to MC 10226 for
subsaquent fetching of corresponding data from MEM
10112. FUCTL 20214 includes r in part, MISPR 10356, RCWS
10358, Fetch Unit S-Interpreter Dispatch Table (FUSDT)
11010, and Fetch Unit S-Interpreter Table (FUSITT) 11012.
Having described the overall structure of FU 10120,
in particular with regard to previous descriptions in
Chapter 1 of this description, DESP 20210, MEMINT 20212,
and FUCTL 20214 will be described in further detail
below, and in that order~
As described above, DESP 20210 comprises a 32 bit CPU
for performing all usual arithmetic and logic operations
on data. In addition, a primary function of DESP 20210
is generation and manipulation of entries forr for
example, Name Tables (NTs) 103S0, ATC 10228, and PC
10234, and generation and manipulation of logical
9~63
-231-
descriptors. As previously ~escribed, with reference to
CS 10110 addressing structure, logical descriptors are
logical addresses, or pointers, to data stored in MEM
10112. Logical descriptors are used, ~or example, as
architectural base pointers or microcontrol pointers in
ABRs 10364 and mCRs 10366 as shown in Fig. ~03, or as
linkage and local pointers of Procedure Frames 10412 as
shown in Fig. 104. In a further example, logical
descriptors generated by DESP 20210 and corresponding to
10 certain operand Names are stored in MC 10226, where they
are subsequently accessed by those Names appearing in
SI~ fetched from MEM 10112 to provide rapid translation
between operand Names and corresponding logical
descriptors.
As has been previously discussed with reference to CS
10110 addressing structure, logical descriptors provided
to ATU 10228, from DESP 20210 or NC 10226, are translated
by ATU 10228 to physical descriptors which are actual
physical addresses of corresp~nding data stored in MEM
10112. That data subse~uently is provided to JP 10114,
and in particular to FU 10120 or EU 10122, throug~ MOD
Bus 10144.
As has been previously discussed with reference to
~EM 10112, each data read to JP 10114 from ~IE~ 10112 may
contain up to 32 bits of information~ If a particular
data item referenced by a logical descriptor contains
more than 32 bits of data, DESP 20210 will, as described
further below, generate successive logical descriptors,
9~3
--23 2 -
each logical descriptor referring to 32 bits or less of
information, until the entire data i~em has been read
from MEM 10112. In this regard, it should be noted that
~C 10226 may contain logical descriptors only for data
items of 255 bits or less in length. ~11 requests to ~EM
10112 for data items greater than 32 bits in 1 ength are
generated by DESP 20210. Most of data items operated on
by CS 10110 will, however, be 32 bits or less in length
so that ~C 10226 is capable of handling most operand
~ames to logical descriptor translations.
As described a~ove, DESP 20210 includes AONP 20216,
OFFP 20218, and LENP 20220. OFFP 20218 comprises a
general purpose 32 bit CPU with additional logic
circuitry for generating and manipulating table and cache
entries, as described above, and for generating and
manipulating offset fields of AON pointers and logical
descriptors. AO~P 20216 and LENP 20220 comprise logic
circuitry for generating and manipulating, respectively,
AON and length fields of AON pointers and losical
descriptors. As indicated in Fig. 202, GRF 10354 is
vertically divided in three parts. A first part resides
in A~OP 20216 and, in additon to random data, contains
AON fields of logical descriptors. Second and third
parts reside, respectively, in OFFP 20218 and LENP 20220
and, in addition to containing random data, respectively
contain offset and length fields of logical descrip~ors.
AON, Offset, and length portions of GRF 10354 residing
respectively in AONP 20216, OFFP 20218, and LENP 20220
~ ,!
9~63
-233- -
are designated, respectively, as AONGRF, O~FGRF, and
LE~GRF. AONGRF portion of GRF lG354 i5 28 bits wide
while OFFGRF and LENGRF portions of GRF 10354 are 32 bits
in width. Al~hough shown as divided vertically into
three parts, GRF 10354 is addressed and operates as a
unitary structure. That is, a particular address
provided to GR~ 10354 will address corresponding
horizontal segments of each of GRF 10354's three sections
residing in AONP 20216, OFFP 20218, and LENP 20220.
a. ~ rocesso~ io~ 9e~ t--
Referring first to OFFP 20218, in addition to being a
32 bit CPU and generating and manipulating table and
cache entrie~ and offset fields of AON pointers and
logical descriptors, OFFP 202i8 is DESP 20210's primary
path for receiving data from and transferring data to MEM
10112. OFFP 20218 includes Offset Input Select
Multiplexer (OFFSEL) 20238, OFFGRF 20234, Offset
Multiplexer Logic (OFFMUX) 20240, Offset ALV (OFFALU)
20242, and Offset ALU A Inputs ~ultiplexer (OFFALUSA)
20244.
OFFSEL 20238 has first and second 32 bit data inputs
conne~ted from, respectively, MOD Bus 10144 and JPD Bus
10142~ OFFSEL 20238 has a third 32 bit data input
connected from a first ou.tput of OFFALU 20242, a fourth
28 bit data Lnput connected from a first output of AONGRF
20232, and a ~ifth 32 bit data input connected from
OFFSET Bus 20228. OFFSEL 20238 has a first 32 bit output
connected to input of OFFGRF 20234 and a second 32 bit
7~63
-23 ~-
output connected to a first input of OFFMUX 20240.
OFFMUX 20240 has second and third 32 bit data inputs
connected from, respec~ively, MOD Bus 10144 and JP~ Bus
10142. OFF~UX 20240 also has a fourth 5 bit data input
S connected from Bias Logic (BIAS) 20246 and LENP 20220,
described ~urther below, and fi~th 16 bit data input
connected from NA~E Bus 20224. Thirty-two bit data
output of OFFGRF 20234 and first 32 bit data output of
OFFMUX 20240 are connected to, respectively, first and
second data inputs of OFFALUSA 20244. A first 32 bit
data output of OFFALUSA 20244 and a second 32 bit data
output of OFFMUX 20240 are connected, re~pectively, to
first and second data inputs of OFFALU 20242. A second
32 bit data output of OFF~LUSA 20244 is connected to
OFFSET Bus 20228. A first 32 bit data output of OFF~LU
20242 is connected to JP~ Bus 10142, to a first input of
AON Input Select Multiplexer (AONSEL) 20248 and AONP
20216, and, as described above, to a third input of
OFFSEL 20238. A second 32 bit data output of OFFALU
20242 is connected to O~FSET Bus 20228 and third 16 bit
output is connected to NAME Bus 20224.
b.
Referring to AONP 20216, a primary func~ion of AONP
20216 is that o~ containing AON ~ields of AON pointers
and logical descriptors. In addi~ion, those portions of
AONG~F 20232 not otherwise o~cupied by AON poi~ters and
logical descriptors may be used as a 28 bit wide general
register area by JP 10114. These portions o~ AONG~
9(~63
~235-
20232 may be so used either alone or in conjunction wih
corresponding portions of OF~GRF 20234 and LENGRF 20236.
AONP 20216 includes AONSEL 20248 and AONGRF 20232. As
previously describedr a f irst 32 bit data input AO~SEL
20248 is connected from a first data output of OFEALU
20242. A second 28 bit data input of AONSEL 20248 is
connected from 28 bit output of AON~RF 20232 and from AON
Bus 20230. A third 28 bit data input of AONSEL 20248 is
connected from logic 7.ero, that is a 28 bit input wherein
each input bit is set to logic zero. Twenty-eight bit
data output of AONSEL 20248 is connected to da~a input of
~ONGRE 20232. As jus~ described, 28 bit data output of
AONGRF 20232 is connec~ed to second data input of AONSEL
20248, and is connected to AON Bus 20230.
c. ~
Referring finally to LE~P 20220, a primary ~unction
of LENP 20220 is the generation manipulation of length
fields of AO~ pointers and physical descriptors. In
additionr LENGRF 20236 may be used, in part, either alone
or in conjunction with corresponding address spaces of
A~NGRF 20232 and OFFGRF 20234, as general registers for
storage of data. LE~P 20220 includes Length Input Select
Multiplexer ~LENSEL) 20250, LE~GRF 20236, BIAS 20246, and
L~ngt~ ALU (LENALU) 20252. LENSEL 20250 has first and
second data inputs connected from, respectively, LENGTH
Bus 20226 and OFFSET Bus 20228. LENGT~ Bus 20226 is
eight data bits, zero filled while OFFSET Bus 20228 is 32
data bits. LENSEL 20250 has a third 32 bit data input
'
1 ~ ~9 ~6 3
-236-
connected from data output of LE~ALU 20252. Thirty-two
bit data output of LENSEL 20250 is connected to data
input of LENGRF 20236 and to a ~irst data input of BIAS
20246. Second and third 32 bit data inputs o~ BIAS 20246
axe c~nnec~ed from, respectively, Constant (C) and
Literal (L) outputs of F~SITT 11012 as will be described
further below. Thirty-two bits data output of LE~GRF
20236 is connected to JPD Bus 10142, to Write Length
Input (WL) input of NC 10226, and to a first input of
LENALU 20252. Five bit output of BIAS 20246 is connected
to a second input of LE~AhU 20252, to LENG~H Bus 2~226,
and, as previously described, to a fourth inpu~ of OYFMUX
20240. Thirty-two bit output of LENALU 20252 is
connected, as sta~ed above, t~ third input of L~SEL
20250.
~ aving described the overall operation and the
structure of DESP 20210, operation of D~SP 20210 will be
described next below in further detail.
do _=~
a.a. ~ f~ o3c- ==cl~
Re~erring to OFFP 20218, G~F 10354 includes GR's
10360 and SRIs 10362. GR's 10360 in turn contain ABR's
10364, mGR's 10366, and a set of general registers. SR's
10362 include MI5 10368 and MOS 10370. GRF 10354 is
Z5 vertically divided into three parts. AONGRP 20232 is 28
bits wide and resides in AONP 20216, LENGRF 10354 is 32
bits wide and resides in LENP 2~220, and OFFGRF 20234 is
32 bits wide and resides in O~FP 20218. AONGRF 20232,
1~79Q63
-~37-
OFFGRF 20234, and LE~GRF 20236 may be comprised of
Fairchild 93422s.
In addition to storing offset fields of AO~ pointers
and logical descriptors, those portions o OFFGRF ~0234
not reserved for ABR's 10365, mCR's 10366, and SR'~ 10362
may be used as general registers, alone or in con~unction
with corresponding portions AONGRF 20232 and LENGRF
20236, when OFFP 20218 is being utili~ed as a general
purpose, 32 bit CPU. OFFG~F 20234 as will be described
further below, is addressed in parallel with AONGRF 20232
and LE~GRF ~0236 ~y address inputs provided from FUCTL
20214.
OFF5EL 20238 is a multiplexer, comprised for example
of SN74S244s and SN74S257s, for selecting data inputs to
be written into selected address locations of OFF~RF
20234. OFFSEL 20238's first data input is from ~OD Bus
10144 and is the primary path for data transfer be~ween
MEM 10112 and DESP 20210. As previously described, each
da~a read from ~EM 10112 to JP 10114 is a single 32 bit
word where between one and 32 bits may contain actual
data. If a data item to be read from MEM 10112 contains
more than 32 bits of data, successive read operations are
performed until the entire data item has been
transferred.
OFFSEL 20238's second data input is from JPD Bus
10142. As will be described further below, JPD Bus 10142
is a data transfer path by which data outputs of FU 10120
and EU 10122 are written into ~EM 10112. OFFSEL 20238's
63
-238-
input of JPD Bus 10142 thereby provides a wrap around
path by which data present at outputs of FU 10120 or EU
10122 may be transferred back into DESP 20210 for further
use. For example, as prevlously stated a first output of
OFFALU 20242 is connected to JPD Bus 10142, thereby
allowing data output of OF~P 20218 to be returned to OFFP
20218 for ~urther processing, or to be transferred to
AONP 20216 or LENP 20220 as will be described further
below. In addition, output of LENGRF 20236 is also
connected to JPD Bus 10142 so that length fields of AON
pointers or physical descriptors, or data, may be read
from LE~GR~ 2023~ to OFFP 2021~. This path may be usPd,
for example, when LENGR~ 20236 is being used as a general
purpose register for storing data or intermediate results
o~ arithmetic or logical operations.
OFFSEL 20238's third input is provided from OFFALU
20242's output. This data path thereby provides a wrap
around path whereby offset fields or data residing in
OFFGRF 20234 may be operated on and returned to ~FFGRF
20234, either in the same addEess location as oriyinally
read from or to a different a~dress location. OFFP 20218
wrap around path from OFFALU 20242's output to OFFSEL
20238's third input, and thus to OFFGRF 20234t may be
utilized, for example, in readinq from MBM 10112 a data
25 item containing more than 32 bits of data. As previously
described, each read operation from ME~ 10112 to JP 10114
is of a 32 bi~ word wherein between one and 32 bits may
contain ac~ual data. Transf er of a data word containing
63
-239-
more than 32 bits is accomplished by performing a
succession o~ read operations from ~E~ 10112 to JP
10114. For example, if a re~uested data item contains 70
bits o data, that data item will be transferred in three
consecutive read operations. First and second read
operations will each transer 3~ bits of data, and final
read operation will transfer the remaining 6 bits of
data. To read a data item of greater than 32 bits from
MEM 10112 therefore, DESP 20210 must generate a sçquence
of logical descriptors, each de~ining a successive 32 bit
segment of that data item. Final logical descriptor of
the sequence may define a segment o less than 32 bits,
for example, six bits as in the example just stated. In
each successive p~ysical descriptor, of~set field must be
incremented by value of length field of the preceding
physical descriptor to define starting addresses o~
successive data items segments to be transferred. Length
field of succeeding physical descriptors will, in
general, remain consta~t at 32 bits except for final
transfer which may be less than 32 bits~ O~fset field
will thereby usually be incremented by 32 bits at each
. transfer until final transfer. OFF~ 20218's wrap around
data path from OFFALU 20~42's output to ~hird input of
OFFS~L 20238 may, as stated above, be utilized in such
sequential data transfer operations to write incremented
or decremented offset ield of a current physical
descriptor back into OFFGRF 20234 to be ofset field of a
next succeeding physical descriptor.
6 3
-240-
~ n a further example, OFFP 20218's wrap around path
rom OFFALU 20242's output to third input of OFFSEL 20238
may be used in resolving Entries in Name Tables 10350,
that is Name resolutions. In ~ame resolutions~ as
previously described, offs~t fields of AON pointers, ~or
example Linkage Pointers 10416, are successively added
and subtracted to provide a final AO~ pointer to a
desired data item.
OFFSEL 20~38's fourth input, from AONGRF 20232's
ou~pu~, may be used to transfer data or AON fields from
AONGRE 20232 to OFFGRF 20234 or OFFMUX 20240. This data
path may be used, for example, when OFFP 20218 is used to
generate AON fields of ~ON pointers or physical
descriptors or when performing ~ame evaluations.
~inally, OFFSEL 20238's fifth data input from OFFSET
Bus 20228 allows offset fields on OFFSET Bus 2022~ to be
written in~o OF~GRF 20234 or transferred into OFFMUX
20240. This data path may be used, for example, to copy
offset fields to OFFGRF 20~34 when JP 10114 is performing
a Name evaluation.
R~ferring now to OFF~UX 20240, OFF~UX 20240 includes
logic circuitry for manipulating individual bits of 32
bit words. OFFMU~ 20240 may be used~ for example, to
increment and decrement offset ~ields by length fields
when performing string transfers, and to generate entries
for, for example, M~T 10716 and ~FT 10718. OFEMUX 20240
may also be used to aid in generating and manipulating
AON, OFFSET, and LENGTH ~ields of physical descriptors
and AON pointers.
9~63
-241-
b.b.
~.. e.~ ~
Referring to Fig. 238, a more detailed, partial block
diagram of OFFMUX 20240 is show~. OFFMUX 20240 includes
Offset Multiplexer Input Selector (OFFMUXIS) 23810, which
for example may be comprised of SN74S373s and S~74S244s
and Of~set Multiplexer Regis~er ~OFFMUXR) 23812, which
for example may be comprised of SN74S374s. OFF~UX 20240
also includes Field Extraction ~ircuit (FEXT) 23814,
which may for example be comprised of S~74S257s, and
O~fset Multiplexer Field Selector (OFFMUXF5) 23816, which
for example may be comprised of SN74S257s and SN74S374s.
Finally, OFFMUX 20240 includes Offset Scaler (OF~SCALE)
23818, which may for example be comprised of AMD 25S10s,
Ofset Inter-element Spacing Encoder (OFFIESE~C) 23820,
which may for example be comprised of Fairchild 93427s
and Offset Multiplexer Output Selector (OFFMUXOS) 23822,
which may for example be comprised o~ AMD 25Ss, Fairchild
93427s, and SN74S244s.
Referring first to OFFMUX 20240's connections to
other portions of OFFP 20218, OFFMUX 20240's first data
input, from OFFSEL 2023~; is connected to a first input
o~ OFF~UXIS 23810. OFFMUX 20240's second inpUtf from ~OD
Bus 10144, is connected to a second input of OFFMUXIS
23810~ OFFMUX 20240's third input, from JPD Bus 10142,
is connected to a first input o~ OFFMUXFS 23816 while
OF~UX 20240's fourth input, from 8IAS 20246, i~
connected to a first input of OFFMUXOS 23822. OFFMVX
20240's ifth input, from NA~E Bus Z0224, is connected to
~7~63
--242--
a second input of OF~UXPS 23816. OFF~qUX 20240's first
out put, to OFFALUSA 20244, is connected from output of
OFFMUXR 23812 while OFFMUX 20240's second output, to
OFFALU 20242, is connected from output of OFF~UXOS 23822.
Referring to OFFMUX 20240's internal connections/ 32
bit output of OFFMUXIS 23810 is connected to input
OFFMUXR 23812 and 32 bit output of ûFFMUX~ 23812 is
connected, as described above, as first output of OFFMUX
20240, and as a third input of OFFMUXFS 23816. ~hirty--
two bit output of OFFMUXR 23812 is also connected to
input of FEXT 23814. OFFMUXFS 23816's ~irst, second and
third inputs are connected as described above. A fourth
input of OFFMUXFS 23816 is a 32 bit input wherein 31 bits
are set to logic zero and 1 bit to logic 1 A fifth
input is a 32 bit input wherein 31 bits are set to logic
1 and 1 to logic 0. A sixth input of OFFMUXFS 23816 is a
32 bit literal (L) irlput provided from FUSITT 11012 and
is a 32 bit binary number comprising a part of a
microinstruc~ion FUCqL 20214, described below. OFF~UXFS
23816's seventh and eighth input are connected from FEXT
23814 . Input 7 comprises FIU and TYPE f ields of ~ame
Table Entries which have been read into OFFkl~XR 23812.
Input 8 is a general purpose input conveying bits
extracted from a 32 bit word captured in OFFMUXR 23812.
As indicated in Fig. 238, OFF~qUXFS 23816's firs~, third,
fourth, fi~th, and sixth inputs are each 32 bit inputs
which are divided to provide two 16 bit inputs each.
That is, each of these 32 bit inputs is divided into a
. r -
1~79(~63
-243
first input comprising bit 0 to 15 of that 32 bit input,
and a second lnput comprising bits 16 to 31.
Thirty-two bit output of OFFMUXFS 23816 is connected
to inputs of OFFSCALE 23818 and OFFIESENC 23820. As
indicated in Fig. 238, Field Select Output (FSO) of
OFFMUXFS 23816 is a 32 bit word divided into a ~irst word
including 0 to 15 and a second w~rd including bits 16 to
31. Output FSO of OFFMUXFS 23816, as will be described
~urther below, thereby reflects the divided structure of
OFFMUXFS 23816's first, third, fourth, fifth, and sixth
inputs.
Logical functions performPd by OFFM~XFS 23816 in
generating output FSO, and which will be described in
further detail in following descriptions, include,
~1) Passing the con~ents of OFF~UXR 23812 direc ly
through OFFMUXFS 23816;
(2) Passing a 32 bit word on JPD ~us 10142 directly
through OFF~UX~S 23816;
(3) Passing a literal value comprising a part of a
Z0 microinstruction from FUCTL 20214 directly through
OFFMUXFS 23816;
(4) Forcing FSO to be Iiteral values 0000 0000
(5) Forcing FSO to be literal value 0000 001
(6) Extracting Name Table Entry fields;
(7) Accepting a 32 bit word from OFFMUXR 23812 or
~PD Bus 10142, or 32 bits of a microinstruction from
FUCT~ 20214, and pas~ing the lower 16 bits while forcing
the upper 16 bits to logic 0;
~7~ ~6
-~44-
(8) Accepting a 32 bit word from OFF~UXR 23812 or
~PD Bus 10142, or 32 bits of miroinstruction from FUCTL
20214, and passing the higher 16 bits while orcing th~
lower 16 bits to logic 0;
(9) Accepting a 32 bit word f~om OFFMUXR 23B12, or
JPD Bus 10142, or Name Bus 20224, or 32 bits of a
microinstruction rom ~UCTL 20214, and passing the lower
16 bits while sign extending bit 16 to the upper 16 bits;
and,
` (10) Accepting a 32 bit word from ~ame Bus 20224 and
passing the lowest 8 bits while sign extending bit 24 to
the highest 24 bits.
Thirty-two bit output of OFFSCALE 23818 and 3 bit
output of OFFIESE~C 23820 are connected, respectively, to
second and third inputs of OFFMUXOS 238220 OFFMUXOS
23822's ~irst input is, as described above, OFFMUX
20240's fourth input and is connected from output BI~S
20246. Finally, OFFMUXOS 23822's 32 bit output, OF~MUX
(0-31) is OFFMUX 20240's second output and as previously
described as connected to a second input of OFFALU 20242.
c . c . ~
a.a.a. _Ct~- A~=Q~ ~5~
~aving described the structure of OFFMUX 20240 as
shown in Fig~ 238, operation of OFFMUX 20240 will be
described below. Internal operation of OFFMUX 20240, as
shown in Fig. 238, will be described first, followed by
description of OFFMUX 20240's operation with regard to
DESP 20210.
llt79~63
--245--
Referring first to OFFMUXR 23812, OFFMUXR 23812 is a
32 bit register receiving either a 32 bit word from MOD
Bus 10144, MOD (0-31), or a 32 bit word received from
OFFSEL 20238, OF~SEL ~0-31), and is selected by OFFMUXIS
23810. OFFM~XR 23812 in turn provides those selected 32
bit words from MOD Bus 1û144 or OFFSEL 20238 as OFFMUX
20240's first data output to OFFALUSA 20244, as FEXT
23814's input, and as OFFMUXFS 23816's third input.
OFFMUXR 23812's 32 bit output to OFFMUXFS 23816 is
10 provided as two parallel 16 bit words designated as
OFFMUXR output (OFFMUXRO~ (0-15) and (16-31) . ~s
described above, OFFMUXFS 23816's output to OFFALUSA
20244 from OFFMUXR 23812 may ~e right shifted 16 places
and the highest 16 bits zero filled.
PEXT 23814 receives OFFMUXRO (0-15) and (1&-31) from
OFFMUXR 23812 and extra~ts certain fields from those 16
bit words. In particular, FEXT 23814 extracts FIU and
T~PE fields from NT 10350 Entries which have been
transferred into OFFMUXR 23812~ FEXT 23814 may then
provide those FIU and ~YPE fields as OFFMUXFS 23B16's
-- seventh input. FEXT 23814 may, selectively, extract
cer~ain other fields from 32 bit words residing in
OFFMUXR 23812 and provide those fields as OFFMUXFS
23816's eighth input.
OFF~UXFS 23816 operates as a multiplexer to select
certain fields from OFFMUXFS 23816's eight inputs and
provide corresponding 32 bit output words, Field Select
Output (FSO), comprised of those selected fields from
.
~9~63
-246-
OFF~UXFS 23816's inputs. As previously described, FSO is
comprised of 2, parallel 16 bit wor~s~ FSO (0-15) and FSO
~16-31). Correspondingly, O~FMUX 24240's third input,
from JPD Bus 10142, is a 32 bit input presented as two 16
bit words, JPD (0-15) and JPD (16-31). Similarly,
OFFMUXFS 23816's four~h, fiftht and six~h inputs are each
presented as 32 bi~ words comprised of 2, parallel 16 bit
wordsr respectively, "0~ (0-15) and (16-31~, "ln (0-15)
and (16-31), and L (0-15) and (16-31). OFFMUXFS 23816's
second input, from NAME 3us 20224, is presented as a
single 16 bit word, NAME (16-31), while O~UXFS 23816's
inputs from FEXT 23814 are each less than 16 bits in
width. OFF~UXFS 23816 may,~for a single 32 bit output
word, select ~SO (0-15) to contain one of corresponding
16 bit inputs JPD (0-15), "0" (0-15), "1" (0-15), or L
(0-15)o Similarly, FSO (16-31) of that 32 bit output
word may be selected to con~ain one of NAME (16-31), JPD
(16-31) t 0 ~16-31), 1 (16-31), L (16-31), or inputs 7 and
8 fro~ FEXT 23814. OFFMUXFS 23816 therefore allows 32
bit words, comprised of two 16 bit fields, to be
generated ~rom selected portions o~ OFF~UXFS 23816's
inpu~s.
OFFMUXFS 23816 32 bit output is provided as inputs to
OFFSCALE 23818 and OFFIESENC 23820. ~eferring first to
OFFIESENC 23820, OFFIESENC 23820 is used, in particular,
in resolving, or evaluating, NT 10350 Entries (NTEs)
referring to arrays of data words. As indicted in Fig.
108, word D of an NTE contains certain information
relating to inter-element spacing (IES) of data words of
il~79~63
-247-
an array. Word D o~ an NTE may be read from ~EM 10112 to
MOD Bus 10144 and through OFFMnX 20240 to input of
OFFIESENC 23820. OFFIESENC 23820 then examines word D~s
IES field to determine whether inter-element spacing of
that array is a binary multiple, that is 1, 2, 4, 8, 16,
32, or 64 bits. In particular, OFFIESENC 23820
determines whether 32 bit word D contains logic zeros in
the most significant 25 bits and a single logic one in
the least significant 7 bits. If inter-element spacing
is such a binary multiple, starting addresses of data
words of that array may be determined by left shifting of
index (IES) to obtain offse~ fi~lds of physical addresses
of words in the array and a slower and more complex
multiplication operation is not required. In such cases,
OFFIESE~C generates a first output, IES Encodeable
(IESENC) to FUCTL 20214 to indicate that inter-element
spacing may be determined by simple left shifting.
O~FIESENC 23820 then generates encoded output, Encoded
IES (ENCIES), to OFFMUXOS 23822. E~CIES is the~ a coded
value specifying the amount of left shi~t necessary to
translate index (IES) value into offsets of words in that
array. As indicated in Fig~ 238, ENCIES is OFFM~XOS
23822's third input.
OFFSCALE 23818 is a left shi~t shift networ~ with
zero ~ill of least significant bits, as bits are left
shifted. Amoun~ of shift by OFFSCALE 23818 is selectable
between zero and 7 bits. Thirty-two bit words
transferred into OFFSCALE 23818 from OF~SCALE 23818 from
9063
-248-
OFFMUXFS 23816 may therefore be left shifted, bit by bit,
to selectively reposition bits within that 32 bi~ input
word. In conjunction with OFFMUX~S 23816, and a wrap
around connection provided by OFFALU 20242's output to
OFFSEL 20238, OFFSCALE 23818 may be used to generate and
manipulate, for example, entries for ~T 10716, MFT
10718, AOT 10712, and AST 10914, and other CS 10110 da~a
structures.
OFF~UXOS 23822 is a multiplexer having first, second,
and third inputs from, respectively, BIAS 20246, OFFSCALE
23818, OFFIESENC 23820. OFF~UXOS 23822 may select any
one of these inputs as OFFMUX 20240's second output,
OFFMUX (0-31). As previously described, OFFM~X 20240's
second output is connected to a second input of OFFALU
20242.
~ aving described internal of OFF~UX 20240, operation
of OFF~UX 20240 with regard to overall operation of DESP
20210 will be described next below~
b ~ b o b ~ ~e~=~se:~
~ ~8~
OFFMUX 20240's first input, from OFFSEh 2n238, allows
inputs to OFFSEL to be transferred through OFFMUXI9 23810
and into OFFMUXR 23812. This input allows OFFMUXR 23812
to be loaded, under control of FUCTL 20214
microinstructions, with any input of OFFSEL 20238. In a
particular example, OFFALU 20242ls output may be fed back
through OFFSEL 20238's third input and OFFMUX 20240's
` t
~7~ ~6 3
-249-
first input to allow OFFMUX 20240 and OFFALU 20242 to
perorm reiterative operations on a single 32 bit word.
OFFMUX 20240's second input, from ~OD Bus 10144,
allows OFFMUXR 23812 to be loaded directly from ~OD Bus
10144. For example, ~Es from a currently activa
procedure may be loaded into OFFMUXR 23812 to be operated
upon as described above. In addition, OFFMUX 20240's
second inpu~ may be used in conjunction with OFFSEL
20238's first inputr from MOD Bus 10144, as parallel
input paths to OFFP 20218. These paraliel input paths
allow pipelining of OFFP 20218 operations by allowing
OFFSEL 20238 and OFFGRF 20234 to operate inde~endently
from OFFMUX 20240. For example, FU 10120 may initiate a
read operation from MEM 10112 to OF~MUXR 23812 during a
L5 f irst microinstruction. The data so requested will
appear on MOD BU9 10144 during a second microinstruction
and may be loaded into OFFMUXR 23812 through OFF~UX
20240's second input from MOD Bus 10144. Concurrently,
FU 10120 may initiate, at start of second
mlcroinstruction, an independent operation to be
performed by O~FSEL 20238 and OFFGRF 20234, for example
loading output of OFFAL~ 20242 into OFFGRF 20234~
Therefore, by providing an independent path into OFFMUX
20240 from MOD Bus 10144, OFFSEL 20238 is free to per~orm
other, concurrent data tran~fer operations while a data
transfer from MOD Bus 10144 to OFFMUX 20240 is being
performed.
6 3
-250-
OFF~UX 20240's third input, from JPD BUS 10142, is a
general purpose data transfer path. For example, data
from LENGRF 20236 or OFFALU 20242 may be transferred into
OFFM~X 20240 through JPD Bus 10142 and OFF~UX 20240's
third input.
OFFMUX 20240's fourth input is connected from B~AS
20246 and primarily used during string transfers as
described above. That is, length fields or physi~al
descriptors generated for a string transfer may be
transferred into OFFMUX 20240 through OFFMUX 20240's
fourth input to increment or decrement, offset ~ields of
those physical descriptors in OFFALU 20242.
OFFMUX 20240's fifth inpu~ is connected from ~AME Bus
20224. As will be described further below, Names are
provided to NC 10226 by FUCTL 20214 to call, from MC
10226, logical descriptors corresponding to Names
appearing on ~OD 8us 10144 as part of sequences of SI~s.
As each Name is presented to ~C 10226, that Name is
transferred into and captured in Name Trap (NT) 20254.
Upon occurrence of an NC 10226 miss, that is ~C 10226
does not contain an entry corresponding to a particular
~ame, that Name is subsequently transferred from NT 20254
to OFFMUX 20240 through NAME Bus 20224 and OFFMUX 20240's
fifth input. That Name, which is previously described as
an 8, 12, or 16 bit binary number, may then be scaled,
that is multiplied by a NTE size. That scaled Name may
then be added to Mame Table Pointer ~TP) from mCRs 10366
to obtain the address o a corresponding ~E in an NT
11~79~;3
--2s 1--
10350. In addition, a Name resulting in a NC 10226 miss,
or a page fault in the corresponding NT 10350, or
requiring a sequence of Name resolves, may be transferred
into OFFGRF 20234 from OFFMUX 20240, through OFFALU 20242
and OFFSEL 20238 third input. That Name may subsequently
be read, or restored, from OFFGRF 20234 as required.
Referring now to outputs of OFFMUX 20240, OFFMUX
20240's first output, from OFF~UXR 23812, allows contents
of OFFMUXR 23812 to be transferred to first input of
l OFFALU 20242 through OFFALUSA 20244. OFFMUX 20240 ' s
second output, from OFF~UXOS 23822, is provided directly
to second iApUt of OFFALU 20242. OFFALU 20242 may be
concurrently provided with a irst input from O~FMUXR
23812 and a second input, for example a manipulated
offset field, from OFFMUXOS 23822.
Referring to OFFALUSA 20244, OFFALUSA 20244 is a
multiplexer. OFFALUSA 20244 may select either output of
OFFGRF 20234 or firqt output of OFFMUX 20240 to be either
first input of OFFALU 20242 or to be OFFP 20218lS output
to OFFSET Bus 20228. For example, an offset field from
OFFGRF 20234 may be read to OFFSET Bus 20228 to comprise
offset field of a curren~ logical descriptor, and
concurren~ly read into OFFALU 20242 to be incremented or
decremented to generate offset field of a subsequent
logical descriptor in a string transfer.
790~;3
-252-
OFFALU 20242 is a general purpose, 32 bit arithmetic
and logic unit capable of performing all usual ALU
operations. For example, O~FALU 20242 may add, subtract,
increment, or decrement of~set fields of logical
descripto~s. In addition, OFFALU 20242 may se~ve as a
transfer path for data, that is OFFALU 20242 may transfer
input data to OFFALU 20242's outputs without operating
upon that data. OFFALU 20242's first output, as
described above, is connected to JPD Bus 10142, to third
input of OFFSEL 20238, and to first input of AONSEL
20248. Data transferred or manipulated by OFFALU 20242
may therefore be transferred on to JPD Bus 10142, or
wrapped around into OFFP 20218 through OFFSEL 20238 for
subsequent or reiterative operations. OFFALU 20242's
output to AONSEL 20248 may be used, for example, to load
AON fields of AON pointers or physical descriptors
generated by OFFP 20218 into AONGRF 20232. In addition,
this data path allows FU 10120 to utilize AONGRF 20232
as, for example, a buffer or temporary memory space for
intermediate or final results of FU 10120 operations.
OFFALU 20242'g outpu~ to OFFSET Bus 20228 allows
~logical descriptor offset fields to be transferred onto
OFFSET Bus 20228 direc~ly from OFFALU 20242. Por
example, a logical descriptor offset field may be
generated by OFFALU 20242 during a first clock cycle, and
transferred immediately onto OFFSET Bus 20228 during a
second clock cycle.
79~3
253-
OFFALU 20242's third output is to NAME Bus 20224. ~s
will be described further below, NAME Bus 20224 is
addres~ input ~ADR) to ~C 10226. OFFALU 20242's output
to NAME Bus 20224 thereby allows OF~P 20218 to generate
or provide addresses, that is ~ame~, to NC 10226.
~ aving described operation of OFFP 20218, operation
o~ LENP 20220 will be described next below.
e. ~
Referring to Fig. 202, a primary ~unction of LENP
l 20220 is generation and manipulation of logical
descriptor length fields, including length fields of
logical descriptors generated in string transfers~ LENP
20220 includes LENGRF 20236r LENSEL 20250, BIAS 20246,
and LENAhU 20252. LENGRF 20236 may be comprised, for
example, of Fairchild 93422so LE~SEL 20250 may be
comprised of, for example, SN74S257s, SN74S157s, and
SN74S244s, and LENALU 20252 may be comprised of, for
example, SN74S381s.
As previously described, LENGRF 20236 is a 32 bit
wide vertical section of GRF 10354. LENGRF 20236
operates in parallel with OFFGRF 20234 and AONGRF 20232
and contains, in part, length fields of logical
descriptors. In addition, also as previously described,
LENGRF 20236 may contain data.
~ LEN8EL 20250 is a multiplexer having three inputs a~d
providing outputs to LENG~F 20236 and first input of BIAS
20246. LENSEL 20250's first input is from Length Bus
20226 and may be used to write physical descriptor or
.
11~79~63
-254-
length fields from LENGTH Bus 20226 into LENGRF 20236 or
into BIAS 20246. Such leng~h fields may be written from
LENGTH Bus 20226 to LE~GRF ~0236, for example, during
Name evaluation or resolve operations. LE~SEL 20250's
second input is from OFFSET Bus 20228. LENSEL 20250's
second input may be used, for example, to load length
fields generated by OFFP 20218 into LENGRF 20236. In
addition, data operated upon by OFFP 20218 may be read
into LE~GRF 20236 for storage through LENSEL 20250's
l second input.
LENSEL 20250's third input is from output of LENALU
20252 and is a wrap around path to return output of
LENALU 20252 to LENGRF 20256. LENSEL 20250's third input
may, for examplet be used during string transfers when
length fields of a particular logical descriptor is
incremented or decremented by LENALU 20252 and returned
to LE~GRF 20236. This data path may also, for example,
be used in moving a 32 bit word from one location in
LENGRF 20236 to another location in LENGRF 20236. As
stated above, LENSEL 20250's output is also provided to
first input BIAS and allows da~a appearing at first,
second, or third inputs of LE~SEL 202S0 to be provided to
first input of BIAS 20246.
BIAS 2024~, as will be described in further detail
below, generates logical descriptor length ~ields during
string transfers. As described above, no more than 32
bits of data may be read from ~E~ 10112 during a single
read operation. A data item o~ greater than 32 bits in
.
9~163
-255-
length must therefore be transferred in a series, or
string, of read operations, each read operation
tran~ferring 32 bits or less of data. String transfer
logical descriptor length fields generated BIAS 20246 are
provided to LENGT~ Bus 20226, to LENALU 20252 second
input, and to OFFMUX 20240's fourth input, as previously
described. These string transer logical descriptor
length fields, referred to as bias fields are provided to
LE~GTH Bus 20226 by ~IAS 20246 to be length fields of the
series of logical descriptors generated by DESP 20210 to
execute a string transfer, These bias fields are
provided to fourth inpu~ OFFMUX 20240 to increment or
decrement offset fields sf those logical descriptors, as
previously described. These bias field~ are provided to
second input of LENAL~ 20252, during string transfers, to
correspondingly decrement the length field of a data item
being read to MEM 10112 in a string transfer. BIAS 20246
will be described in greater detail below, ater LENALU
20252 is first briefly described.
a.a. ~ Y~ t~
LENALU 202S2 is a general purpose, 32 bit arithmetic
and logic unit capable of executing all cus~omary
arithmetic and logic operations. In particular, during a
string transfer of a particular data item LENALU 20252
receives that data items length field fro~ LENGRE 2~236
and successive bias fields from BIAS 20246. LENALU 20252
then decrements that logical descriptor's current length
field to generate length field to be used during next
read operation of the string transfer, and transfers new
length ield back into LENGRF 20236 through LENSEL
20250's third input.
9~63
--256--
b.b. ~S~=c:~
Referring to Fig. 239, a partial block diagram of
BIAS 20246 is shownO BIAS 20246 includes Bias Memory
(BIAS~) 23910~ Length Detector (LDET) 23912, Next Zero
5 Detector (~XTZRO~ 23914, and S~lec~ Bias (SBIAS) 23916.
Input of LDET 23912 is first input of BIAS 20246 and
connected from output of LENSEL 20250. Output of LDET
23912 is connected to data input o BIASM 23910, and data
output of BIASM 23910 is connected to input of NXTZRO
23914~ Output of NXTZRO 23914 is connected to a first
input o:E SBIAS 23~16. A second input of SBIAS 23916 is
BIAS 20246 l s second input, L8, and is connected from an
output of FUCTL 20214. A third input of SBIAS 23916 is
BIAS 20246's third input, L, and is connected from yet
another output of FUCTL 20214. Output of SBIAS 23916 is
output of BIAS 20246 and, as described above, is
connected to LENGT~ Bus 20226, to a second input of
LEN~LU 20252, and to fourth input of OFFMUX ~0240.
BIASM 23910 is a 7 bit wide random access memory
20 having a length equal to, and operating and addressed in
parallal with, SR's 10362 of GRF 10354. BIASeq 23910 has
an address l-ocation corresponding to each address
location of SR's 10362 arld is addressed concurrently with
those address locations in SR's 19362. BIASM 23910 may
25 be comprised, for example, of A~ 27S03As.
BIASM 23910 contains a bias value of each logical
descriptor residing in SR's 10362. As described above, a
bias value is a number representlng number of bits to be
9 ~ ~ 3
-257-
read from ME~ 10112 in a particular read operation when a
data item having a corresponding logical descriptor, with
a length field stored LE~GR~ 20236, is to be read from
MEM 10112. Initially, bias values are written into BIASM
23910, in a manner deqcribed below, when their
corresponding length fields are written into LENGRF
20236. If a particular data item has a lenqth of less
than 32 bits, that data item's initial bais value will
represent that data items actual length. For example, if
a data item has a length of 24 bits the associated bias
value will be a 6 bit binary number representing 24.
That data item's length field in LENGRF 20236 will
similarly contain a length value of 24. If a particular
item has a length of greater than 32 bits for example, 70
bits as described in a previous example, that data item
must be read from MEM 10112 in a string transfer
operation. As previously described, a string transfer is
a series of read operations transferring 32 bits at a
time from ~lEM 1.0112, with a ~inal transfer of 32 bits or
less completing transfer of that data item~ Such a data
ltem's initial length field en~ry in LENGRE 20236 will
contain, using the same example as previously described,
a value of 70. That data item's initial bais entry
written into a corresponding address space of BIASM 23910
will contain a bias value o~ 32. That initial bias value
of 32 indicates that at least the first read operation
re~uired to transfer that data item from ~E~ 10112 will
transfer 32 bits of data.
~7~ ~ ~ 3
-258-
When a data item having a length of less than 32
bits, for example 24 bits, is to be read ~rom ME~ 10112,
that data item's bias value of 24 is read from BIASM
23910 and provided to LE~GTH Bus 20226 as length field of
logical descriptor for that read operation. ~
Concurrently, that bias value of 24 is subtracted from
that data items length field read from LENGRF ~0236.
Subtracting that bias value from that length value will
yield a result of zero, indicating that no further read
operations are re~uired to comple~e transfer of that data
item.
If a data item having, for example, a length o 70
bits is to be read from MEM 10112, that data item's
initial bias value of 32 is read from BIASM 23910 to
LENGT~ Bus 20226 as length field of first logical
descriptor of a string trans~er. Concurrently, that data
item's initial length field is read from LENGRF 20236.
That data item's initial bias value, 32, is subtracted
~rom that data item's initial length valuP, 70, and
LE~ALU 2025~. The result of that sub~raction operation
is ~he rem~inIng length of data item to be transferred in
one or more ~ubsequent read operations. In this example,
subtracting initial bias value from initial length value
indicates that 38 bits of that data item remain to be
transferred. LENALU 20252's output representing results
of this subtraction, for example 38, are transferred to
hE~SEL 20250 ' s third input to LENGR~ 20236 and written
into address location from which that data item ' s initial
~ `
-
~79 ~6 3
-259-
length value was read. This new length field entry then
represents remaining length of that data item.
Concurrently, LDE~ 23912 examines that residual length
value being written into LE~GRF 20236 to determine
whether remaining length of that data item is greater
than 32 bits or is equal to or less than 32 bits. If
remaining length is greater than 32 bits, LDET 23912
generates a next bias value of 32, which is written into
BIASM 23910 and same address location that held initial
bias value. If remaining data item length is less than
32 bits, LDET 239I2 generates a 6 bit binary number
representing actual remaining length of data item to be
transferred. Actual remaining length would then, again~
be written into BIASM 23910 address location originally
containing initial bias value. ~hese operations are also
performed by LDET 23912 in examining initial length field
and generating a corresponding initial bias value. These
read operations are continued as described above until
LDET 23912 detects that remai~ing length field is 32 bits
or Iess, and thus that transfer of that data item will be
completed upon next read operation. When this event is
detected, LDET 23912 generates a seventh bit input into
BIASM 23910, which is written into BIASM 23910 together
with last bias value of that string transfer, indicating
that remaining length will be zero after next read
operation. When a final bias value is read from BIAS~
23910 at start of next read operation of that string
transfer, that seventh bit is examined by NXTZRO 23914
which subsequently generates a test condition output,
Last Read (LSTRD) to FUCTL 20214. FUCTL 20214 may then
~ ~9063
-260-
terminate execution of that string transfer after that
last read operation, if the transfer has been
successfully completed.
As previously descri~ed, the basic unit of length of
a data item in CS 10110 is 32 bits. Accordingly, data
items of 32 or fewer bits may be transferred directly
while data items of more than 32 bits require a string
transfer. In addition, transfer of a data item through a
string transfer re~uires tracking of the transferred
length, and remaining length to be transferred, of both
the data item itself and the data storage space of the
location the data item is being transferred to. As such,
BIAS 20246 will store, and operate with, in the manner
described above, leng~h and bias fields of the logical
descriptors of both the data item and the location the
data item is being transferred to. FUCT~ 20214 will
recei~e an LST~D test condition if bias field of source
descriptor becomes zero be~ore or concurrently with that
of the destination, that is a completed transfer, or if
bias field of destination becomes zero before that of the
source, and may provide an appropriate microcode control
response. I~ should be noted that if source bias field
becomes zero before that of the destina~ion, the
remainder o~ the location that this data item is being
transferred to will be filled and padded with zeros. If
the data item is larger than the destination storage
capacityl the destination location will be filled to
capacity and FUCTL 20214 notified to initiate appropriate
action.
li~79063
-261-
In addition to al~owing data item transfers which are
insensitive to data item length, BIAS 20246 allows string
transfers to be accomplished by short, tight microcode
loops which are insensitive to data item length. A
string transfer, for example, from location A to location
B is encoded as: -
51) Fetch from A, subtract length from bias A, andupdate offset and length of a; and,
(2) Store to B, subtract length from bias B, and
branch to (1) if length of B does not go to zero or fall
through (end transfer) if length of B goes to zero.
Source (A) length need not be texted as the microcode
loop continues until length of B goes to zero; as
described above, B will be filled and padded with zeros
if length of A is less than length of B, or B will be
filled and the string transfer ended if length of A is
greater than or equal to length of B.
LDET 23912 and NXTZRO 23914 thereby allow FUCTL 20214
to automatically initiate a string transfer upon
occurrence of a single microinstruction from FUCTL 20214
initiating a read operation by DESP 20210. That
microinstruction initiating a read operation will then be
automatically repeated until LST~D to FUCTL 20214 from
NXTZRO 23914 indicates that the string transfer is
completed. LDET 23912 and ~XTZRO 23914 may,
respectively, be comprised for example of S74S260s,
SN74S133s, SN74S51s, SN74SOOs, S~74SOOs, SN74S04s,
SN74S02s, and SN74S32s.
~ - J
79~;3
--262--
Referring finally to SBIAS 23916, SBIAS 23916 is a
multiplexer comprised, for example, of SN74S288s,
SN74S374s, and SN74S244s. SBIAS 23916, under
microinstruction control from FUCTL 20214, selects BIAS
S 20246's output to be one of a bias value from BIAS~
23glO, L8, or L. SBIAS 23916's ~irst input, from BIASM
23910, has been described above. SBIAS 23916's second
input, L8, is provided ~rom FUCTL 20214 and is 8 bits of
a microinstruction provided from ~U5ITT 11012. 5BIAS
23916's second input allows microcode selection of bias
values to be used in manipulation of length and offset
flelds o~ logical descriptors by I.EN~LU 20252 and OFFALU
20242, and for generating entries to ~C 10226. SBIAS
23916's third input, L, is similarly provided from FUCTL
20214 and is a decoded length value derived from portions
of microinstructions in FUSITT 11012. These microcode
length values represent cer~ain commonly occurring data
item lengths, for example length of 1, 2, 4, 8, 16, 32,
and 64 bits. An L input representing a length of 8 bits,
~ay be used ~or example in reading data from ME~ 10112 on
a ~yte by byte basis.
~ aving de~cribed operation of LE~P 20220, operation
of AO~P 20216 will be describ~d next below.
f- _~lL~ .e2
a.a. ~s~5~ æ~
As described above, AONP 20216 includes AONSEL 20248
and AO~GRF 20232 AO~GRF 20232 is a 28 bit wide vertical
section of GRF 10354 and stores AON ~ields of AON
pointers and logical descriptors. AONSEL 20248 is a
multiplexer for selecting inpu~s to be written into
1~79063
-263-
AONGRF 20232. AONSEL 20248 may be comprised, for example
of SN74S257s. AONGRF 20232 may be comprised of r or
example, Fairchild 93422s.
As previously described, AO~GRF 20232's output is
connected onto AON Bus 20230 to allow AON fields o~ AON
pointers and logical descriptors to be transferred onto
AON Bus 20230 ~rom AONGRF 20232. AONGRF 20232's output,
together with a bi-directional input from AON Bus 20230,
is connected to a second input of AONSEL 20248 and to a
~ourth input o~ AONSEL 20238. This data path allows AON
fieldsr either from AO~GRF 20232 or from AON Bus 20230,
to be written into AONGRF 20232 o~ AONGRF 20234, or
provided as an input to OFFMUX 20240.
b.b.~ tl~C~ c=~L~
l5AONSEL 20248's ~irst input is, as previously
described, connected from output o~ OFFALU 20242 and is
used, for example, to allow ~ON fields generated or
manipulated by OFFP 20218 to be written into AONGRF
20232. AONSEL 20248's third input is a 28 bit word
wherein each bit is a logical zero. AO~SEL 20248's third
input allows AO~ fields of all zeros ~o be written into
AONGRF 20232. An AON field of all 2eros is reserved to
indicate that corresponding entries in OFFGRF 20234 and
LE~GRF 20236 are neither AON pointers nor logical
descriptors. AON fields of all zeros are there~y
reserved to indicate that corresponding entries in OFFGRF
20234 and LE~GRF 20236 contain data.
In summary, as described above, DESP ~0210 includes
AONP 20216, OFFP 20218, and LENP 20220. OFFP 20218
contains a vertical section o~ GRF 10354, OFFGRF 20234,
6 3
-264-
for storing o~fset fields of AON pointers and logical
descriptors, and for containing data to be operated upon
by DESP 20210. OFFP 20218 is principal path for transfer
of data from ME~ 10112 to JP 10114 and is a general
purpose 32 bit arithme~ic and lo~ic unit for per~orming
all usual arithmetic and logiG operations. In addition,
OFFP 20218 includes circuitry, for example OFFMUX 20240,
for generation and manipulation of AON, OFFSET, and
LENGTa fields o~ logical descriptors and AON pointers.
0 OFFP 20218 may also generate and manipulate entries for,
for example, NC 10226, ATU 10228, PC 10234, AOT 3.0712
M~T 10716, MFT 10718, and other data and address
structures residing in ~EM 10112O LENP 20220 includes a
vertical section of GRF 10354, LENGRF 20236, for storing
length field~ of logical descriptors, and for storing
data. 1ENP 20220 ~urther includes BIAS 20246, used in
conjunction with LE~GRF 20236 and LENALU 20252, for
providing length ields of logical descriptors for MEM
10112 read operations and in particular automatically
performing string transfers~ AONP 20216 similarly
includes a vertical section of GRF 10354, AONGRF 20232.
A primary function AO~GRF 20232 is storing and providing
AON fields o~ AON pointers and logical descriptors.
~aving described structure and operation of DESP
20210, structure and operation of ~emory Interface
(MEMINT) 20212 will be described nex~ below.
2.
-2~L
MEMINT 20212 comrises FU 10120's interface to ME~
101120 As described above, ME~INT 20212 includes Name
~t79~63
-265-
Cache (NC) 10226, Address Translation Unit (ATU) 10228,
and Protection Cache (PC) 10234, all of which have been
previou91y briefly described. ME~INT 20212 further
includes Descriptor Trap (DEST) 20256 and Data Trap (DAT)
20258. Func~ions performed by MEMI~T 20212 includes (1)
resolution of Names to logical descriptors, by NC 10226;
(2) translation of logical descriptors to physical
descriptors, by ATU 10228; `and (3) confirmation of access
writes ~o objects, by PC 10234.
As shown in FigO 202, ~C 10226 adress input (ADR) is
connec ed from NAME Bus 20224. ~C 10226 ~rite Length
Field Input ~WL~ is connected from LENGRF 2Q236's
output. NC 10226's ~rite Offset Field Input (WO) and
Write AON Field Input (WA) are connected, respectively,
f~om OFFSET Bus 20228 and AON Bus 20230. NC 10226 Read
AON Field (RA), Read Offset Field (RO), and Read Length
Field (RL) outputs.are connected, respectively, to AON
Bus 20230, OFFSET Bus 20228, and LENGTH Bus 20226.
DEST 20256's bi-directional AON (AON), Offset (OEF),
and Length (LEN) ports are connected by bi-directional
buses to and from, respectively, AON Bus 20230, OFFSET
Bus 20228, and LENGT~ Bus 20226.
PC 10234 has AON (AON) 2nd Offset (OFF) inputs
connected from, respectively, AON ~us 20230 and OFFSET
Bus 20228. PC 10234 has a Write Ent~y (WEN) input
connected from JPD Bus 10142. ATU 10228 has AON (AON) r
Offset (OFE), and Length (LEN) inputs connected from,
respectively, AON Bus 20230, OFFSET Bus 20228, and LENGTH
-266-
Bus 20226. ATU 1022a's output is connected to Physical
Descriptor (PD) ~us 10146.
Finally, DAT 20258 has a bi-directional port
connected to and from JP~ Bus 10142.
a~a.
~2D~
Referring first to DST 20256 and DAT 20258, DST 20256
is a register for receiving and capturing logical
descriptors appearing on AON Bus 20230, OFFSET Bus 20228,
and Length BU5 20226. Similarly, DAT 20258 is a register
for receiving and capturing data words appearing on ~PD
Bus 10142. DST 20256 and DAT 20258 may subsequently
return captured logical descriptors or data words to,
respectively, AON Bus 20230, OFFSET Bus 20228~ and LENGTH
Bus 20226, and to JPD Bus 10142.
As previcusly described, many CS 10110 operations, in
particular ME~ 10112 and JP 10114 operations, are
pipelined. That is, operations are overlapped with
certain sets within two or more operations being executed
concurrently. For example, FU 10120 may submit read
request to MEM 10112 and, while ME~ 10112 is accepting
and servicing that request, submit a second read
request. DEST 20256 and DAT 20258 assist in execution of
overplapping opsrations by providing a temporary record
of these operations. For example, a part of a read or
write request to MEM 10112 by FU 10120 is a logical
descriptor provided to ATU 10228. If, for example the
first red request just referred to results in a ATU 10228
cache miss or a protection violation, the logical
descriptor of that first request must be recovered for
`~
7~63
-267-
subsequent action by CS 10110 as previously described.
That logical descriptor will have been captured and
stored in DEST 20256 and thus is immediately available,
so that DESP 20210 is not required to regenera~e that
descrip~or. DAT 20258 serves a similar purpose with
regard to data being written into M~M 10112 from JP
10114. That is, DAT 20258 receives and captures~a copy
of each 32 bit word transferred onto JPD Bus 10142 by JP
10114. In event of MEM 10112 being unable to accept a
l write request, that data may be subse~uently reprovided
from DAT 20258.
b~bo a~e~ *~ d~ss~
~it~ ,
~2~0t~C~0~--2~se--~ ~
Referring to NC 10226, ATU 10228, and PC 10234, these
elements of MEMINT 20212 are primarily cache mechanisms
to enhance the speed of F~ 10120's interface to MEM
10112, and consequently of CS lOllO's operation. As
described previously, NC 10226 contains a set of logical
descriptors corresponding to certain operand names
currently appearing in a process being executed by CS
10110c NC 10226 ~hus effectively provides high speed
resolution of certain operand names to corresponding
logical descriptors. As described above with reference
to string transfers, NC 10226 will generally contain
logical descriptors only for data items of less than 256
bits length. NC 10226 read and write addresses are names
provided on ~AME Bus 20224. Name read and write
9~63
-268
addresses may be provided from DESP~20210, and in
particular from OFFP 20218 as previously described, or
from FUCTL 20214 as will be described in a following
description of ~UCTh 20214. Logical descriptors
S comprising ~C 10226 en~ries, each entry comprising an AON
field, an Offset field, a Length field, are written into
NC 10226 through NC 10226 inputs WA, WO, and WL from,
respectively, AON Bus 20230, OFFSET Bus 20228, and LENGRF
20236's output. Logical descriptors read from NC 10226
in response to names provided to NC 10226 ADR input are
provided to AON Bus 20230, OPFSET Bus 20228, and LE~GT~
Bus ~0226 from, respectively, NC 10226 outputs RA, RO,
and RL.
ATU 10228 is similarly a cache mechanism for
providing high speed translation of logical to physical
descriptors. In general, ATU 10228 will contain, at any
given time, a set of logical to physical page number
mappings for MEM 10112 read and write requests which are
currently being made, or anticipated to be made, to ~E~
10112 by JP 10114. As previously described, each
physical descriptor is comprised of a Frame Number ~FN)
field, and Offset Within Frame (O ) fields, and a L~ngth
field. As discussed with reference to string trans~ers,
a physical descriptor length field, as in a logical
descriptor length fie}d, specify a data item of less than
or equal to 32 bits length. Re~erring to Fig. 106C, as
previously discussed a logical descriptor comprised of a
14 bit AON field, a 32 bit Offset field, and Length
field, wherein 32 bit logical descriptor Offset field is
divided into a 18 bit ~age Number (P) field and a 14 bi~
9 ~ 3
-269-
Offset within Page (O ) field. In translating a logicl
into a physical descriptor, logical descriptor Length and
O fields are used directly, as respectively, physical
descriptor length and O fieldsO Logical descriptor AON
and P fields are translated into physical descriptor FN
field. ~ecause no actual translation is required, ATU
10228 may pro~ide logical descriptor L field and
corresponding O field directly, that is without delay,
to ~EM 10112 as corresponding physical descriptor O and
Len~th fields. ATU 10228 cache entries are thereby
comprised of physical descriptor FN fields corresponding
to AON and P fields of those logical descriptors for
which ATU 10228 has corresponding entries~ Because
physical descriptor FN fields are provided from ATU
10228's cache, rather than directly as in physical
descriptor O and Length fields, a physical descriptor's
FN field will be provided to MEM 10112, for example, one
clock cycle later than that physical descriptors O and
Length fields, as has beçn previously discussed.
~Referring to Fig. 202, physical descrip~or FN fields
to be written into ATU 10228 are, in general, generated
by DESP 20210. F~ fields to be written into ATU 10228
are provided to ATU 10228 Data Input (DI) through JPD ~us
10142. ATU 10228 read and ~rite addresses are comprised
o~ AON and P fields of logical descriptors and are
provided to ATU 10228's AON and OFF inputs from,
respectively, AON Bus 20230 and OFFSET Bus 20228. ATU
10228 read and write addresses may be provided ~rom DESP
20210 or, as described further below, from FUCTL 20214.
ATU 10228 FN outputs, together with O and Length fields
1~7~Q63
--27 o--
comprising a physical descriptor, are provided to PD Bus
10146.
PC 10234 is a cache mechanis~ ~or confirming active
procedure's access rights to objects identified by
logical descriptors generated as a part of JP 10114 read
or write requests to MEM 10112. As previously descri~ed
access rights to objects are arbitrated on the basis of
subjects. A subject has been defined as a particular
combination of a principal, process, and domain. A
principal, process, and domain are each identified by
corresponding UIDso Each subjec~ having acce~s rights to
an object is assigned.an Active Subject Number ~ASN) as
described in a pre~ious description of CS 10110's
Protection Mechanism? The ASN of a subject currently
active in CS 10110 is stored in ASN Register 10916 in FU
10120. Access rights of a currently active subject to
currently active objects are read from those objects
Access Control Lists (ACL) 10918 and stored in PC 10234.
If the current ASN changes, PC 10234 is flushed of
corresponding access right entries and new entries,
corresponding to the new AS~ are written into PC 10234.
The access rights of a particular current ASN to a
particuIar objPct may be determined by indexlng, or
addressing, PC 10234 with the AON identifying that
r~
'5 object. Addresses to write entries into or read entries
from PC 10234 are provided to PC 10234 AON input from AON
Bus 20230~ Entries to be written into PC 10234 are
provided to PC 10234's WEN input rom JPD 3us 10142. PC
10234 is also provided with inputs, not shown in Fig. 202
for purpose~ of clarity, from FUCTL 20214 indicating the
9Q~i3
--27 1-
current operation to be perfomed by JP 10114 with respect
to an object being presently addres~ed by FU 10120.
Whenever FU 10120 submits a read or write request
concening a particular object to MEM 10112, AON field of
that re~uest is provided as an addess to PC 10234.
Access right~ of the current active subject to that
objec~ are read from corresponding PC 10234 entry and
compared to FUCTL 20214 inputs indicating the particular
operation to be per~ormed by JP 10114 with respect to
lo that object. The operation to be performed by JP 10114
is then compared to that active subject's access rights
to that object and PC 10234 provides an output indicating
whether that active s~bject possesses the righ~s re~uired
to perform the intended operakion. Indexing of PC 10234
and comparison of access ri~hts ~o intended operation is
performed concurrently with transla~ion of the memory
request logical descriptor to a corresponding physical
descriptor by ATU 10228. If PC 10234 indicates that that
active subject has the required access rights, the
intended op~ration is executed by JP 10114. If PC 10234
indicates that that active subject does not have the
required access rightsr PC 10234 indicates that a
protection mechanism violation has occurred and
interrupts execution of the intendad operation.
c-c- ~ 3.~St2C=~
~ ' .
Having described overall structure and operation of
NC 10226, AT~ 10228, and PC 10234, struc~ure and
operation of these caches will be descri~ed in further
~7~ ~ 3
-272~
detail below. Structure and operation of NC 10226, ATU
10228, and PC 10234 are similar, except that NC 10226 i9
a our-way set associative cache, ATU 10228 is a three-
way set associative cache and PC 10234 is a two-way set
associative cacheO
As such, the structure and operation of NC 10226, ATU
10228, and PC 10234 will be described by reference to and
description of a generali2ed cache similar but not
necessarily identical to each of NC 10226, ATU 10228, and
PC 10234. Reference will be made ~o NC 10226 in the
description of a generalized cache next belowr both to
further illustrate structure and operation of the
generalized cache, and to describe differences between
the generalized cache and NC 10226. A~U 10228 and PC.
I5 10234 will then be described by description of
differences betw~en ATU 10228 and PC 10234 and the
generalized cache.
Referring to Fig. 240, a partial block diagram of a
generalized four-way, set associative cache is shown.
Tag 9tore (TS~ 24010 is comprised o Tay Store ~ (TSA)
24012, Tag Store B (TSB) 24014f Tag Store C (TSC~ 24016,
and Tag Store D (TSD) 24018. Each of the cache'~ sets,
represented by TSA 24012 to TSD 24018, may contain, for
example as in NC 10226, up to 16 entries, so ~hat TSA
24012 to T5D 24018 are each 16 words long.
Address inputs to a cache are divided into a tag
field and an index field~ Tag fields are stored in the
cache's tag store and indexed, that is addressed to be
read or written from or to tag store by index f ield of
the address. A tag read from tag store in response to
- ~ /
:
9 ~6 3
-273-
index field of an address is then compared to tag field
of that addre~s to indicate whether the cache contains an
entry corresponding to that address, that is, whether a
cache hit occurs. In, for example, ~C 10226, a Name
S syllable may be comprised of an 8, 12, or 16 bit binary ..
word, as previously described. ~he four least
significant bits of ~hese words, or Names, comprise MC
10226 's index ~ield while the remaining 4, 8, or 12 most
significant bits comprise NC 10226~s tag field. TSA
24012 to TDS 24018 may each, therefore, be 12 en~ry wide
memories to store the 12 bit ta~ f ields of 16 bit names.
Index ~IND) oe address inputs of TSA 24012 to TSD 24018,
would in NC 10226, be connected from four least
significant bits of ~AME Bus 20224 while Tag Inputs
(TAGI) of TSA 24012 to TSD 24018 would be connected from
the 12 most significant bits of NAME sus 20224.
As de~cribed above, tag outputs of TS 24010 are
compared to tag fields of addresses presented to the
cache to determine whether the cache contains an entry
20 - corresponding to that address. Using NC 10226 a~ an
example 12 bit Tag Outputs tTAGOs) of TSA 24012 to TSD
24018 are connected to first inputs of Tag Store
Comparators (TSC) 24019, respectively to inputs of Tag
Store Comparitor A (TSCA) 24020, Tag Store Comparitor B
(TSCB) 24022, Tag Store Compari~or D (TSCD) 24024, and
Tag Store Comparitor E (~SCE) 24026. Second 12 bit
inputs of TSCA 24020 to ~SCE 24026 may be connected from
the 12 most significant bits of NAME Bus 20224 to receive
1~79(~3
-274-
tag fields of ~C 10226 add~esses~ TAS 24020 to TSSE
24026 compare tag fi~ld of an address to tag outputs read
from TSA 24012 to TSE 24018 in response to index field of
that address, and provide four bit outputs indica~ing
5 which, if any, of the possible 16 entries and ~heir
associated tag store correspond to that address tag
field. TSCA 24020 to TSCE 24026 may be comprised, for
example, of Fairchild 93S46s.
Four bit outputs of TSCA 24012 to TSCE 24026 are
connected in the generalized cache to inputs of Tag Store
Pipeline Registers (TSPR) 24027; respectively to inputs
of Tag Store Pipeline Register A (TS~RA) 24028, ~ag Store
Pipeline Register B (TSPRB) 24030~ Tag Store Pipeline
Register C (TSPRC) 24032, and Tag Store Pipeline Register
15 D ~TSP~D) 24034. ATU 10228 and PC 10234 is pipelined
with a single cache access operation being executed in
two clock cycles. During first clock cycle tag store is
addressed and tags store therein compared to tag field of
address to provide indication of whether a cache hi~ has
occurred, that is whether cache contains an entry
corresponding to a particular addressO During second
clock cycle, as will be described ~elow, a detected cache
hi~ i~ encoded to obtain access to a corresponding entry
in cache data store. Pipeline operation over two clock
cycles is provided by cache pipeline registers which
include, in part~ TSPRA 24028 to TSP~D 24034. NC 10226
is not pipelined and does not include TSPRA 24028 to
TSP~D 24034. In NC 10226, outputs of TSCA 24012 to TSCD
275-
24024 are connected directly to inputs of TS~EA 2~036 to
TSHED 24042, described below.
Outputs o~ TSPRA 24028 to TSPRD 24034 are connected
to inputs o Tag Store ~it Encoders (TSaE) 24035,
r.espectively to Tag Store ~it Encoder A (TS~EA) 24036,
Tag Store ~it Encoder B (TS~EB) 24038, Tag Store ~it
Encoder C (TSHEC) 24040, and Tag Store ~it Encoder D
(TSHED) 24042. TSHEA 24036 to TSHED 24042 encode,
respectively, bit inputs from TSPRA 24028 to TSPRD 24034
to provide single bit ou~puts indicating which, if any,
set of the cache's four se~s includes an entry
corresponding to the address input.
Single bit outputs of T5HEA 24036 to TS~ED 24042 are
connected to inputs of ~it Encoder (~E) 24044. ~E 24044
encodes single bit inputs from TSHEA 24036 to TS~ED 24042
to provide two sets of ouputs. First outputs of H~ 24044
are provided to Cache Usage Store (CUS) 24046 and
indicate in which of the cache's four sets, corresponding
to TSA 24012 to TSD 24018, a cache hit has occurred. As
described previously with reference to MC 20116, and will
be described ~urther below, C~S 24046 is a memory
containing information for trac~ing usage of cache
entries. That is, CUS 24046 contains entries indicating
whether, for a particular inde~, Set A, Set B, Set C or
Set D of the cache's four sets has been most recently
used and which has been least recently used~ CUS 24046
entries regarding Sets A, B, C, and D are s~ored in,
respectively, memories CUSA 24088, CUSB 24090, CUSC
~ .
1~7~63
-276-
24092, and CUSD 24094. Second output o ~E 24044, as
described further below, is connected to selection input
of Data Store Selection ~ultiplexer (D5SMUX) 24048 to
select an ou~put from Data Store (DS) 24050 to be
provided as output of the cache when a cache hit occurs.
Referring to ~S 24050, as previously described a
cache's data store contains the information, or entries,
stor ed in that cache. For example, each entry in NC
10226's DS 24050 is a logical descriptor comprised of an
AON, and Offset, and Length. A cache's data store
parallels, in structure and organization, that cache's
tag store and entries therein are identified and located
through that cache's tag store and associated tag store
comparison and decoding logic. In NC 10226, for example,
for each Name having an entry in NC 10226 there will be
an entry, the tag field of that name, stored in TS 24010
and a corresponding entry, a logical descriptor
corresponding to that Name, in DS 24050~ As described
above, NC 10226 is a four-way, set associative cache so
20 that TS 24010 and D5 240S0 will each contain four sets of
data. Each ~et was previou~ly described as containing up
to 16 entries.. DS 24050 is therefore comprised of four
16 word memories. Each memory is 65 bits wide,
accommodating 28 bits of AON, 32 bits of offset, and 5
25 bits of length~ These four component data store memories
of DS 24050 are indicated in Fig~ 240 as Data Store A
(DSA) 24052, Data Store B (DSB) 24054, Data Store C (DSC)
24056, and Data Store D (DSD) 24058. DSA 24052, DSB
9 ~6 3
-277-
24054, DSC 24056 and DSD 24058 correspond, respectively,
in structur~, contents, and operation to ~SA 24012, TSB
24014, TSC 24016 and TSD 24018.
Data Inputs ~DIs) o~ DSA 24052 to DSD 24058 are, in
NC 10226 for example, connected from AON Bus 20230,
OFFSET Bus 20228, LE~GTH Bus 20226 and comprise inputs
W~, WO, W~ respectively o ~C 10226. DSA 24052 to DSD
24058 DIs are, in NC 10226 as previously described,
utilized in writing NC 10226 entries into ~SA 24052 to
10 DSD 24058. Address inputs of DSA 24052 to DSD 24058 are
connected from address outputs of Address Pipeline
Register (ADRPR) 24060. ~s will be described
momentarily, except during cache flush operations9 DSA
24052 to DSD 24058 address inputs are comprised of the
same index fields of cache addresses as are provided as
address inputs to TS 24010, but are delayed by one clock
: cycle and AD~PR 24060 ~or pipelining purposes. As
described above, NC 10226 is not pipelined and does not
have the one clock cycle delay. An address input to the
20 cache will thereby result in corresponding entries,
selected by index field of that address, being read ~rom
TSA 24012 to TSD 24018 and DSA 24052 to DSD 24058~ The
~our outputs of DSA 24052 to DSD 240S8 s21ected by a
particular index ield of a particular address are
25 provided as inputs to DSSMUX 24048. DSSMUX 24048 is
concurrently provided with selection control input ~rom
HE 24044. As previously described, this selection input
to DSS~UX 24048 is derived from TS 24010 tag entries and
1~'79~63
-278-
indicates which of DSA 24052 to DSD 24058 entries
corresponds to an address provided to the cache. In
response to that selection control input, DSSMUX 24048
selects one of DS 24050'~ ~our logical descrip~or outputs
5 as the cache's output corresponding to tha~ address.
DSSMUX 24048's output is then provided, through Buffer
Driver (BD) 24062 as the cache's output, for example in
NC 10226 to AON Bus 20230, OFF5ET Bus 20228, and LENGTH
~us ~226.
Re~erring to ADRMUX 24062, AD~MUX 24062 selects one
o~ two sources to provide address inputs to DS 24050,
that as to index t~ DS 24050. As described above, a
first AD~MUX 24062 input is comprised of the cache's
address index fields and, for example in NC 1022~, is
15 connected from the four least significant bits of NAME
Bus 20224. During cache flush operations, DS 24050
:address inputs are provided from ~lush Counter (FLUSHCTR~
24066, which in the example is a four bi~ counter.
During.cache flush operations, FLUS~CTR 24066 generates
20 sequential bit addresses which are used to sequentially
address DSA 24052 to DSD 24058. Selection between ADR~UX
24062 first and second inputs, respectively the address
index fields and from FLUS~CTR 24066, is controlled by
Address Multiplexer Select (AD~UXS) from FUCT~ 20214.
Validity Store (VALS) 24068 and Dirty Store (DIRTYS)
24070 are memories operating in parallel with, and
addressed in parallel wih TS 24010. VALS 24068 contains
entries indicating validity of corresponding ~S 24010 and
DS 24050 entries. That is, VALS 24068 entries indicate
30 whether corresponding entries have been written in~o
`~
79063
corresponding locations in TS 24010 and DS 240500 In the
example, VALS 24068 may thereby be a 16 word by 4 bit
wide memory. Each bit of a VA$S 24068 word indicates
validity of a corresponding location in TSA 24012 and DSA
S 24052t TSB 24014 and DSB 24054, TSC 24016 and DSC 24056
and TSD 24018 and DSD 24058. DIRTYS 24070 similarly
indicates whether corresponding entries in corresponding
locations of TS 2401Q and DS 24050 have been written
over, or modified. Againr DIRTYS 24070 will be a sixteen
word by four bit wide memory.
Address inputs of VALS 24068 and DIRTYS 24070 are,
for example in ~C 10226, connected from least significant
bits of NAME ~us 20224 and are thus addressed by index
~ields of NC 10226 addresses in parallel with TS 24010.
Outputs of VALS 24068 are provided to TSCA 24020 to TSEE
24026 to inhibit outputs of TSCA 24020 through TSCE 24026
upon occurrence of an invalid concurrence between a TS
24010 entry and a NC 10226 address input. Similar
outputs of DIRTYS 24070 are provided to ~UCTL 20214 for
use in cache flush operations to indicate which NC 10226
entries are dirty and must be written back into an ~T
10350 rather than disgarded.
Outputs of VALS 24068`and DIRTYS 24070 are also
connected, respectively, to inputs of Validity Pipeline
Register (VALPR) 24072 and Dirty Pipeline Register
(DIRTYPR) 24074 . VALPR 24072 and DIRTYPR 24074 are
pipeline registers similar to TSPRA 24028 to TSPRD 24034
and are provided for timing purp~ses as will be descri~ed
momentarily. Outputs of VALPR 24072 and DIRTYPR 24074
are connected to inputs of, respec~ively, Validity Write
~179063
-280
Logic (~IWL) 24076 and Dirty Write Logic (DWL) 24078. As
described above, NC 10226 is not a pipelined cache and
does not include V~LPR 24û72 and D~RT~PR 24074; outputs
of VALS 24068 and DIRTYS 24070 are connected directly to
5 inputs of VWL 2407~ and DWL 24078. Outputs of VWL 24076
and DWL 24078 are connected, respectively, to data inputs
of VALS 24068 and DIRTYS 24070. Upon occurrence o~ a
write operation to TS 24010 and DS 24050, that is writing
in or modifying a cache entryr corresponding validity and
10 dirty word entries are read from VALS 24068 and DIRTYS
24070 by index field of the caches input address.
Outputs to VALS 24068 DIRTYS 24070 are received and
stored in, respecti~?ely, VALPR 24070 and DIRTYPR 24074.
At start of nesct clock cycle, validity and dirty words in
15 ~ALPR 24072 and DIRTYPR 24074 are read into,
respectively, VWL 24016 and D~L 24078. ~7WL 24076 and DWL
2407 8 respectively modify those validity or dirty word
entries from VALS 24068 and DI~S 24010 in accordance to
whether the corresponding entries in TS 24010 and DS
20 24050 are wri~ten into or modified. These modified
validity and dirty words are then written, during second
clock cycle, from VWL 24076 and DWL 24078 into,
reQpectively, VALS 24068 and DIRTYS 24070. Control
inputs of VWL 24076 and DWL 24078 are provided from FUCTL
25 20214.
Referring finally to Least Recent Used Logic (LRUL)
24080, LRUL 24080 tracks usage of cache entries. As
previously described, the generalized cache of Fig. 240
/ - )
~lt79~3
-281-
is a four way, set associative cache with, for example,
up to 16 entries in each o NC 10226's sets~ Entries
with~n a particular set are identified, as described
above~ by indexing the cache's TS 24010 and DS 24050 may
contain, concurrently, up to four individual entries
identified by the same index but distiguished by having
di~ferent tags. In this case, one entry would reside in
Set A, comprising TSA 24012 and DSA 24052, one in Set B,
comprising TSB 24014 and DSB 24054, and so on. Since the
possible num~er of individual entries having a common tag
is greater than the number o~ cache sets, it may be
necessary to delete a particular cache entry when another
entry having the same tag is to be writ~en into the
caohe~ Tn general, the cache's least recently used entry
would be deleted to provide a location in TS 24010 and DS
24050 for writing in the new entry. LRUL 24080 assists
in determining which cache entries are to be deleted when
necessary in writing in a new entry by tracking and
indicating relative usage of the cache's entries. LR~L
24080 is primarily comprised of a m~mory, LRU ~emory
~LRU) 24081, containing a word ~or each cache setO As
described ~bove, ~C 10226, for example, includes 16 sets
o~ 4 frames each, so that LRUL 24080's memory may
correspondingly be, for exAmple, 16 words long. Each
word indicates relative usage of the 4 f rames in a s~t
and is a 6 bit word.
Words are generated and written into LRUL 24080's
~LRU 24081, through Input Register A, ~, C, D (RABCD)
24083, according to a write only algorithm executed by HE
.;
/- :
9~ ~ 3
-282-
24044, as described momentarily. Each bit of each six
word pertains to a pair o~ frames within a particular
cache set and indicates which of those two ~rames was
~ore ~ecently used than ~he other. For example, Bit n
5 will contain logic l if Frame ~ was used more recently
than Frame B and a logic zero if Frame B was used more
recently than Frame A. Similarly, Bit l pertains to
Frames A and C, Bit 2 to Fxames A and D, Bi~ 3 to Frames
B and C, Bit 4 to Frames B and D~ and Bit 5 to Frames C
and D. Initially, all bits of a par~icular LRUL 24080
word are set to zero~ Assuming, for example, ~hat the
frames of a particular set are used in the sequence Frame
A, Frame D, Frame B; Bits 0 to 5 of that LRUL 24080 word
will initially contain all zeros. Upon a reference to
Frame A, Bits 0, l, and 2, referriny respectively to
Frames A and 8, Frames A and C, and Frames A and D, will
be written as logic l's~ Bits 3, 4, and 5, referring
respectively to Frames B and C, Frames B and D, and
Frames C and D, will remain logic 0. Upon re~erence to
Frame ~, Bits 0 and l, referring respectively to Frames A
and B and Frames A and C, will remain logic l's. Bit 2,
referring to Frames A and D, will be changed ~rom logic l
to logic 0 to indicate that Frame D has been referred to
more recently than Frame A. Bi 3, re~erring to Frames B
and C, wilI remain logic 0. Bits ~ and 5, referring
respectively to Frames ~ and D and Frames C and Dl will
be written as logic 0, although they are already logic
zeros, to indicate respectively that Frame D has been
used more recentLy than Frame B or Frame C~ Upon
reference to Frame B, Bit 0, referring to Frames A and B,
-
11~79~16~
-283-
will be written to logic 0 to indicate ~hat Frame B has
been used more recently than Frame A. Bits l and 2,
referring resectively to Frames A and C and Frames A and
D, will remain respectively as logic 1 and logic 0. Bits
three and four, referring respectively to Frames B and C
and Frames B and D, will be written as logics l's to
indicate respectively ~hat Frame B has been used more
recently than Frame C or Frame D. Bit five will r~main
logic 0.
When it is necessary to replace a cache entry in a
particular frame, the LRUL 24080 word referring to the
cache ~et containing that frame will be read from L~U~
24080's MLRL 24081 through LRU Register (RLRU) 24085 and
decoded by LRU Decode Logic (LRUD) 24087 to indicate
which is least recently used frame. This decoding is
executed by means of a Read Only Memory operating as a
set of decoding gating.
~aving described the struc~ure and operation of a
. generalized cache as shown in Fig. 240, with references
to ~C 10226 for illustration .and to point out differences
between the generalize~ cache and ~C 10226, structure and
operation of AT~ 10228 and PC 10234 will be described
next bslow. ATU 10228 and PC 10234 will be described by
describing the differences between A~U 10228 and PC 10234
and the generalized cache and NC 10226. ATU 10228 will
be described first, followed by PC 10234.
~79(~3
-284-
d.d. ~ .
ATU 10228 is a three-way, set associative cache of 16
sets, that is contains 3 frames ~or each set. Stxucture
and operation of ATU 10~28 is similar to the generalized
cache described above. Havin~ 3 rather than 4 frames per
set, ATU 10228 does not include a STD 24018, ATSCE 24026,
ATSPRD 24034, ATSHED 24042, or ADSD 24058. As previously
described ATU 10228 address inputs comprise AON and O
fields o~ logical descriptors. AON fields are each 28
bits and O fields comprise the 18 most significant bits
of logical descriptor offset fields, 50 that ATU 10228
address inputs are 48 bits wide. Four least significant
bits of O fields are used as index. AON fields and the
14 most significant bits of O field comprLse ATU 10228's
tags. ATU 10228 tags are thereby each 42 bits in width.
Accordingly, TSA 24012, TSB 24014, and TSC 24016 of ATU
10228's TS 24010 are each 16 words long by 42 bits wide~
DSA 24052, DSB 24054, and DSC 24056 of ATU 10228 are
each 16 bi~s long. ATU 10228 outputs are, as previously
described, physical descrip~or Frame Number (F~) fields
of 13 bits each. ATU 10228's DSA 24052, DSB 24054, DSC
24056 are thereby each 13 bits wide.
ATU 10228's LRUL 24080 is similar in structure and
25 operation to that of the generalized cache. ATU 12028's
LRUL 24080 words, each corresponding to an AT~ 10228 set~
are each 3 bits in width as 3 bits are sufficient to
indicate relative usage of frames within a 3 frame setO
9 ~ ~ 3
-285-
In ATU 10228, Bit 1 of an LRUL 24080 word indicates
whether Frame A was used more recently than Frame B, Bit
2 whether Frame A was used more recently than Frame C,
and Bit 3 whether Frame B was used more recently than
Frame C. In all other respects, other than as stated
above, ATU 10228 is similar in s~ructure and operation to
the generalized cache.
Referring to PC 10234, PC 10234 is a two-way, set
associative cache of 8 sets, that is has two frames per
et. Having 2 rather than 4 frames, PC 10234 will not
include a TSC 24016, a TSD 24018, a TSCC 24024, a TSCD
24026, a TSPRC 24032, a TSPRD 24034, a TS~EC 24040, a
TS~ED 24042, a DSC 24056, or a DSD 24~58.
Address inputs of PC 10234 are the 28 bit AON fields
o~ 1O5ical descriptors. The 3 least significant bits of
those AON fields are utili2ed as indexes for addressing
PC 10234's TS 24010 and DS 240S0. The 25 most
significant bits of those AO~ field address inputs are
utilized as PC 10234's tags, so that PC 10234's TSA 24012
and TSB 24014 are each 8 word by 25 bit memories.
Referring to PC 10234's LRUh 24080, a single bit is
sufficient to indicate which of the two fràmes in each of
PC 10234's sets was most ~ecently accessed. PC 10234's
LRUL 24080's memory is thereby 8 words, or sets long, one
bit wide.
As previously described, PC 10234 entries ccmprise
information regarding access xights of certain active
subjects to certain active objects. Each PC 10234 entry
contains 35 bits of information. Three bits of this
information indicate whether a particular subject was
,
~7~ ~ 3
-286-
read, write, or execute rights relative to a particular
object. The remaining 32 bits effectively compr1se a
length field indicati~g the volume or portion, that is
the number of data bits, of that object to which those
access rights pertain.
Referring again to Fig. 240, PC 10234 differs from
the generalized cache and from NC 10226 and ATU 10228 in
further including Extent ~heck Logic (EXTC~) 24082 and
Operation Check Logic (OPRCHR~ 24034. PC 10234 entries
include, as described above, 3 bits identifying type of
access rights a par~icular sub~ect has to a par~icular
object. These 3 bits, representing a Read ~), Write
(W), or Execute (E) right, are provided to a first input
of OPRC~K 24084. A second input of OPRC~R 24084 is
provided from FUCTL 20214 and specifies whether JP 10114
intends ~o perform a Read (RI), a Write (WI), or Execute
(EI), operation with respect to that object. OPRC~X
24084 compares OPRCHK 24084 access right inputs from DS
24050 to OPRC~R 2~084's intended operation input from
FUCTL 20214. If that subject does not possess the rights
to that object which are re~uired to perform the
operation intended by JP 10114, OPRC~K 24084 gen~rates an
Operation Violation (OP~V) indicati~g that a pro~ection
violation has occurred.
Similarly, the 32 bits of a PC 10234 entry regarding
extent rights is provided as an input (EXTENT) to EXTCHK
24082. As stated above, EXTENT field of PC 10234 entry
indicates the length or number of data bits, within an
obect, to which those access rights pertain. EXTENT
field from PC 10234 entry is compared, by EXTC~R 24082,
79~63
-287-
to o~set field of the logical descriptor of the current
JP 10114 request to MEM 10112 for which a current
~rot~ction mechanism check is being made. If comparison
o~ extent rights and offset field indicate that the
current memory request goes beyond the objec~ length to
which the corresponding rights read from DS 24050 apply,
EXTCHg 24082 generates an Extent Violation (EXTV)
output. EXTV indicates that a current memory request by
JP 10114 refers to a portion of an object to which the PC
10234 entry read from ~S 24050 does not apply. As
described previously, each read from or write to MEM
10112t even as part of a string transfer, is a 32 bit
word. As such, EXTC~ 24082 will generate an EXTV output
when OFFSET field of a current logical descriptor
d@scribes a segment of an objec~ less than 32 bits from
the limit defined by EXTE~T field of the PC 10234 entry
provided in response to that logical descriptor. EXTV
and OPRV are gated together, by Protection Violation Gate
(PVG~ 24086 to generate Protection Violation (PROTV)
output indi ating that either an extent or an operation
violation has occurred.
~ aving described the structure and operation of
MEMINT 20212, and previously the structure and op2ration
of DESP 20210, structure and operation of FUCTL 20214
will be described next below.
79(163
--28~--
3.
The following descriptions will provide a detailed
description of FU 10120's struc~ure and operation.
Overall operation of ~U 10120 will be described first,
followed by description of FU 10120's structure, and
finally by a detailed description of ~U 10120 operation.
As previously described, FUCTL 20214 direc~s
operation o~ ~P 10114 in executing procedures of userls
processes. Among the functions performed by FUC~L 20214
are, first, main~enance and operation of CS 10110's Name
Spaee, UID, and AON based addressing system, previously
described; second, interpretation of SOPs of user's
processes to provide corresponding sequences of
microinstructions to FU 10120 and EU 10122 to control
operation of JP 10114 in execution of user's proc~sses,
previously described; and, third, control of operation of
CS 10110's internal mechanisms, for example CS 10110's
stack mechanisms~
As will be described in ~urther detail below, FUCTL
20214 includes Prefetcher (PR~F) 20260 which generates a
sequence of logical addresses, each logical address
comprising an AO~ and an offset field, for reading S-
Instructions ~SINs) of a user's program from MEM 10112.
As previously described, each SIN may be comprised o~ an
S-Operation ~SOP) and one or more operand Names and may
occupy one or more 32 bit words~ SI~s are read from MEM
10112 as a sequence o~ single 32 bit words, so that P~EF
:,
11~79~63
-289-
20260 need not specify a length field in a ME~ 10112 read
request for an SIN. SINs are read from MEM 10112 through
~OD Bus 10144 and are cap~ured and stored in Instruction
Buffer ~INSTB) 20262. PARSER 20264 extracts, or parses,
SOPs and op~rand Names from INSTB 20262. P~RSER 20264
provides operand ~ames to ~C 10226 and SOPs to FUS
Intrepreter Dispatch Table (FUSD~) 11010 and to EU
Dispatch Table (EUSDT~ 20266 through Op-Code Register
(OPCODEREG) 20268~ Operation of INSTB 20262 and PARSER
20264 is controlled by Current Program Counter (CPC)
20270, Initial Program Counter (IPC) 20272, and Executed
Program Counter (EPC) 20274.
As previously described, FUSDT 11010 provides, for
each SOP received from OPCODEREC 20268, a corresponding
S-Interpreter Dispatch (SD) Pointer, or address, to
FUSITT 11012 to select a corresponding sequence of
micrsinstructions to direct operation of JP 10114, in
particular FU 10120. As previously described, FUSITT
11012 also contains sequences of microinstructions for
20 controlling and directing operation of CS 10110's
internal mechanisms, ~or example those mechanisms such as
RCWS 10358 which are involved in swappi~g of processes~
EUSDT 20266 per~orms an analogous function with respect
to EU 10122 and provides SD Pointers to EU S-Interpreter
Tables (EUSI~Ts) residing in EU 10122.
Micro-Program Counter (mPC) 20276 provides sequential
addresses to FUSITT 11012 to select individual
microinstructions of sequences of microinstructions.
' .J
7~63
-290-
Branch and Case Logic (BRCASE) 20278 provides addresses
to FUSITT 11012 to select microinstructions sequences for
microinstructions branches and and cases~ Repeat Counter
~REPCTR) 20280 and Page Number Re~ister (P~REG) 20282
g provide addresses to FUSITT 11012 during FUSITT 11012
load operations~
As previously described, FUSI~T 11012 is a writable
microinstruction control store which is loaded with
selected S-Interpraters (SINTs) from ME~ 10112.
FUSITT 11012 addr~sses are also provided by Event
Logic (EVE~T) 20284 and by JA~ input from ~C 10226. As
will be described fur her below, EVENT 20284 is part of
FUCTL 20214's circuitry primarily concerned with
operation of CS 10110's intern~l mechani ms. Input JAM
from NC 10226 initiates certain ~UCTL ~0214 con.trol
functions for CS 10110's Name Space addressing
mechanisms, and in particular NC 10226. Selection
between the above discussed address inputs to FUSIT~
11012 is controlled by S-Interpreter Table Next Address
Generator Logic (SITT~AG) 20286~
Other portions of FUCTL 20214~s circuitry a~e
concerne~ with operation of C5 10110's internal
mechanisms. ~or example, FUC~L 20214 includes Return
Control Word Stack (RCWS) 10358, previously described
with reference to CS 10110's Stack Mechanisms. Register
Address Generator ~RAG) 20288 provides pointers for
addressing o~ GRF 10354 and RCWS 10358 and includes
Micro-Stack Pointer Registers (MISPR) 10356.
lLt~9~6~3 '
-291-
As previously describedt MISPR 103S6 mechanism
provides pointers for addressing Micro-Stack (MIS)
10368. As will be described further below, actual M~S
10368 Pointers pointing to current, previous, and bottom
frames of MIS 10368 reside in Micro-Control Word Register
1 ~MCWl) 20290. MCWl 20290 and Micro-Control Word Zero
Register (MCWO) 20.292 together contain certain
information indicating the current execution environment
o~ a microinstruction se~uence currently being executed
10 by FU 10120. This execution information is used in aide
of execution of these microinstruction sequences. State
Regis~ers (STATE) 20294 capture and store certain
information regarding state of operation of FU 10120. As
described further below~ this information, referred to as
state vectors, is used to enable and direct operation of
FU 10120.
Timers (TI~ERS) 20296 monitor elapsed time since
occurrence of the events requiring sPrvicing by FU 10120.
If waiting time for these events exceeds certain limits,
20 TIMERS 20296 indicate that ~hese limits have been
exceeded so that service o~ those events may be
initiated.
Finally, Fetch Unit to E Unit Interface Logic
(FUEUINT) 20298 comprises the FU 10120 portion of the
i~terface between ~U 10120 an ~U 1012~. FUEUINT 20298 is
primary path through which operation of FU 10120 and EU
10122 is coordinated.
Having described overall operation of FU 10120,
structure o~ FU 10120 will be described next below with
79Q63
-292-
aide of Fig~ 202! description of FU 101201S structur
will be followed by a dPtailed description ~f FU 10120
wherein furth~r, more detailed, diagrams of certain
portions of F~ 10120 will be introduced as required to
5 enhance clarity of presentationO
a.a. ~
Referring again to Fig. 202, as previously described
Fig. 202 includes a partial block diagram of FUCTL
10 20214. Following the same sequence of description as
above, PREF 20260 has a 28 bit bi-directional port
connected to AON Bus 20230 and 32 bit bi-directional port
directed from OFFSET B)us 202287 A control input of PREF
20260 is connected from control output of INSTB 20262.
INSTB 20262 32 bit data input (DI) is connected from
~OD Bus 10144. INSTB 20262's 16 bit output (DO) is
connected to 16 bit bi-directional input of OPCODEREG
20268 and to 16 bit NAME Bus 20224. OPCODE~EG 20268's
input comprises 8 bits o~ SI~T and 3 bits of dialect
20 selection. As previously described, NAME Bus 20224 is
connected to 16 bit bi-directional port of Name Trap (~T)
20254, to address input ADR of NC 10226, and to inputs
and outputs of OFFP 20228~ Control inputs of INSTB 20262
and YARSER 20264 are connected from a control output of
25 CPC 20270.
Thirty-two bit input of CPC 20270 is connected from
JPD Bus 10142 and CPC 20270's 32 bit output is connected
to 32 bit input of IPC 20272~ Thirty-two bit output of
IPC 20272 is connected to 32 bit input of EPC 20274 and
-293-
to JPD Bus 10142. EPC 20274's 32 bit output is similarly
connected to JPD Bus 10142.
Eleven bit outputs of OPCODEREG 20268 are connected
to 11 bit address inputs of FUSDT 11010 and EUSDT 20266.
These 11 bit addres~ inputs to FUSDT 11010 and EUSDT
2026Ç each comprise 3 bits of dialect selection code and
8 bits of SINT code. Twelve bit S~T outpu~s of EUSDT
20266 is connected to inputs of Microinstruction Control
Store in EU 10122, as will be described in a following
description of EU 10122. FUSDT 11010 has, as described
further below, two outputs connected to address (ADR) Bus
20298. First output of FUSDT 11010 are six bit SDT
pointers, or addresses, corresponding to generic SINTs as
will be described further below. Second output of FUSDT
11010 are 15 bit SDT pointers, or addresses, for
algorithm microinstruction sequences, again as will be
described further below.
Referring to RCWS 10358, RC~S 10358 has a first bi-
directional port connected from JPD Bus 10142r Second,
tnird~ and f~urth bi-directional p~rts of RCWS 10358 are
connected from, respectively, a bi-directional port of
MCWl 20290, a first bi-directional port Et7ENT 20284, and
a bi-direc~ional port of mPC 20276. P,n output of RCWS
10358 is connected to ADR Bus 20298.
An input of mPC 20276 is connected from ADR Bus 20298
and first and second outputs of mPC 20276 are connected
to, respectively, an input of BRCASE 20278 and to ADR Bus
20298 . An output of BRCASE 20278 is connecte~ to ADR Bus
20298 .
9~63
-294-
As described above, a first bi-directional port of
EVENT 20284 is connected to RCWS 10358. A second bi-
directional port of EVENT 20284 is connected from ~CWO
20292. An output of EVE~T 20284 is connected to ADR Bus
2~298.
Inputs of RPCTR 20280 and PNREG 20282 are connected
from JPD ~us 10142. Outputs of ~PCTR 20280 and PNREG
20282 are connected to ADR Bus 20298.
ADR Bus 20298, and an input from a first output of
FUSITT 11012, are connected to inputs of SITTNAG 20286.
Output of SITTNAG 20286 is-connected, through Control
Store Address ~CSA~R) Bus.20299t to address input of
FUSITT 11012. Data input of FUSITT 11012 is connected
from JPD Bus 10142. Control outputs of FUSIT~ 11012 are
connected to almost all elements of JP 10114 and ~hus,
for clarity of presentation, are not shown in detail by
drawn physical connections but are described in following
description~
As described above, MCWO 20292 and MCWl 202~0 have
bi-directional ports connected to, respectively, bi-
directional ports of E~ENT 20284 and to a second bi-
directional port of RCWS 10358. Outputs of ~CWO 20292
and MCWl 20290 are connected to JPD Bus 10142. Other
inputs of MCWO 20292 and MCWl 20290, as will be described
further below, are connected from several other elements
of JP 10114 and, for clarity of presen~a~ion, are not
shown herein in detail but are described in the following
text. STATE 20294 similarly has a lar~e number of inputs
~79~6~
-295-
and outputs connected from and to other elements of JP
10114, and in particular FU 10120~ Inputs and outputs of
STATE 20294 are not indicated here for clarity of
presentation and will be described in detail below.
RAG 20288 has an input connected from JPD Bus 10142
and other inputs connected, for example, ~rom MCWl
20290. RAG 20288, includin~ MISPR 10356, provides
outputs, for example, as address inputs to RCWS 10358 and
GRF 10354. Again, for clarity of presentation, inputs
10 and outputs of RAG 20288 are not shown in detail in Fig,
202 but will be described in detail further below.
TIMERS 20296 receive inputs from EVENT 20284 and
FUSITT 11012 and provide outputs to EVENT 20284. For
clarity of presentationt these indications are not shown
in detail in Fig. 202 but will be described urther
below.
FUINT 20298 receives control inputs from FUSITT 11012
and EU 10122. FUINT 20298 provides outputs to EU 10122
and to other elements of F~CTL 20214. For clarity of
20 presentation, connections to and from FUINT 20298 are not
shown in detail in FigO 202 but will be described in
further detail below.
Having described the overall operation, and
structure~ of FUCTL 20214, ope~atio~ o~ FUCTL 20214 will
25 be des~ribed next below. During the following
descriptions further diagrams of certain portion~ o~
F~CTL 20214 will be introduced as rP~uired to disclose
structure and operation o~ FUCTL 20214 to one of ordinary
~790f~3
-296- -
skill in the art. FUCTL 20214's operation with regard to
fetching and interpretation of SINs, that is SOPs and
operand Names, will he described first, followed by
description of FUC~L 20214's operation with regard to CS
10110's internal mechanisms.
. b.b. ~ Y~ n~ osi~=~
Referring ~irst to those elements of FUCTL 20214
directly concerned with control of JP 10114 in response
10 to SOPs and Name syllables, those elements include~
PREF 20260; (2) INSTB 20262; (3) PARSER 20264; (4~ CPC
20270, IPC 20~72, and EPC 20274; (5) OPCODEREG 20268; (6)
FUSDT 11010 and EUSDT 20266~ (7) mPC 20276; (8) BRCASE
20278; (9~ REPCTR 20280 and PNREG 20282; (10) a part of
15 RCWS 10358; (11) SITTNAG 20286; tl2) FUSITT 11012; and,
(13) NT 20254. These FUCTL 20214 elements will be
de cribed below in the order named.
a.aOa.
ZO
~_
As described above~ PREF 20260 generates a series of
25 addresses to MEM 10112 to read SINs of user's programs
from MEM 10112 to FUCTL 20214, and in particular to INSTB
20262. Each PREF 20260 read request transfers one 32 bit
word from MEM 10112. Each SIN may be comprised o~ an SOP
and one or more Name syllables. Each SOP may comprise,
30 for example, 8 bits of information while each Name
~79~63
-297-
syllabl.e may comprise, for example, 8, 12, or 16 bits of
data. In general, and as will be described in further
detail in a f~llowing description of STATE 20294, PREF
20260 obtains access to ~EM 10112 on alternate 110 nano-
second syste~ clock cycles. P~EF 20260's access to ~EM10112 is conditional upon INSTB 20262 indicating that
INSTB 20262 is ready to receive an SIN read from MEM
10112. In particular, INSTB 20262 ~enerates control
output Quiry Prefetch (QP~) to PREF 20260 to enable PREF
10 20260 to submit a request to MEM 10112 when, as described
further below, INSTB 20262 is ready to receive an SIN
read from MEM 10112.
~ REF 20260 is a counter register comprised, for
example of SN74S163s.
Bi-directional inputs and outputs of PREF 20260 are
connected to AON Bus 20230 and OFFSET Bus 20228. As PREF
20260 reads only single 32 bit words, PREF 20260 is not
required to specify a LENGT~ field as part of an SIN read
request, that is an AON and an OFFSET field are
20 sufficient to define a single 32 bit word. At start of
read of a sequence of SIMs from MEM 10112, address ~AON
and OFFSET fields) o first 32 bit word of that SIN
sequence are provided to ~E~ 10112 by DESP 20210 and
concurrently loaded, from AON 8us 20230 and OFFSET Bus
25 20228, into PREF 20260. Thereafter, as each successive
thirty-two bit word o~ the SIN's sequence is read from
MEM 10112, the address residing in PREF 20260 is
incremented to specify successive 32 bit words of that
9(~63
-298-
SIN's sequence. The successive single word addresses
are, for all words after first word of a sequence,
provided to MEM 10112 from PREF 20260.
As described above, I~STB 20262 receives SINs from
~E~ 10112 through ~OD Bus 10144 and, with PARSER 20264
and operating under control of CPC 20270, provides Name
syllables to NA~E Bus 20224 and SINs to OPCODE~EG 20268.
INSTB 2026~ is provided, together with PRE~ 20260 to
increase execution speed of SINS.
Referring to ~ig. 241, a more detailed block diagram
of INSTB 20262, PARSER 20264, CPC 20270, IPC 20272, EPC
20274 as shown. INSTB 20262 is shown as comprising two
32 bit registers having parallel 32 bit inputs from ~OD
Bus 10144. INS~B 20262 also receives two Write Clock
(WC) inputs, one for each 32 bit regis~er of INSTB 20262,
from Instruction Buffer Write Control (I~STB~C) 24110.
INSTB 20262's outputs are structured as eight, eight bit
Basic Syllables (BSs) r indica~ed as ~SO to BS7. BSO,
BS2, BS4, and BS6 are ORed to comprise eight bit Basic
20 Syllable, Even (BSE) of INSTB 20262 while BSO, BS3, BS5,
and BS7 are similarly ORed to comprise Basic Syllable,
Odd ~BSO) of INSTB 20262. ~SO and BSE are provided as
inputs of PARSE~ 20264.
PARSER 20264 receives a first control input from
25 Current Syllable Size Register (CSSR) 24112, associated.
with CPC 20270. A second control input of PARSER 20264
is provided from Instruction Buffer Syllable Decode
Register (IBSDECR) 24114, also associa ed with CPC
20270. PARSER 20264 provides an eight bit output to NAME
30 Bus 20224 and to input of OPCODEREG 20268.
DEMANDES OU E~RE~ETS VOLlllVllNEl.lX
LA PRI~SENTE PARl~IE DE CETTE DEMANDE OU CE BREVET
COMPREND PLUS l)'UN TOME.
( 3
CE~ ST LE TOME IDE
NOTE: Pour les tomes addit;onels, vQuille con~actel le Bureau canadien des
brevets
/1 ~ ~ 6~
.
JUMBO APPLlCATlONS/P~TENTg~
THIS SECTION OF THE APPLIG~TION/PATEIUT CONTAIINS MOP~E
THAN ONE VOLUME
1 7
THIS IS VOLUNIE I OF ~
. ~
NOTE: For additional volumes please contact the Canadian Patent Offlce
