Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
DEMANE3ES OU IBREVETS VOaalJMlNEUX
LA PIR~SENTE~ PAP~TIE DE CETTE DE~IAINDE 0U CE BREVET
C:OMPREND PLUS D'UN TONlE~.
~`: -3
CECI EST L TOIVIE ~ DE
NOTE: Pour 1~5 tome addltioncb, veuillez contacter le Bureau c~nadien de~
brevet~
....... ~
'
JUMBO APIPLIC:ATIONS/PATENTS
~ "
T1115 SECTION OF ~HE APPLIICATION/P~TENT CONT~IIYS NIC)P~E
,. ; Tl IAN ONE VOLUIVIE
, 3
THI~i; IS VC)LUME ~ OF _
'
~ NOTE: For addllion~l volumes pl~a~e cont~ct the Canadian P~tent Offlce
:,
.,
,, .
s, ' ' ' ' ' . ,.
: . , '
.. . .
,
~, ,
~, ' ' '
~,'. , .
3 1~?~7~
CROSS REFE~ENCE TO RELATED APPLICATIONS
The present patent application is related to other
patent applications assigned to the assignee of the
5 present application.
: .
BACRGROUND OF T~E I~VENTION
l. Field of the Invention
~ he present invention relates ~o a digital data
processing system and, more particularly, to a
10 multiprocess digital data processing system suitable for
use in a data processing networ~ and having a qimplified,
flexible user interface and flexible, multileveled
internal mechanismsO
~' 2~ Description o~ Prior Art
A general trend in the devPlopment o~ data processing
:~ sy~tems has been towards systems suitable for use in
~i. interconnected data processing networks. Another trend
has been towards data processing systems wherein the
internal structure o the system is flexibl~, protecte~
from users, and effectively invisible to the user and
wherein the user is presented with a flexible and
Yimplified interface to ~he system.
:~ Certain problems and shortcomings af~ecting the
re~lixation 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 ~imitations
-~ include the following topics.
i, .
:, ' .
,'. :'
, . . .
,,.
- . . , - , . - . . .
. ., . " . ~ ", s , " ,
: . ~ ~ , , . . ,, ~ , . .
. ~,................ ,. . , ~, ' '
.
;, . . . .
: ; .
~4766
-2-
First, the data processing systems of the prior ar~
have not provided a system wide addressing system
suitable for use in common by a large number of data
processing systems interconnected into a ne~work.
Addressing systems of the prior art have not provided
sufficiently large address spaces and have not allowed
informaticn to be permanently and uniquely identified.
Prior addressing systems have not made provisions for
information to be located and identified as to type or
format, and have not provided sufficient granularity~ In
addition~ prior addressing systems have reflected the
physical structure of particular data processing
systems. ~hat is, the addressing systems have been
. dependent upon w~ether a particular computer was, for
~ 15 example, an 8, 16, 32, 64 or 128 bit machine. Since
:~ prior data processing systems have incorporated
addressin~ mechanisms wherein the actual physical
~tructure of the processing system is apparent to the
user, the operations a user could perform have been
: 20 limited by the addressing mechanismsO In addition, prior
.
^~ processor systems h~ve operated as fixed word length
~-~ machines, further limiting user operations.
Prior data processing systems have not provided
.~ ef~ective prot~tion mechanisms preven~ing one user from
effecting another user's data and programs without
permissionO Such protection mechanisms have not allowed
unique, positive identification of users requesting
....
', ' : '. ' . ~ :
' '
.- ... .
, . . .
--3--
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 than to the information, so that control of access
rights has been dif f icult . ~inally, pr ior art protection
` mechanisms have allowed the use of "Trojan Horse
: arguments~O Tha~ is, users not having access riyhts to
certain information have been able to gain access to that
information through another user or procedure having such
access rights~
Yet another problem of the prior art is that of
: providing a simple and flexible interface user interface
to a data proces~ing system. The charac~er 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 proceclures of the user's pro~rams
:~ and by the instruction structLIre of the system. Operands
:~ and procedures are customarily re~erred to and identified
by some form of logical address having points of
reference, and validity, only within a user's progr~m~
These addresses must be translated into logical and
~;~ physical addresses within a data processing system each
time a program is execu~ed, and must then be frequently
retranslated or generated during execution of a program.
; 25 In addition, a user must provide speci~ic instruction~ as
to data format and handling. As such reference to
~ operands or procedures typically comprise a major portion
',': ;
'' :
'.'' - t~j :
,. ' '.
. ' `' .
"~" ' '. . , ' . ' ' ., ' '
~, , ' ' ' ' ' ' ', , .' ' ' '' '
/' ' ' ; .' .
' ' ' . . . '
~' ' ' , , ~ ' ' ' " ' ' " ' ' ';' '
4--
.
of the instruction stream of the user's progra~ and
requires numerous machin translation~ and operations to
implement. A usPr's interface ~o a conventional system
. is thereby complicated, and the speed of execution of
programs reduced, because of the complexity of the
proyram ref erences 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 instruction~ are
: 10 executedO Conventional data processing systems are
designed to efficiently execute instructions in one or
two user languages, for example, FORTRAN or COBOL.
~ Programs written in any other language are not
; efficiently executable. In addition, a user is often
L5 faced with difficult programming problems when using any
high level language other than the particular one or two
languages that a particular conventionaL system is
; designed to utilize.
; Yet another problem in conventional data processing
systems is that of protecting the system's internal
me~hanism~, for example, stack mechanisms and internal
control mechanism~, from accidental or malicious
: inter~erence by a userG
Fina~ly, the internal structure and operation of
prior art data processing systems have not been flexible,
or adaptive, in structure and opera~ionO That is, thP
internal structure structure and operation of prior
systems have not allowed the systems to be easily
, :
~, . .
,
: ,
. ' ~ ., ~ ,, :
. . . . .
.
~'747~ '
: .
-5-
modified or adapked to meet particular data processing
requirem2nts. Such modifications may include changes in
: inte~nal memory capacity, such as the addition or deletion of special purpo~ subsystems, for example,
. 5 floating point or array processors. In addition, such
modifications have significantly effected the users
in~erface with the sy~tem. Ideally, the actual physical
structure and opera~ion of the data processing system
should not be apparent at the user interface.
The present invention provides data pr~cessing system
improvementæ and features which solve the above-described
problems and limitations.
The present invention relates to structure and
opera~ion of a data processing system suitable for use in
`- interconnected data processing networks, which internal
structure is flexible, protect.ed from users, effectively
~; invisible to users, and provicles a ~lexible and
simplified interace to users. The data processing
sy~tem provides an addressing mechanism allowin~
~ permanent and unique identification o~ all information
:, ~enerated for use in or by operation of the sy~em, and
an extremely large address space which i5 accessible to
; and common to all such data processing systems, The
: 25 addressing mechanism provides addresses which are
independent of the physical configuration of ~he system
and allow information to be comple~ely identified, with a
s "
~. :
.. ' ~ .
, - . ,. , ~ - , . , . .; .
~ , :-,. . . .` ` . :
. , . . . , : ,
:
,: ' ` :
~:,'` ~ , :' ' :
, . .
'? '~ .
-6- 9
single address, ~o the bit granular ~evel and with regard
to information type or form~t. The present invention
further provides a protection mechanism wherein variable
access rights are associated with individual bodies of
in~ormation, Information, and users requesting access to
information, are uniquely identified through the system
addressing mechanism. The protection mechanism also
~ prevents use of Trojan ~orse argumentsc And, the present
`~ invention provides an instruction s~ructure wherein high
;~ 10 level user language instructions are ~ransformed into
dialect coded, unifo~m, interme~iate level instructions
`-~ to provide equal facility of execution for a plurality of
- user languages. Another f~ature 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 addressesO The present invention additionally
~: provides multilevel control and stack mechanisms
protecting the system's internal mechani~m from
interference hy users. Ye~ another ~eature is a data
~ processing syst~m having a ~lexible internal structure
i capable of performing multiple, concurrent operations and
~-- c~mprised o a plurality of separate, independent
`: processors. Each such independent processor has a
' 25 separate microinstruGtion control and at least one
,~ separate and independent port to a central communications
- and memory node. The communications and memory node is
~ also an independent processor having separate and
,, . ~
: ' .
~. .
,~ , . . .
~: ' ' '. ~ ~ ' ,
~L7~7~ i
--7--
ind~pend~nt microinstruction con~rol. The memory
processor is internally comprised of a plurality o
: independently operating, microinqtruction controlled
processors capable of performing multiple, concurrent
S memory and communications operations. The present
:~ invention also provides further data processing system
structural and opera~ional 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 sui~able ~'
for use in large interconnected data proc~ssing
~ networks. Additionally, the present invention is
.. advantageous in that it provid~es an information
:~ 15 pro~ection mechanism suitable :Eor use in large,
interconnected data processing networ~s. The present
. .. : .
~:` invention is further advanta~eous in tha~ it provides a
: simpli~ied, flexible, and more efficient interface to a
data processing system. The present inven~ion is yet
further advantageous in that it provides a data
:~ processing system which is e~ually e~ficient with any
: ùser level language by providing a m~chanism for ~:
: referring to operands in user programs by uniform format
:~ name~ and instruction structure incorporating dialect
. 25 coded, uniform format intermediate level instructions.
- Additionally, the present invention protects data
processing system internal mechanisms from user
: inter~erence by providing multilevel control and stack
i'; ' '
. ........................................................................ .
. .
.~ ,
..
,. . .
', "~
.
,,.,.. ... . . - , . . . . ,
:: . .,~ .- : - .
.. . ..
,, . : i ~ .. .
., ., ~ .
.. .. ..
` ` ~
~ 7
:~ -B-
mechanisms. The present invention is yet further
advantagaous in providing a flexible intexnal system
-structure capable of performiny multipler concurrent
operations, comprising a plurality of separate,
independent processors, each having a separate
. .
microinstruction control and at least one separate and
independent port to a central, independant communications
and memory processor comprised of a plurality of
independen~ processors capable of per~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 anothe~ object of the present invention to
provide a data processing system capable of use in large,
interconnected data processinq networks.
It is yet another object o~ the present invention to
:provide an improved addressinq mechanism suitable for use
in large, interconnected data processing networks.
It is a further object of the present invention to
~20 provide an improved information protec~ion mechanism.
,:It is still another obj@ct; of the present invention
:to provide a simplified and flexible user interface to a
data processing system.
;lIt is yet a further o~ject of the present invention
:~25 to provide an improved mechanism for refe~ring to
~ operandsO
,.It is a still further object o the present invention
~to provide an instruction structure allowing efficient
,. ,
,. . .
.
.
;'
,. .
, ., , ~-,. . . .
,. .. . ..
~ : .
~' ' .
g_
data processing system operation with a plurality o~ high
level user language~.
: It is a further object of the present invention to
provide data processing internal mechanisms protected
: 5 from user in erference.
It is yet another object 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 re~erring to the following detailed '!
description of the preferred embodiments and drawings - ~
wherein: ~ :
~ D~ E~ 2
:
Fig. 1 is a partial block diagram of a computer
system incorporating the present invention;
~ig. 2 is a diagram illustrating computer system
addressing structure of the present invention;
:` 20 ~ig. 3 i~ a diagrala illustrating the computer
system instruction stream of the present invention;
Fig. 4 is a diagram illustrating the control
- structure of a conventional computer system;
FigO 4A is a diagram illustrating the con~rol
~t.ructure of a computer ~ystem incorporating the present
~ invention;
: Fig. 5 - Fig. Al inclusive are diagrams all
.~ relating to thP present invention;
' .:'
':
't
'''' '
.~
'
. .
.'' . ' ' , ' ' . , ' ., . ' :
~' ' ' " ' ' : ~ ' ' '' ,, ', , :
.
1 0
:
~ig. 5 is a diagram illustrating a stack
mechanlsm~
- Fig. 5 is a diagram illu~trating procedures,
procedure objects, processes, and virtual proceSsorst
Fig~ 7 is a diagxam illus~rating operating
levels and mechanisms of the present computer;
Fig. 8 is a diagram illustrating a physical
implementation of processe~ and virtual processor~;
Fig. 9 is ~ diagram illustrating a process and
10 ~process stack objects;
ig. lO is a diagram illustrating operation of
~ macrostacks and secure stacks;
.;~ FigO 11 is a diagram illustrating detailed
structure of a stack;
Fig. 12 is a diagram illustrating a physical
descriptor;
Fig. 13 is a diagram illustrating the
relationship between logical pages and ~rames in a memory
~torage space;
~ig. 14 is a dia~ram illustrat1ng access control
to ob~ects;
~' FigO 15 i~ a diagram illustrating virtual
; proce~sor and.virtual proces~or swapping;
Fig~ 16 is a partial block diasram of an I/O
i 25 sy~tem o~ the present computer system;
Fig. 17 is a diagram illustrating operation of a
. ring grant generator;
:~ .
.,, ~
.. . .
, . .
.. ..
.,, ..
,.~ .
:,' '
. .
';' . ,." '"' ' ' "'
',. ," I ' :
,
~L~L7~76f~
11 -
: Fig. 18 is a partial block di~gram of a memory
system;
. ~ig. 19 is a partial block diagram o a ~etch
- unit of the present computer system;
Fig~ 20 is a partial block diagram of an ~xecute
- unit of he present computer system;
Fig. 101 is a more detailed partial block
diagr~m of the present computer system;
:~ Fig. 102 is a diagram illustrating cer~ain
information structures and mechanisms of the present
computer system;
~: Fig. 103 is a dia~ram illustrating process
. struc~ures;
~ Fig. 104 is a diagram illustrating a macrostack
`~` 15 structure;
~. Fig. 105 is a diagram illustrating a secure
,,; stack structure;
Figs. 106 A, B, and C: a~e diagrams illustrating
the ddressing structure of the present computer system;
!,'' 20 Fig~ 107 is a diagram illustrating addressing
. mechanisms of the present computer system;
- Fig. 108 is a diagram illustra~ing a name table
entry;
. Fig~ 109 is a diagram illustrating protectiQn
~ 25 mechanisms of the present computer system;
;:. Fig. 110 is a diagram illustrating instruction
and microinstruction mechanism of the present computer
:: . system;
: ~ .
,~ :. .
~''''' ~;
i .,
,, i ., ,
l .
,
. . , -- - . :
, . : . . ,
.. , . . : , ,.
. . .
,. . .
, ~ ,
~ 7~7~ E;
~12
Fig. 201 is a detailed block diagram o~ a memory
system;
Fig. 202 is a detailed block diagram of a fetch
unit;
~ig. 203 is a detailed block diagram of an
execute unit;
YigO 204 is a detailed block diagram of an I/0
system;
Fig. 205 is a partial block diagram of a
diagnostic processor system;
;~ Fig. 206 is a diagram illustrating assembly of
.: Figs. 201 205 to form a detailed block diagram of the
present computer system; : :
. Fig. 207 is a detailed block diagram of a memory
" 15 interface controller;
:: Fig. 209 îs a diagram of a memory to I/0 system
port interface;
Fig. 210 is a diagram of a memory operand port
-` interface;
~ig~ 211 is a diagram o~ a memory instru~tion
port interfaca;
: Fig~ 230 is a detailed block dia~ram of memory
ield interface unit logic;
Fig. 231 is a diagram illustrating memory format
. 25 manipulation operations;
Fi~. 238 is a detailed block diagram of fetch
unit offset multiplexer;
.~
, ~ ~
':~
, , - .. .
:
,~ .
.
, . . .
. . ~ ' ' ' :,:
; ~7~1~6~i
., .
-13-
Fig. 239 is a detailed block diagram of fetch
unit bias logic;
Fig. 240 is a detailed block diagram of a
;generalized four way, set associati~e cache representing
: 5 name cache, protection cache, and address translation
unit;
Fig. 241 is a detailed block diagram of portions
: of computer system instruction and microinstruction
control logic;
Fi~. 242 is a de~ailed block diagram of poxtions
of computer system microinstruction control logic;
: Fig. 243 is a detailed block diagram of further
portions of computer system microinstruction control
~` logic;
Fig. 244 is a diagra$l illustrating co~puter
system states of operation;
Fig. 245 is a diagram illustrating computer
.`3ystem states of operation for a trace trap request;
. 246 is a diagram illustrating computer
~20 ~ystem states of operation for a memoxy repeat interrupt;
.. ~ Figc 247 is a diagræm illustrating priority
.~ level and masking of computer system events;
.` ~ig. 24~ is a detailed block diagram of event
; logic;
`. 25Fig. 249 is a detailed bloc~ dia~ram of
:: ~icroinstruction control store logic;
Fig. 251 is a diagram illustrating a return
control word stack word;
:;.
~,
,
:
,
. . . . . .
~,'' ` ' ' . .. ` ' ' ': .
~ , . . . .
7~ ~ ~6
~14-
Fig. 252 is 2 diagram illustrating machine
control words;
Fig. 2S3 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
` uni~ control logic;
FigO 257 is a detailed block diagram of execute
: 10 unit multiplier data paths and memory;
.. : Fig. 260 is a diagram illustratin~ operation of
an execute unit command queue load and interface to a
~etch unit;
Fig. 261 is a diagram illustrating operation o
an execute unit operand buffer load and inter~ace to a
fetch unit;
Fig. 262 is a diagr~m illustra~in~ operation of
;.~ an execute unit storeback or transfer of results and
~: interface to a fetch unit;
~ 20 Fig~ 263 is a diagram illustrating operation of
.-: an execute unit che~k test condition and interface to a
`~ fetrh unit;
~ig~ 264 is a dia~ram illustrating operation of
an execute unit exception test and interface to a fetch
:: 25 unitî
Fig. 265 is a block diagram of an execute unit
~ arithmetic operation ~tack mechanism;
';'- , :
:.
.', ~ ' ~'''
, .
., ~ .
~ ~ .
.~; . . ..
. ~ , . . . . .
:. , ~ , , -
.~ ,~ .
:, .
. .
~ 15-
,'
Fig. 2~6 is a diagram illustrating execute unit
and fetch unit interrup~ handshaking and inter~ace;
~ Fig. 267 is a diagram illustrating execute unit
: and fetch unit interface and operation for nested
interruptst
Fig. 268 is a diagram illustrating execute unit
and ~etch unit interface and operation for loading an
execute unit control store;
Fig. 269 is a detailed block diagra~ and
: 10 illustration of operation of an I/O system ring grant
generator;
~Fig. 270 is a detailed block diagram of a fetch
unit micromachine Qf the presen computer system;
.- FigO 271 is a diagram illustrating a logical
descriptor;
.~: Fig. 272 is a diagram illustrating use of fetch
` uni~ stack regis~ers;
: Fig. 273 is a diagram ilustrating struc~ures
~ controlling event invocations;
. 20 Fig. 301 is a diagram illustrating pointer
.
-~ formats; .
. FigO 302 is a diagram illustra~ing an associated
address table;
;~ ~ig. 303 i~ a diagram illus~xating a namespace
overview of a procedure object;
Fig. 304 is a diagram illustrating name table
~ entries;
.~
. .
i .
.~: . ~
.J
, .' .
': ' . .
:, . . . .
,. ' , ~
", . , ' ' , .
'
7'~
-16-
Fig. 305 is a diagram illustrating an example of
- name rasolution;
FigO 306 is a diagram illu~trating name cache
entries;
Fig. 307 is a diayram illustrating translation
of S-interpreter universal identifiers to dialect
:; numbers;
Fig. ~01 is a diagram illustrating operating
systems and system resources;
; lO ~ig. 402 is a diagram illustrating multiprocess
. ~ operating systems;
.. ~ig. 403 is a diagram illus~rating an extended
:~ operating system and a kernel operating system,
~ig. 404 is a diagram illu~trating an EOS view
o objec~s;
Fig. 405 is a diagram illustrating pathnames to
: universal identifier translation;
Fig. 406 is a diagram illustrating uni~ersal
~: identi~ier detail;
Fig~ 407 is a dlagram illu~trating address
~ranslation with an address translation unit, a memory
.~ hash table, and a memory;
:: Fig. 408 is a diagram illustrating hashing in an
~ ac~iYe subject table;
.:~ 25 Fig~ 409 is a diagram illustrating logical
:;: allocation units and ob~ects; :: :
~.:
:''
~: '
,, ~
,~. .
,. ..
: - .
:. '
i. . . . . . .
.
,. .. . .. . ... . .
,, ,, :........................ :
:, ~ ., . : ,
,: - , . :
,: . , , . :
,: , .
.
: ~17-
:, .
Fig. 410 is a diagram illustra~ing an active
logical allocation unit table and active allocation
unitsf
Fig. 411 is a diagram illus~rating a conceptual
logical allocation unit directory structure;
. FigO 412 is a diagram illustrating detail of a
logical allocation unit directory entry
.~ Fig. 413 is a diagram illustrating universal
identifiers and ac~ive object numbers;
Eig. 416 is a diagram illustrating subject
templatesJ primitive access control list entries, and
extended access contxol list entries;
:; Fig. 421 is a diagram illustrating an active
primitive access matrix and an active primitive access
~atrix entry;
Fig. 422 is a diagram illustrating primitive
data access checking;
Fig. 448 is a diagram illustrating event
~ counters and await entries;
: 20 Fig. 449 is a diagram illustrating an await
:; table overview;
Fig. ~53 is a diagram illustrating an overvi~w
of a virtual processor;
~ig~ 454 is a diagram illustrating virtual .,.
processor synchronization;
~ig. 467 is a diagram illustrating an overview
of a macrostack object;
.'~ `` .
.~ .'
~ . .
.,
~ ~ .
.
- .
.
. .
'176
~: ~18-
Fig. 468 is a diagram illustrating details of a
macrostack objec'c bzse;
Fig. 46g is a diagram illustrating details of a
macrostack ~rame;
Fig. 470 is a diayram illustrating an overview
of a secure stack,
~ig. 471 is a diagram illustrating details of a
secure stack frame; andJ
Fig. 472 is a diagram illustrating an overview
`: 10 o~ procedure object.
The following description presents the struc~ure and
-~ operation of a computer system incorporating a presently
preferred embodiment of the p~esent invention. As
indicated in the following Table o Contents, certain
features of computer system st:ructure and operation will
.~ first be described in an ~ntroductory Overview. Next,
the~e and other features will ~e described in further
detail in a more detailed Introduction to the detailed
descriptions of the computer system. Following the
; Introduction, the structure and operation o 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 r and of overall computer
system operation~ Next, certain features of the
operation of the individual subsystems will be presented
in ~urther detail.
'"' ~
i .
,~ .
, . - , .
; , - . .
, , .,.; .
. , , . : :
~ 7~7~ ~
- Certain conventions are used throughout the following
descriptions to enhance clarlty of presentation~ First,
.~ and with exception of the Introductory Overview, each
figure referred to in the ~ollowing descriptions will be
~ 5 re~erred to by a three digit number. The most
: significant digit represents the number of the chapter in
the following description~ in which a particular figure
is first ref~rred to. The two least signi~icant digits
- represent the sequential number of appearance of a figure
in a particular chapteru For example, ~igure 319 would
~ be the nineteenth figure appearing in the third chapter.
: ~igures appearing ln 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
. 15 Overview. It should be noted that certain figure
~ numbers, for example, Figure 208, do not appear in the
; followin~ figures and descriptions; the subject matter of
these figures has been incorporated in~o other fisures
r~, and 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 c~rresponding elements first appear. For
;~ 25 example, reference numerals 31901 to 31999 would refer to
elements 1 through 99 appearing in Fig. 319.
.~ .
.
~.
`
: . -
, .. .
' .
, . . .
.. . . . .
7 ~7
-20-
Finally, int~rconnections between related circui~ry
is represented in ~wo waysO First, to enhance clarity of
presentation, interconnections betwsen circuitry may be
: represented by common signal name~ or referenGes, rather
than by drawn representa~ions of wires or busesO Second,
where related circuitry is shown in two or more ~igures,
the figures may share a common figure number and will be
distinguished by a letter designation, for example, Figs.
319, 319A, and 3I9B. Common electrical points between
such circuitry may be indicated by a bracket enclosing a
lead to such a point and a designation of the form A-bn.
"A" indicates other ~iyures having the same common point
for example, 319A, and "b" designates the particular
:~ common electrical point. In cases of related circuitry
.~ 15 shown in this manner in two or more figures, reference
:: numerals to elements will be assigned in sequence through
the group of figures; the figure number portion of such
~ reference numerals will be that of the first ~igure of
:~ the group of fisures.
., .
20 5b5 ~L~ ss~:ec
ardware Overview tFig. 1)
B~ Individual Operating Features (Figs. 2, 3, 4, 5, 6)
: 1. Addressing (Fig. 2)
:; 2. S-Language Instructions and Namespace Addressing
. 25 (FigO 3)
: 3. Architectural Base Pointe~ Addressing
~ ~. Stack Mechanisms tFigs. 4-5)
,
,:
;','' '
, .......................... .
' :~
'
. : :
:; . . . . .
.. . . : . . .
,.
.
. : . ' '. ' , ' '' ~:' '
. .
:
~'7'~766
-21-
.::
C. Procedure Process~s and Virtual Proces~ors (Fig. 6~
Do CS 101 Overall Structure and Operation (Fig~O 7, 8 r
9, 10, 11, 12, 13, 14, 15)
lo Introduction (Fig. 7)
2O Compilers 702 ~FigO 7)
3. Binder 703 (Fig. 7)
4. EOS 704 (Fig. 7)
:- 5. KOS and Architectural Interface 708 (Flg. 7)
6~ Processes 610 and Virtual Processors 612 (Fig.
8)
7. Processes 610 and Stacks (Fig. 9)
: 8. Processes 610 and Calls (Figs. 10, 11)
9. Memory References and the Virtual Memory
Management System (Fig. 12, 13)
~: 15 10. Access Control (FigO 14)
.~ 11. Virtual Processors and Virtual Processor
Swapping ~Fig. 15)
. E. ~S 101 Structural Implemelltation (Figs. 16f 17~ 18r
~:~ 19, 20)
1. (IOS) 11~ l~igs. 16, 17)
2. ~emory (MEM) 112 (Eig~ 18)
;~ 3. Fetch Unit ~FU) 120 (Fig. 19)
~:-; 4. . Execute Unit (E~) 122 ~Fig. 2~)
,'
i; 25 A. General Structure and Operation (Fig~ 101)
, ~ a~ General Structure
bo Ge~ral Operation
.
~s
,:.
'
.,
~'
',l''
:~ . . . . . . . .
~': `.: '. . .. :. '
: :- ~ . . .
'~ ` ' ' ~ ': , . "
. . : :
76~
` -Z2-
c. Definition of Certain Terms
dq Multi~Program Operation
e. Multi~anguage Operation
f. Addressing Structure
g~ Protestion Mechanism
B. Computer System 10110 Information Structure and
Mech~nisms ~Figs. 102, 103, 104~ 105)
a. Introduction (Fig. 10~)
b. Process Structures 10210 (Figs. 103, 104,
`, 10 10~) `
1. Procedure Objects (Fig. 103)
: 2~ Stack Mechanisms (~ig~. 104, 105)
`. 3. FURS~ 10214 (Fig. 103) ; .
CO Virtual Processor State Blocks and ~irtual
: 15 Process Creation (Fig. 102)
D. Addressing Structures 10220 (Fig~. 103t 106,
107, 108)
1. . Objects, UID's, .AON's, Names, and Physical
Addresses (Fig. 106)
2. Addressins Mechanisms 10220 (Fig. 107)
3. Name Resolution (Figs. 103, 108)
: 4~ Evaluatlon o~ AO~ Addresses to Physical
Addresses (Fig~ 107)
;~ E. CS 10110 Protection Mechanisms (Fig. 109)
Z5 F. CS 10110 Micro-Instruction Mechanisms (Fig. 110)
.. G. Summary of Certain CS 10110 Features and
Alternate Embodiments.
.~.'.,
:','
':"
.
~' , .,.''
: :
, . .. ~ .
'.
.
7 ~ 7
-23-
2.
A, MEM 10110 (~ig ~ 201, Z06, 207-237)
a. Terminology
b. ~M 101.12 Physical Structure (Fig. 201)
c. ~EM 10112 General ~peratiQn
d. MEM 10112 ~ort Structure
1. IO Port Characteristic~
2. JO Port Characteristics
3. JI Port Characteristics
e. ME~ 10112 Control Structure and Operation
(Fig~ 207)
' ~ 1D MEM 10112 Control Struc~ure
2. MEM 10112 Contr~l Operation
lS f. MEM 10112 Operations
. g. MBM 10112 Interfaces to JP 10114 and IOS
10116 (Figs~ 209, 210, 211, 204)
; 1. IO Port 20gl0 Operating
Characteristics ~Figs 209, 204)
2. JO Port 21010 Operating
- Characteristics (Fig. 210) : .
3. JI Port 21110 Operating
: Charactertis~is (Fig. 211)
h. FI~ 20120 (Figs. 201, 230, 231)
B~ Fetch Unit 10120 ~Fiss. 202, 206, 101, 103, 104,
2383
~ 1. Descriptor Processor 20210 (Figs. 202,
':~ 101, 103, 104, ~38, ~39)
:
, ~.
.'.:,:, ,
, ' '
.. . . . .. . . . . . . . . . . ....
.:,: : : ,
. .-i . . .
.. , ~ . . ~ ;
" ,., ... . . ~ . ..
''': ' ., :, ' ,: ' . ', ,~, ' ~ ;,
.; . ; . ..
,, , ~
.
-24
a. Off~et Processor 20218 Structure
b. ~ON Proces~or 20216 Structur~
c. Length Processor ~0220 S~ructure
. ~ do De~criptor Proctssor 20218 Operation
a.a. Off~et Selector 20238
b.b. O~fset ~ultiplexer 20240 Det~iled
Structure (Fig. 238)
:~ c.c. Offset Multiplexer 20240 Detailed
; Operation
~aa. Internal Operation
bbb. Operation Relative to DESP
20~10
e. Lensth Processor 20220 (FigO 239) :`
a.a. Length ALU 20252
. 15 b.b. BIAS 20246 (Fig~ 239)
f. AON Processor 202~6
. -i
a.a. AONGRF 20232
.~ b.b. ~ON Selector 20248
- 2. ~emory Interface! 20212 (FigsO 106, 240)
~-~ 20 a.a. Descriptor Trap 202S6 and Data Trap
~ 2025
:: b.b. Name Cache 10226, Add~ess Translation
.~ Unit 10228, and Protection Cache 10234
. (Fig. 106~
c.c. Structur~ and Operation of Generalized
Cache and NC 10226 (FigO 240)
d.d. AT~ 10228 and PC 10234
, 3. Fetch Unit Control Logic 20214 ~Fig. 202)
a.a. Fetch ~nit Control Logic 20214 Overall
: 30 Structure
.
' ' '
. .
''' ,
, : . , . ~. - . ::,: . ,
.: . . . ~ . . .: ,
, ~ , , ,
,~`~b~ ~
._.
7f~76
~25-
b.b. Fetch Unit Control Logic 20214
Operation
a~a,a~ PrefPtcher 20264,
Instruction Bu~fer 20262,
Parser 20264 r Operation Code
.~ Register 20268, CPC 20270,
;~; IPC 20272, and EPC 20274
(Fig~ 241~
~ b.b.b. Fetch Unit Dispatch Table
: l0 11010, Execute Unit Dispatch
~ Table 20266, and Operation
:~ Code Register 20268 (Fig.
24~)
` c~c.c. Next Address Generator 24310
;; 15 ~Fig. 243)
:~ cc. ~UCTL 20214 Circuitry for CS 10110
Internal Mechanisms (Figs. 244-250)
.. a.a.a. State Logic 20294 tFigs.
244~-2442)
bob~b~ E'vent Logic 20284 (~igs.
245~ 246~ 247r 248)
~; c.c~c. Fetch Unit S-Interpreter
: Table 11012 ~Fig. 24g)
~ d.d. C8 10110 Internal Mechanism Control
.. 25 a.a.a. Return Control Word Stack
. 10358 (Fig. 251)
b~b~bo Machine Control Block (Pig.
25~)
. -
,, ~ ...
,
, .
. . .
. . . . . . ..... .
. , ~ , ., ; . - : ~ , . . . . .
.
, l, . -
, . . ~ ,, .
,. . .
!, .
'176
~26-
c.c.c, Register Address Generator
20288 (Fig. 2S3)
~ d.d~d~ Timers 20296 (Fig. 254)
: e~e~e. Fetch Unit 10120 Interface
to Execute Unit 10122
C. Execute ~nit 10122 (Fig~. 203, 25$-268)
a. General structure o~ Execute Unit 10122
1. Execute Unit I/O 20312
:: 2. Execute Unit Control Logic 20310
-:~ 10 3. Multiplier Logic 20314
4. Exponent Logic 20316
. 5. ~ultiplier Control 20318
6. Test and Inter~ace Logic 20320
b. Execute Unit 10122 Operation (Fig. 255)
1. Execute Unit Control Logic 20310 ~Fig.
255)
~`. aOa. Command Queue 20342
~` b.b. Command Queue Event Control Store
:
-~` 25514 and Command Queue Event
Address Con~rol Store 25516
cOc. Exec~te Unit S-Interpreter Table
;.- 20344
d~d. ~icrocode Control Decode Register
2034~
e.e~ ~ext Address Generator 20340
2~ Operand Buffer 20322 (Fig. 256
3O Multiplier 20314 (Figs. 257, 258)
aOa. Multiplier 20314 I/O Data Paths
and Memory (Fig 257)
! .,
.'~ ' ` ;
''- ~ , :
'''''
:. . ' ' : . : . ', '
.', ' ', ,' ' , , . ' ' ' ~ ~ ' ' ' , ' ' . ' ' ` ' '
'`` ~ ' : :` : : . ,
. .
-27-
a.a.a. Container Sixe Check
b.b.b. Final ~eqult Output
Multiplexer 20324
4. T~st and Inter~ace Logic ~0320 (Figs.
260-268)
a.a. PU 10120/EU 10122 Inter~ace
a.a.aO ~oadlng of Command
Queue 20342 (Fig. 260)
:~ b~b~b, Loading of Operand
Buffer 20320 (Fig. 261)
c.c.c. Storeback ~Fig. 262)
d~d.d. Test Conditions (Fig.
263)
. e.e.e. Exception Checking
(Fig. 264)
f.f.f. Idle Routine
g.g.g. EU 10122 Stack
.. Mechanisms (Figs. 265,
:~ 266, 267)
; ~ 20 h~h~ho Loading of Execute Unit
S-Interpreter Table
. 2~344 ~ig. ~68)
D. I/O System 1~116 (Fiy~ 2049 206, 269)
a~ I/O Sy~tem 10116 Structure ~Fig. 204)
bo I/O System 10116 Operation (Pig. 269)
1~ Data Channel Devices
,
2. I/O Control Proce sor 20412
3. Data Mover 20410 (Fig. 269)
a.a. Input Data Buffer 20440 and
~ 30 Output Data Bu~fer 20442
.. . .
:- .,
'~
. ' .
' .
, ~ . . .
. ~ . .
. . . . . .
, . . .. ' ' . ' ' ~
- . , : ~ . ..
,
,
,,, ~ , . . . . . .
.7''~7
--2~
b.b7 Priority Resolution and Control
20444 (Fig. 269)
~ ~ Diagnostic Proces~or 10118 ~Fig. 101, 205)
; F. CS 10110 Micromachine Structure and Operation
:. 5 (Figs~ 270 274)
a. Introduction
:~ b. Overview of Devices Comprising FU
Micromachine (Fig. 270)
lo Devices ~sed By Most Microcode
- 10 a~a. ~OD Bus 10144, JPD Bus 10142, and
: DB Bus 27021
b~b. Microcode Addressing
c.c. Descriptor ~rocessor 20218 ~Fig~
271)
.. - 15 d.d. ~U 10122 Interface
' 2. Speciali2ed Micromachine Devices
~ .;;
a.a~ Instruction Stream Reader 27001
.: b~b. SOP Decoder 27003
c.c. ~ame Translation Unit 27015
~: 20 drd~ ~emory Reference Unit 27017
.~ e.eD Protection Unit 27019
.: ~.f. XOS ~icromachine Devices
c. Micromachine Stacks and Microroutine Calls
- and ~eturns ~Figs. 272, 273)
1. Micromachine Stacks (Fig. 272)
:~ 2. ~icromac~ine Invocations and Returns
3. ~eans of Invoking ~icroroutines
, ,
. .
'~' . .~
:,
.....
F ,':
" "
t ~'
', ' ' . ~ ', ' " . . ', , '
,' , , ' . ' ' ' . . . : ,
i"''''" ,. ' ' ' ' , ', ' ' ''~''; ~' ' . '
', ' , ' ': ' ' . ' ' , ' ~ ' : .
': " "", " " ' " ' " ' ' , ' ' ' , , . :
~7'~
..~9_
4. Occurrence of Event Invocations (~ig~
~73~
d. Vir~ual Micromachines and Monitor
Micromachine
1. Virtual Mode
2. Monitor ~icromachine
e. Interrupt and ~ault ~andling
1. General Principles
2. ~ardware Interrupt and Fault Handling
in CS 10110
~:: 3. Monitor Mode: Differential Ma~king
and ~ardware Int~rrupt Handling
g. FU Micromachlne and CS 10110 Subsystem~
~`..'
3~ Y ~U~ 'a_t~e~9~ C ~ t~2=~ri~b
3ge~L ~b~l
. Pointers and Pointer Resolution (Figs. 301, 302)
a. Pointer Format~ (Fig. 301
b~ Psinters in F~ 10120 (Fig. 302~
~: c. Descriptor to Pointer Conversion
; 20 B. Namespace and the S-Interpreters (Fig~. 303-307)
.~ a. Procedure Object 606 Overview ~Fig. 303)
b. Namespace
1. Name Resolution and Evaluation
2. The Name ~able (Fig. 304)
3. Architectural Base Poin~ers (Figs.
r 305, 306)
. , ~
, ~"
1,
''
,. . .
~',, ~ ' ~ . ., . . ' ' :
S~ ' , .' ~
~' ' ' .
~' "' ' ~' ' ' ~' ' '
~, :~ , . . ~ :
!, .
~7'~7~6
-30-
'
a.a~ Resolvin~ and Evaluating Names
(Fig. 3053
b.b. ~mplemen~ation of Name Evaluatlon
and Name Resolve in CS 10110
c.c. Name Cache 10226 Entries (Fig.
306)
~; d.d. Name Cache 10226 Hits
e.eD. Name Cache 10226 Misses
: f,~. Flushing Name Cache 10226
.'' gAg~ Fetching the Instruction Stream
`. 10 h.h. Parsing the Instruction Stream
c. The S-Interpreters ~Fig. 307)
1. Translating SIP into a Dialect Number
ig. 307)
2. Dispatching
:: :
'` 15 4. ~ 2~ -t -=~l 3
A. Introduction
a. Operating Systems (Fig. 401)
l~ Resource~ Controlled by Operating
Systems (FigO 4d2)
b. The Operating S~stem in CS 10110 ~`
; ~. Extended Operating System and the Rernel
Operating System (Fig~ 403)
B. Objects and Object Management (Fig. 40~
a. Objects and User Programs (Fig. 405)
:. 25 b~ UID~ 40401 (Fig. 406)
c, Object Attribu~es
~ ~''.'
~ ,.
.:,
i':' .
, ~. . . . . .
~, , : ' , ' ~ .' '` '
... , . ~
. .
~: :, , . . : ,. . . ' , . .::
'~
~ 7
-31~
d. Attributes and Access Control
2. Implementation of Objects
1. Introduction ~Figs 407, 408)
2. Ob~ectc in Secondary Storage 10124
(Figs 409, 410)
aOa. Representation of an Object'~
Contents on Secondary Storage
10124
t b.b. LAUD 40g03 (Figs. 411, 412)
3. Active Objects (Fig. 413)
a.a. UID 40401 to AON 41304
Translation
CO The Access Control Sy~tem
. a, Subjects
.. ~ 15 b~ Domains
;....
~ c. Access Control Lists
.
: 1. Subject Templates (Fig~ 416)
2. Primitive Access Cont~ol Lists (PACLs)
3. APAM lQ918 and Protection Cache 10234
(Fiy. 421) .
4~ Protection Cache 10234 and Protection
Checking (Fig. 422)
~:~ D. Processes
9 Synch~anization of Pro~esses 610 and
. Virtual Processors 612
a~ Even~ Counters 44801, Await Entries 44804,
.~ and Await Tables (Fig. 448, 44g)
:
,.
, .
' `' ;` :
,; .:
,; ' .
.~, . .
~ , . . .
: .. . . .
~ : ~ . , , . ,.,, .;
7~ ~ 6
-32~
' .
bo Synchronization with Event Counter~ 44801
: and A~ait Ent~ies 448a4
Eo Virtual Proce~sors 612 ~Fig. 453)
~ a. Virtual Processor Management (Fig. 453)
;~ 5 b~ Virtual Processor~ 612 and 5ynchronization
: (Fig. 454~
F. Process 610 S~ack Manipulation
1. Introduction to Call and Return
2. ~acrostacks ~MAS) 502 (Fig. 467)
a.a. MAS Base 10410 (Fig. 468)
b~b. Per-domain Data Area 46853 (FigO
468)
cOc. MAS Frame 46709 Detail ~Fig. 469)
:~ 3O SS 504 (Fig~ 470~
a.a. SS Baq,e 47001 (Fig. 471)
b.b~ SS Fra~es 47003 (Fig 471)
a.a.a. Ordinary SS Frame :
~eaders 1051~ t~ig.
. ~71)
b~b.b. Detailed Structure o~ :
Macrostate 1051~ (Fig.
. 471)
c.c.c~ Cross-dom?in SS Frames : .
47039 ~Fig. 471)
4. Portions of Procedure Object 608
Relevant to Call and Return (Fig~ 472)
,~ 5. Execution of ~ediated Calls
a.a~ Mediated Call SINs
.', :
.,. :
: .
. ~ .,
,, ~,
.''~
' , '.
:: ' ,, ., .' , , ~ : '
;, . .
-: . , ~ , :
, , ,
~ - ~
~74 7
~33~
b .b . Simple ~ediated Calls (Figs ~, 270,
: 468, 46g, 470, 471, 472~
C,,C5, Invocations of Procedures 602
. Requiring SERs 46864 (Fig~. 270,
~' 5 468, 469, ~70, ~71, ~72~
d.d. Cross-Procedure O}:~ject Calls
(Figs. 270, 468, 469, 470, 471,
~: 472)
e.e. Cross-Domain Calls (Figs. 270,
.. ; 10 408, 418~ 468, ~69, 470, 471,
472)
.fO Failed Cross-Domain Calls (FigsO
270, ~6~ ~ 469, 470, 471, 472)
6., Meighborhood Calls (Figs. 468, d~69,
: 15 472)
,,~,: '
i: The ~ollowing overview will first brie~ly describe
the overall physical structure and operation of a
presently pre~erred embodime~t o~ a digital computer
system in~.orp~rating the present invention. Then certain
~ operati~g ~e~tures o~ thAt co~nputer system will be
!~ individually describedO Ne~t~ overall operation of the
computer sys em ~ill be described in terms of those
individual features.
,;~, ''
~, ;. ,
~ : .
,
: . " .
',
::, , ,
, . ... .. . . . . .
,. . . . . ..
.
~,
~: . : '. - ', '
ij~: : , , ~ :
,, ' : '
~34
,~
A. ~Ld~:~_2~_r~ S~
Ree~ring to ~ig. 1, a block diagram of Computer
System ~CS) 101 incorporating the present invention ls
~hown. Major elements o~ CS 101 are I/O System (IOS)
116, Memory (~EM) 112, and Job Processor ~JP~ 114. JP
114 i~ comprised of a Fetch Unit (F~) 120 and an Execute
Unit (EU) 122~ CS 101 may also include a Diagnostic
~rocessor (DP), not shown or described in the instant
description.
R ferring first to IOS 116, a p~imary fu~ction of IOS
116 is control of transfer of information between ~EM 112
and the outside world. Information is transferred from
MEM 112 to IOS 116 through IOM Bus 13Q, and from IOS 116
-; to ~EM 112 through MIO Bus 129~ IOMC Bus 131 is
.' 15 comprised of bi-direc~îonal control signals coordinating
.. ; operation of ~EM 112 and IOS 116. IOS 116 also has an
: inter~ace to FU 120 through IOJP ~us 132. IOJP Bus 132 .
is a bi-directional control bus comprised essentially of
two interrupt lines. These interrupt lines allow FU 120
20 to indicate ~o IOS 116 that a request for information by
; FU 120 has been placed in MEM 112, and allows IOS 11~ to
inform FU 120 that information requested by ~U 120 has
been transfer~ed into a location in ~EM 112. MEM 112 is
-~ ~ CS l Ol ' s main memory and serves as the path for
25 information trans~er between the outside world and JP
; 114. ~E~ 112 provides instructions and data to FU 120
and EU 122 through Memory Output Da~a (MOD) Bus 140 and
receives information from FU 120 and EU 122 through Job
j . .
s. :.
' :'
"''
. ~: , ~ . ,, , ~ .
. . .
~ ,
. . .
.
, .. . . . .
- ;
7 6
~: -35-
Processor Data (JP~) 3us 1~2~ FU 120 submits read and
write requests to MEM 112 through Physical Descriptor
:- (PD) Bus 146~
; J~ 114 is C5 101'~ CPU and, as described above, i5
::~ 5 comprised of F~ 120 ~nd E~ 122. A primary functlon of F~
120 is executing operations of user's programs. As part
of this function, FU 120 controls transfer o~
instructions and data from ME~ 112 and transEer of
results of JP 114 operations back to MEM 112. FU 120
~ 10 also performs operating system type functions, and is
capable of operating as a complete, general purpose C~U.
EU 122 is primarily an arithmetic and lo~ic unit provided
: to relieve FU 120 of certain arithmetic operations. PU
120, however, i5 capable of performing EU 122
~ 15 operations. In alterna~e embodiments of CS 101, E~ 122
: may be provided only as an option for users having
particular arithmetic requirementsO Coordination of F~
` 1~0 and EU 122 operations is a.ccomplished through FU~EU
.; (FUEU) Bus 148, which includes bi-directional control
; : 20 signals and mutual interrupt lines. As described further
.`.~ below, both FU 120 and EU 122 contain register file
arrays reerred to respectively as C~ and ERF, in
addition to registers associated with, for example, ALUs.
A primary feature of CS 101 is that IOS 116, MEM 112, -
FU 120 and EU 122 each contain separate and independent
microinstruction control, so that IOS 116, MEM 112, and
. E~ 122 operate asynchronously under the general control
.~ o~ FU 120. EU 122, ~or @xample, may execute a complex
,; .
~ - ,
, ~
. .
~'';
,~ ,........ ... .
,: , .' -.. ",. . ~. .. ,: ,
,, " , ,.~. , .
. . : : .
i., ,,,: : , :, ,.,~ - ,... ..
,. .. . . . .
~ ~ 7 ~7
-36-
arithmetic operation upon receipt of data and a single,
initial command rom FU 120.
~ aving briefly described the overall structure and
operation of CS 101, certain features of CS lOl will be
lndividually further described next below~
, B.
. 1~ ~
Referring to Fig. 2, a diagramic representation of
. portions of CS lOl's addressing structure is shown. CS
lO lOlls addressing struc~ure is based upon the concept sf
Objects~ An Object may be regarded as a container for
holding a particular type of information. For example,
: one type of Object may contain data while another type of
Object may contain instruction~ or procedures~ such as a
15 user program~ Still another type o~ Object may contain
microcode. In general, a particular Object may contain
only one type or class of informtion. An Object may~ for
example, contain up to 2 bits of information, but the
actual size of a particular Object is flexible. That is,
: 20 the actual size of a particular Object will increa~e as
-. information is written into that Object and w~ll decrease
.
as information is taken from that Object. In general,
: information in Objects i5 stored sequentially, that is
without gapsO
Each Ob;ect which c n ever exist in any C5 101 system
. ~ is uniquely identified by a serial number referred to as
,~ a Unique Identifier (UID)o A UID is a 128 bit value
.' comprised of a serial number dependent upon, for example,
,~:
. . .
:i,
~ ':
. . .
. .
. .
.,,, ~ . .
:
,:
.. . . .. -
. . - : . . ,
- . . . , .. . ., . ~ ..... . .
~ . ; , ~ ~ , , -
. .
., .
, . . .
,~, . .
-
~17~7
~37--
the particular CS 101 system and user, and a time code
indicating time of creatlon of that Object. UIDs are
permanently assigned to Objects, no two Objects may have
the same UI~, and UIDs may not be reused. UIDs provide
S an addressing base common to all CS 101 systems ~hich may
ever exist, through which any Object ever creat~d may be
permanently and uniquely identified.
As described above, UIDs are 128 bit values and are
thu~ larger than may be conveniently handled in present
embodiments of CS 101. In each CS 101, therefore, those
Objects which are activ~ (currently being used) in that
system are assigned 14 bit Active Object Numbers (AONs).
Each Object active in that system will have a unique
. AO~o Unlike UIDs, AONs are only temporarily assigned to
. 15 particular Objects~ AONs are valid only within a
; particular CS 101 and are not unique between systems. An
Object need not physically reside in a system to be
assigne~ an AON, but can be active in that system only if
it has been assigned an AOM.
A particular bit within a particular Object may ~e
identified by means o~ a UID address or an AON address.
In CS 101, AONs and AON addres~es are valid only within
JP 114 while UIDs and UID addresses are used in MEM 112
and elsewhere~ UID and AO~ addrasses are ormed by
appending a 32 bit Offset ~0) field to that Object's UID
or AONo O fields indicate offset, or location, of a
particular bit relative to the start of a particular
Object~
'
..
,' '
:: ' . ' . '
' !
" , I
. ' , ` ' .
3~-
Segments of information (sequences of informationbi s) within partioular Objects may be identified by
means of descriptors. A UID descriptor is formed by
appending a 3~ bit Length (L) field o 2 UID address. An
5 AON, or logical descriptor is formed by appending ~ 32
bit L field ~o an AON address. ~ fields identify length
of a segment of information bits ~ithin an Object,
starting from the information bit identified by the U D
or ~ON address. In addition to length information, UID
;~ l0 and logical descriptors also contain Type fields
containing information regarding certain characteri~tics
of the information in the inormation segment~ Again,
AO~ based descriptors are used within JP 114, while UID
~' based descriptors are used in MEM 112.
:; 15 Referring to Figs. 1 and 2 together, translation
!~ between UID addresses and descriptors and AON addresses
: and descriptors i5 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
. 20 dP~criptors in M~M 112, IOS 116t and the external world
; are in UID form. In ot~er embodiments Qf CS 101 using
AO~s, transformation from UID to AO~ addressing may occur
at other interfaces, for example at the IOS 116 to MEM
112 interface, or at the IOS 116 to external world
interface. Other embodiments of CS 101 may use UIDs
throughout, that is not use AONs even in JP 114.
.
~; '.
,''''''', ................................................................ .
' '
,' . ' - : ':: .
, ~ ~ . - . ,
~ . ' . ~'', . ' ' ,
~ , . . .
~39-
Finally, in~ormation withln ME~ 112 is located
through MEM 112 Physical Addresses iden~iyln~ particular
physical locations within MEM 112's memory 4pace . Both
IOS 116 and JP 114 addrPss information within MEM 112 by
providing physical addresses to ME~ 112~ In the case of
physical addresses provided by JP 114, these addresses
are refexred to as Physical Descriptors (P~s). As
described below, JP 114 contains circuitry to transla~e
logical descrlptors into physical descriptors.
,' 10
., U~
CS 101 is both an S-Language machine and a Namespace
` machine. That ist. 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 FORTRAN and COBOL, but of a higher level than
. conventional machine language .instructions. SOPs are
:. specific to partic~lar user languages rather than a
. 20 par~icular embodiment of CS 101, while conventionai
machine language instructions are specific to particular
machine~. SOPs are in turn in~erpreted and executed ~y
microcode. There wilI be an 5-Language Dialect, a set of
SOPs, for each user languagesO CS 101, for example, may
25 have SOP Dialects for COBOL, FO~I`RAN, and SPL. A
particular di~tinction 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
: :,
. ~ .
,, :
. .
~, , .: , - , ~
,, ' ' :, ' ''' ,.
. , ~
.
7~7~j~
~_
5-Language Dialec~. These microcode Dialect 5ets may be
completely dis~inct, or may overlap wher~ more than one
SOP utilizes the same microcode.
As st~ted above, in CS 101 all operands are
;~ S identi~ied by Names, which are 8, 12, or 16 bit numbers.
- CS 101 includes one or more "Name Tables" containing an
Entry for each operand ~ame appearin~ in programs
: curren~ly be~ng executed. ~ach Name Table Entry contains
information describing the operand referred to by a
particular Name, and the directions necessary for CS 101
~o translate that.information into a corresponding
: logical descriptor. As previously described, logical
d~scriptors may then be transformed into physical
descriptors to read and write operand~ from or to MEM
` 15 112. As described above, UIDs are unique for all CS 101
systems and AONs are unique within individual CS 101
: systems. Names, however, are unique only within ~he
?," context of a user's program. That is, a particular N~me
may appear i~ two different u~er's programs and, within
:; 20 each program, will have differen~ ~ame Table Entries and
; will re~er to different operand-~.
: CS 101 may thereby be con~idered as utilizing two
:~ sets of instructions. A first set is comprised of SOPs,
- that is instructions selecting algorithms to be
:: 25 executed. The second set of instru tions are comprised
of ~ames, which may be regarded as entry points into -
: tables of instructions for making references regardin~
. operands.
: .
.. ~.
..
., .; ' .' , ' ' ` ' ' ' .. ' ' '
76~;
-41-
: Referring to Fig.3, a diagramlc representation of CS
101 instruction stream is shown. A typical SIN i~
comprised of an SOP and may include one or more Names
referring to operands. SOPs and ~ames allow u r's
5 programs to be expressed in very compact code. Fewer
SOPs than machine language instructions are required to
~: exp~ess a u~er's program. Also, use of SOPs allows
easier and simpler construction of compilers, and
facilitates adaption of CS 101 systems to new user
~ 10 languages. In addition, use of Names to refer to operands
;.: means that SOPs are independen of the form of the
; operands upon which they operate. This in turn allows ~ :
for more compact code in expressing user programs in that
~: SOPs specifying operations depe~dent upon operand form
.. 15 are not required.
. ~
As will be described further below, a user' program
residing in CS 101 will inclucle one or more Objects.
~: First, a Procedure Object cont:ains at least the SINs of
.~ 20 the user's programs and a Name Table containing entries
~ o~ operand ~ames o~ the program. The SINs may include
~eferences, or calls, to other Procedure Objects
: containing, for example, procedures available in common
.. ~ to many users. Second, a Static Data Area may contain
i 2S static data, that is data havin~ an exi~tence for at
: least a single execution of the program. And third, a
acro-stack, descxibed below, may contain local data,
that is data generated during execution of a program~
.~ Each Procedure Object, the Static Data Area and the
~ 30 Macro-stack are individual Objects identified by UIDs and
,. ' '
.
~''~ " `
. . .
', ~ . ' :: ' '' '' '
766
-42-
AO~s and addressable through UID and AON addresses anddescriptors.
Locations o information within a user's Procedure
Objec s, Static Data Area, and ~acro st~ck are expres~ed
5 as offsets from one of three values, or base addresses,
referred to as Architectural Base Pointers (ABPs). For
example, locatlon information in ~ame ~ables is expressed
as of~sets from one o$ the ABPs. ABPs may be expressed
as previously described.
10The three ABPs are the Frame Pointer ~FP), the
Procedure Base Poin~er (PBP), and the Static Data Pointer
(SDP~. hocations o~ data local to a procedure, for
example in the procedurels ~acro~tack, are described as
::~ offsets from FP. Locations of non-local data, that is
15 Static Data, are described as offsets ~rom SDP~
; Locations o~ SINs in Procedure Objects are expressed as
offsets ~rom PBP; these offsets are determined as a
Program Counter (PC) value. Values of the ABPs vary
during program execution and are therefore not provided
: 20 by th~ compiler converting ~ u~ier's high level language
` program into a program to be executed in a CS 101
: system. When the program i5 exacuted, CS 101 provides
the proper values for the ~BPs. When a program is
actually being executed, the ABpl5 values are stored in
25 F~ 120's GR~.
' , .
.
-. .
~ . . .
, . . . . . .
,,, ' ' ~ ' '' :'" . ' . ':
, .
.
.
~ ~,, 7L.~ 766
~43~
O~her pointers are used, for example, to identify the
top frame of CS 101'5 Secure Stack (a microcode level
stack described below~ or to identify the microcode
Dialect currently being used in execute ~he 5INs of a
`
procedure~ These pointers are similar to FP, SDP, and
, p~p
4. ~
Referring to Fig. 4 and 4A, diagramic representations
of various control levels and stack mechanisms of,
respectively, conventional machines and CS 101, are
:: shown. Referring first to Fig. 4, top level of control
; is provide~ by User Language Instructions 402, for
example in FORTRAN or COBOL. User Language ~ns~ructions
.. 402 are converted into a greater number of more detailed
:~ 15 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 Machine
20 Ha~dware 408. Some conventional machines may include a
Stack Mechanism 410 used to save current machine state,
that is current microinstructlon and contents of varlous
; machine registers, if a current Machine Language
.; Instruction 404 cannot be executed or is interrupted. In
: 25 general, machine state on the microcode and hardware
level is not saved~ Execution of a current Machine
: Language Instruction 404 is later resumed at start of the
;.
5,'" microinstruction sequence for executing that Machine
: Language Instruction 404.
:
,.
': '
, -
,
,. ~ . . :
r
t , :~,
"
,, . . ?
~7~7 ~ 6
-44-
-. Referring to Fig. 4~, top level control in CS 101 is
: by ~ser Language Instructions 412 as in a conventisnal
machine. In CS 101, hbwever, User Language Instructions
412 are translated into SOPs 414 which are of a hlgher
level than conventional machine language instructionsO
In general, a single U~er Language Instruction 412 is
transformed into at most two or three SOPs 414, as
opposed to an entire sequence of conventional Machine
hanguage Instructions 404. SOPs 414 are interpreted and
.: 10 executed by Microcode Instruc~ions 416 (sequences of
microinstructions) which directly control CS 101 ~ardware
41B. CS 101 includes a Macro-stac~ Mechanism (MAS) 420,
, .
at SOPs 414 level~ which is comparable to but different
. in construction and operation from a conventional ~achine
: 15 Language Stack Mechanism 410~ CS 101 also includes
' ~ ~icro-code Stack Mechanisms 422 operating at Microcode
416 levelr so that execution of an interrupted
:: microinstruc~ion of a microin~;~ruction sequence may be
later resumed with the particular microinstruction which
20 was active at the time o the in~erruptO CS 101 is
~: therefore more efficient in handling interrupts in that
: execu ion of microinstruction sequences is resumed from
the particular point that a microinstruction sequence was
interruptedr rather from the beginning of that se~uence.
~ 25 A5 will be described further below, CS lOl's Micro-code
'- Stack Mechanisms 422 on microcode level is effectively
compris~d of two stack mechanisms. The firs~ stack is
. ~icro instruction Stack ~MIS) 424 while the second stack
;. is referred to as Monitor Stack (MO5) 426. CS 101 SIN
30 Microcode 428 and MIS 424 are primarily concerned with
,
;, ~
,"~
i,,, , , ~
.
.
~ ' ,
~t~47g~6
--~. s-- ,
.
execution of SoP~ of user's programs. Monitor Microcode
430 and MOS 426 are concerned with operation of certain
CS 101 internal functions.
Divlsion of CS 101's microcode stacks into an MIS 424
and a MOS 426 illustrates a further feature of CS 101.
In conventional machines, monitor f unctions 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 to perform both func~ions with ac~ual
10 execution of both functions performed by separate groups
of microcode. Monitor microcode operations may be
initiated either by certain SINs 414 F by control
signals generated directly by CS 101'g ~ardware 418.
: Invocation of Monitor Microcode 430 by ~ardware 418
15 ~enerated signals insures that CS 101's monitor functions
may always be invokedO
: Referring to Fig. 5, a diagramic representation of CS
lOl's stack mechanisms for a ~i$~ ~a~ pro~iam, Qr
. ~l5~ Q~ is shown. Basically, and with excep~io~ of
: 20 MOS 426, CS 101lS stacks reside in MEM 112 with certain
portions of tho e stacks accelerated into FU 120 and EU
122 to enhance speed of operation~ ;
Certain areas of ME~ 112 storage space are set aside
to contain Macro-Stacks (MASs) 502, stack mechanisms
. 25 operating on the SI~s level, as described above. Other
areas of MEM 112 are set aside to contain Secure Stack
~: ~SS) 504, operating on the microcode level, as described
above and of which ~IS 424 is a part.
, ~
,
, . :
.
, . . . . ..
.
~ . l . . . .
.
: . . . . . .
; . . . :
. ..
.
:
.
-4~-
As described ~urther 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
: 5 FU 120's GR~ S06. G~ 506 is horizontally divided into
three areas. A first area, referred to as Gener~l
Registers (GRs~ 508 may in genéral be used in the same
manner as registers in a conventional machine. A second
: area of GRF 506 is ~icro-Stack (MIS) 424, and is set
- 10 aside to contain a portion of a Process's SS 504. A
:third portion of GR~ 506 is set aside to contain MOS
426. Also indicated in FU 120 is a block referred to as
Microcode Control 5tate (mC5) 510. mCS 510 represents
registers and other F~ 120 hardware containi~g current
operating state of FU 120 on the microinstruction and
hardware level. mCS 510 may i.nclude, for example, the
.~ current microinstruction controlling operation of FU 120.
,~ Referring to EU 122, indicated therein is a
firs~ block referred to as Execute Unit State (EUS) 512
20 and a second block referretd to as SOP Stac~ 514. EUS 512
s similar to mCS ~10 in FU 12'J and includes all
. ~
':: registers and other ~U 122 hardware containing
information re~lecting EU 122's~current operating state.
SOP Stack 518 i~ a portion of EU 122's ERF 516 which has
-~25 been set aside as a stack mechanism to contain a portion
of a process' 5 SS 504 pertaining to EU 122 operations.
.Considering first MASs 502, as stated above MASs 502
operate generally upon the SINs level. MASs 502 are used
~-in general to store current state of a process's (defined
'~30 below~ execution of a user'~ program.
`::
, . .
J
, ~,
' . '
,..
'
J, ~ :
-~7
Referring next to ~IS 424, in a present embodiment of
C5 101 that portion of GRF 506 set asld~ to con~ain M~S
424 may have a capacity of eight ~tack framPs. That is,
up to 8 microinstruction level interrupts or calls
~` 5 pertaining to execu~lon of a u~er's program may be
stacked within ~IS 424. Information stored in MIS 424
stack frame~ is generally informakion from GR 508 and MCS
510. MIS 424 stack frames are transferred between MIS
~24 and SS 504 such that at leas~ one frame, and no more
10 than 8 frames, of SS 504 reside in GRF 506. This insures
that at l.east the top-mo~t frames of a proeess's SS 504
are present in F~ 120, thereby enhancing speed of
: operatio~ o~ FU 120 by providing rapid access to those
: top rames~ SS 504, residing :in ME~ 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
effectively an infinitely deep stack.
MOS 426 resides entirely ill FU 120 and, in a present
embodiment of CS 101, may have a capacity of 8 stack ::
~ 20 framesD A feature of C~ 101 op~ration 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
in'cerrupts. Among events handled by CS 101 monitor
25 microcode, for example, are M~ 112 page faults. An MEM
112 page fault occurs whenever FU 120 makes a reference
to data in ME~ 112 and that data is not in ~EM 112. Due
. , .
: , . . . . . .
, -,
- . . . .
.. .. .
~74~76
--4 8--
to this and similar operations, MOS 426 resides entirely
in ~U 120 and ~hus does not rely upon informa~ion in MEM
112.
As described above, GRs 508, MIS 4~4, and MOS 426
5 each reside in certain assigned portions of G~F 506.
This allow~ flexibility in modifying the capacity o GRs
508, MIS 424~ and MOS 426 as indicated by exp~rience, or
~o modify an individual CS 101 for particular purposes.
~eferring finally to EU 122, EUS 51~ is functionally
10 a part of a process's SS 504. Also as previously
described, EU 12~ performs arithmetic operations in
response to SINs and may be interrupted by FU 120 to aid
certain F~ 120 operations. E~S 512 allows stacking of
~interrupts. For example, FU 120 may first interrup~ an
: 15 arithmetic SOP to request E~ 122 to aid in evaluation of
a Name Table Entry~ Before that first in~errupt is
~completed, FU 120 may interrupt again, and so on.
:~ SOP Stack 514~ is a single rame stack for storing
current state of EU 122 when an interrup~ interrupts
:20 execution of an arithmetic SOP. An intarrupted SOP's
:state is ~ransfexred into SOP Stack 514 and the in~errupt
:~`begins execution in EUS 512. Upon occurrence of a second
interrup~ ~before the first in~errupt is completed) EU's
first i~terrupt state is transerred 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 interrupt, E~'s second
interrupt state is transferred from EUS 512 to another
;stack frame in SS 504 and execution of the third
30 interrupt is begun in E~S 512; and so on~ EUS 512 and SS
504 thus provide an apparently inf initely deep microstack
, ,: ,
~ ',. . , , , ~ ~
, ,
~, ' , ~ . ,
,
.
~L~ '7~7~
-49-
for EU 122. Assuming that the third interrupt is
completed t state of second interrupt is transferred from
SS 504 to EUS 512 and execution of second interrupt
reSume~ Upon completion of second interrupt, state of
first interrupt is transferred from SS 594 to EUS 512 and
completed. ~fter completion of first interrup~, state of
the original SOP is transferred from SOP Stack 514 to E~S
: 512 and execution of that SOP resumed. ::
C. C_ e~
:; Re~errinq to Fig. 6, a diagramic representation of
procedures, processes, and virtual processes is shown.
As described above~ a user's program to be executed 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 Name Table containing
Entries for operand ~ames of the user1s program, and a
Static Data Area 606~ A Procedure 602 may also include -
other Procedure Objects 608, for example utility programs
20 available in common to many users. In effect, a
Procedure 602 contains the instructions ~procedures) and
.~ data o~ a user's program.
; A Process 610 includes, as described above, a Macro-
: S ack (MAS) 502 storing state of execution of a user 1 5
25 Procedure 602 at the SOP level, 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 ABP5 described above
. and which are stored in the ~AS 502 of the Process 610.
: 30 Similarly, the MAS 502 and SS 504 o a Process 610 are
f :'.
'" .',
. ' .
':' ~; ' ' :
~' ' .
~' ~
'' ' " ' ' . ' . ' ' `"'''`',~,'''. , ' '
~ ' ' ,' ' ' ' , ' ; '` ' ' ' ' ' '" " '; ' ' ' ~
~' ' ' " ' .
,' ,; .
~7~7
-50-
associated ~hrough non-architectural pointers, described
aboveO A Proce~s 602 is e~fectlvely a body of
information linking the resources, hardware, microcode,
and software, of CS 101 to a us2r's Procedure 602. In
5 effect, a Process 610 makes the resources of CS 101
available to a useris Procedure 602 for executing of that
Procedure 602. CS 101 i3 a multi-program machine capable
of accommodating up to, for example, 128 Processes 610
: concurrently. The number of ~rocesses 610 which may be
; 10 executed concurrently is determined by the number of
Virtual Processors 612 of CS 101. There may be, for
e~ample, up to 16 Virtual Processors 612.
As indîcated in ~ig. 6, a Virtual Processor 612 is
comprised of a Virtual Processor State Block ~VPSB) 614
15 associated with the SS 504 of el Process 612. A VPSB 614
;: is; in e~fect, a body o~ information accessible to CS
lOl's operating system and through which CS lOl's
: . operating sys~em is informed of, and provided with access
to, a Process 510 through that Process 610's SS 504. A
20 VPSB 614 is associated with a particular Process 610 by
w~iting informatlon regarding that ~rocess 610 i~to that
VPSB 614. CS lOl's operating system may, by gaining
access to a Process 610 through an associated PSB 614,
read information, such as ~BP's, from that Process 610 to
25 FU lZ0, thereby swapping that Process 610 onto FU 120 for
execution. It is said that a Virtual Processor 612
thereby executes a Process 610; a Virtual Processor 612
may be regarded therefor, as a processor having
nVirtualn, or potential, existence which becomes "real"
.,
...
:::
, . .
,. .
; . ~ " ;-
,: . ~:
- " ~ .: . .~
. , :
~ -51-
: when its associated Process 610 is swapped into FU 120.
In CS 101, as indicated in Fig~ ~, only one Virtual
Processor 612 may execute on FU 120 at a time and the
operating ~ystem selects w~ich Virtual Processor 612 will
excecute on F~ 120 at any given time. In addition, CS
101's operating system selects which Processes 610 will
be a~ociated with the available Virtual ~rocessors 612.
~ aving briefly described certain individual
structural and operatiny eatures o~ CS 101, the overall
:10 operation of CS 101 will be described in further detail
next below in terms of these individual features.
: 15 As indicated in Fig. 7, CS 101 is a multiple level
sys em wherein operations in one level are generally
. transparent to higher levels. User 701 does not see the
; S-Language, addressing, and protection mechanisms defined
at Architectural Level 708. In~tead, he sees ~ser
20 ~nt~rface 709r which is defined by Gompilers 702, Binder
703, and E~tended (high level) Operating System (EOS)
704~ Compilers 702 tran late high-level language code
into SIN~ and Binder 7~3 translates symbolic Names in
: programs into UID-of~set addresses.
~ 25 As Fig. 7 shows, Architectural Level 708 is not
:: de~ined by FU 120 Inter~ace 711~ Instead, the
architectural resources level are created by S-Language
interpreted SIN~ when a program is executed; Name
'".:. :'
....
, . . .
.,, ~ .
.
, ~ .,
, . -. . , : . ~. .,, , ., ~ , ,
.. , . ,: , ,
;. .~
76
-52-
Interpreter 715 operates under control o~ S-Language
Interpreters 705 and translates Names in o logical
descriptors. Xn CS 101, both S-Language Interpreteris 705
and Name Interpreter 715 are implemented as microcode
which executes on FU 120. 5-Language Interpreters 705
may also use E~ 122 to perform calculation~. A ~ernel
Operating System (ROS) provides CS 101 with UID-offset
addressing, objec~s, access checking, processes, and
-~ virtual processors, dei~cribed further below. KOS has
three kinds of comp~nents ROS ~icrocode 710, ROS
Software 706, and ~OS TablPs in ~EM 112. ROS 710
:` components are microcode routines which a~sist FU 120 in
;~ per~orming certain required operations. ~ike other high-
level language routin~s, ROS 706 componen~s contain SINs
15 which are interpreted by S-Interpreter Microciode 705.
any ~OS ~igh-Level Language Routines 706 are executed by
special KOS processes; others may be executed by any
process. Both ROS ~igh-Level ~anguage Routines 706 and
ROS Microcode 710 manipulate ROS Tables in MEM 112.
2- F~ 120 Interface 711 is visible only to ROS and to S-
Interpreter ~icrocode 705~ ~or the purposes of this
discusslon, ~ 0 may be seen as a pr~cessor which
~: co~tain~ the following main elements:
A Control Mechanism 725 which executes
j Z5 microcode stored in Wri~able Control Store
.i 713 and manipulates F~ 120 devices as
Z~ directed by this microcode.
.
'
:. :
.. ..
, ' .
,
- . . ~
: ' ' .:: '
,
, ', ~
- ' ' "'
53
A GRF 506 containing registers in which
data may be stored~
- A Processin~ Unit 715.
~; All microcode whlch executes on FU 120 uses these
5 d~vices; there i~ in addition a group o~ devices for
performing special functions; these devices are used only
; by mi~rocode connected with those ~unctions. The
microcode, the specialized devices, and sometimes tables
in MEM 112 make up logical machlnes for performing
10 certain functions. These machines will be described in
detail below.
the following, each of the levels illustrated in
FigO 7 will be-discussed in urn. First~ the components
at ~ser Interface 70g will be examined to see h~w they
:` 15 tra~slate user programs and requests into forms usable by
... CS 101. ~hen the components be~low the User Interface 709 ~?
;.~ will be examined to see how they create logical machines ~:
for perfo~ming ~S 101 operations.
2. 9~ o3. _YLL=~Li~= ll
Compilers 702 tran~late fi.les con~aining the high-
-~ level language code writte~ by ~ser 701 into Procedure
Objects 608~ Two comp~nents of a Procedure O~ject 608
. are code ~SO~s) and ~ames7 previously described. SOPs ;
represent operations, and the ~ames represent data. A
. 25 single SI~ thu8 specifies an operation to be per~ormed on
the data represented by the Names.
.
. :
. , .
, .
' -:
. :
, . . . . ;. ~ . , , , :
... . ,. ., ; . .. .
-54-
3. ~Ah~ Ll_LLi~.=3~
In some cases, Compiler 702 cannot define locations
as of~ets ~rom an ABP. For example, i a procedure
~ calls a procedure con~ained in another procedure object,
; 5 the location to which the call transfers control cannot
: be deflned as an offset from the PBP u~ed by the calling
procedure~ In these cases, the compiler uses symbolic
~ames to define the locations~ ~inder 703 is a utility
~ which translates symbolic Names into UID offset
.: 10 addresses. It does so in two ways: by combining -.
separ~te Procedure Objects 608 into a single large
.-: Procedure Object 608, and then redefining symbolic Nam~s
as offsets from that Procedure Object 608's ABPs, or by
translating symbolic Names wh~n the program is executed.
. 15 In ~he second case~ Binder 703 requires assistance ~rom
EOS 704.
.. ' 4. ~s~_YI~=LLi... =l~
~; ~OS 704 manages the resources that User 701 requires
to execute his programsO From ~ser 7Ql's point of view,
~;~ 20 the mo~t importa~t ~f these resources are files and
proce~ses. EOS 704 creates files by requesting ~OS to
~:i ereate an object and then mappiny the file onto the
,~ objec~. When a User 701 performs an operation on a file,
. ;` EOS 704 ~ranslates the ~ile operation into an operation
25 on an object. ECOS crea~es them at EOS 704 ' s request and
i.~ makes them available to EO~ 704, which in tuxn makes them
available to User 701. EOS 704 causes a process to
.....
~ execute by associating it a Virtual Processor 612~ In
s,: .
.
, .
~'~;'`, ,
"
s: , . ,. ~ . . , . ~ .
,. -. . ~ ., : ,
, ~ . .. , , , - . :
,. :. ., , . ; , , ,; , ~:
s',
,
,.. . . .
-5~-
logical terms, a Virtual Proce~sor 612 is the means which
ROS provide~ EOS 704 for executing Processes 610. As
many Processes 610 may apparently execute simultaneously
: in CS 101 a~ there are Virtual Processors 612. The
illu~ion of simultaneous execution is created by
~ multiplexing JP 11~ among the Virtual Processors; the
: manner in which Processes 610 and Virtual processQrs 610
are implemented will be explained in detail below.
~Pi~ -7~
S-Interpreter Microcode 710 and ~ame Interpreter
; Microcode 715 re~uire an environment provided by KOS
Microcode 710 and ROS Software 706 to execute SINqo ~or
.-~ example, as previously explain,ed, Names and program
15 loc~tions are defined in terms of ABPs whose values vary
during execution of the progr~. The KOS en~ironment
`~ provides values or the ABPs, and therefore makes it
. possible to interpret ~ames and program locationæ as
; locations in ~M 112. Similarly, KOS help is required to
20 transform lsgical descriptors into references to ME~ 112
and to perform protection checks.
~: The environment provided by ~OS has the following
elements:
- A Process 610 which contains the state o~
an execution of the program fGr a given
. User 701~
- A Virtual. Processor 612 which gives the
Process 610 access to JP 114.
: . :
.. ~.
. ~
. .
::
". - . . ~ . .. .. .. . . . ,,, - . ,.
,:, . . . . .
1~ 66
-56-
: - ~n Object Management Sys~-em which
tra~slates UI~s lnto values that a~e usable
inside JP 114.
- A Protec~ion System which checks whether a
Proc~s~ 610 has the right to per~orm an
.: opera ion on an ObjectO
... .
- ~ Virtual Memor~ Mana~ement System which
moves ~hose portions of Objects which a
Process 610 actually references from the
lQ ou~side world into MEM 112 and translates
logical descriptors into phy~ical
descriptors.
~ In the ~ollowin~, the logical properties of this
'~ environment and the manner in which a program is executed
15 in it will be explained.
Processes 610 and Virtual Processors 612 have already
been described in logical terms; ~ig~ 8 gives a high-
~ ZO level view o their phy~ical implementation.
'- Fig. 8 illustrate the relationship between Proc2sses
. 610, Virtual Processors 612, and JP 114.. In physical
texms, a Process 670 is an area uf ME~ 112 which contains
, ~ the current state of a user's executio~ of a program.
25 One example of such sta~e is the current value~ of the
~: ~BP5 and a Program Counter (PC). Given the current value
of the PBP and the PC, the nex~ SOP in the program can be
executed; similarly, given the curren~ values of SDP and
.,, :.
. .
~, ....................... . .
" , ~
.' .
;,., '
~",, ., ; . . ~ . ~ . , ,
~'
~747
-57-
. ~
FP, ~he program' s Names can be correctly resolved., Since
the Process 610 conl:ains the current ~i:ate of a program
execution, the program' s phy~ical execution can be
stopp~d and resumed at any point. It is thus pos~ible to
5 control program execution by means of the Process 610. ?
As already mentioned, a Process 610's execution
.~ proceeds only when ROS has bound .it to a Virtual
Processor 612, that is, an area of ~qEM 112 containing the
state required to execute microinstruction~ on JP 114
10 hardware~ The operation of binding is simply a transfer
c of Process 610 state from the Process 610 's area of IqEM :-
: . 112 to a Virtual Processor 612 ' s area of MEM 112 . Si~ce
. ~ binding and unbinding may 'cake place at any time, EO5 704
may multiplex Processe~ 610 amor3g Virtual Processors
15 612. In Fig~ 8, there are more Processes 610 than there
are Virtual Processors 612. The physical execution of a
Proces~ 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 transfe~red ~rom Virtual Processor 612's
20 area of I~EM 112 to JP 114 's regis~ers. Ju~t as EOS 704
:- multiplexes ~tirtual Processors 612 among Processes 610,
KOS multiplex~s JP 114 among Virtual Processors 612. In
Fig. 8, only ~ne Process 610 is being physically ~:
executed. The mean~ by which JP 114 is multiplexed among .
25 Virtual Proces~ors 612 will be d~scribed in further
detail below.
.. ;, :. :.
',.:: '
,:' :
'. ~ '
,
': ;
, .
,
, .
- , . ~ . . . . : . . ..: . ~ . .
, , : . , . , . ,, .. ,. :, ., ., . . .; :
~ 7
-58
7. L ~_~
In CS 101 systems~ a Process 610 is made up of ~ix
Objects: on~ Process Ob~ect 901 and Five Stack Objects
902 to 906. Fig. 9 lllustrate~ a Proce~s 610. Process
5 Object ~01 contains the information which EOS 704
;: requires to manage the Proce~s 610~ EOS 704 has no
direct access to Pro~ess Object 901, but instead obtain~
the information it needs by means of functions provided
. to it by ROS 706, 710. Included in ~he information are
10 the UIDs of Stack Objects 902 through 906. Stack Object~
902 to 906 conta~n the Process 610's state.
S~ack O~jects 902 through 905, are req~ired by CS
lOl's domain pro~.ection method and comprise Process 610ls
~A5 502. Briefly, a domain is determined in part by
15 operations per40rmed when a system is operating in that
domain. ~or example, the system is in EOS 704 domain
~ when executing EOS 704 operatlons and in ROS 706, ~10
: domain when exe-uting ~OS 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 ixed at
fourr but alternate embodiments may allow any number of
domains, and corre9pondi~gly, any number of Stack
~;: Objects. Stack Object 9G6 ompri~es Process 610's Secure
S'cack 504 and is required to store state which may be
25 manipulat~d only by ROS 706 r 710 .
Each învocation made by a Pzocess 610 re~ults in She
addition of frames ~o Secure Stack 504 and to Macro-Stack
502. The state stored in the Secure Stack 504 frame
,
.
,:
.. .
. . . .
,
,
~ , ,: , , , ' .,. ' ,~ ', ,,
.' "'" ' ' ' " ' , . ~ ' , '' ' ~ ' ' " '
,
h~
~ 6
.~ -59-
... .
~` includes the macro~tate for the invocation, the state
required to bind Process 610 to a Virtual Processor 612.
The frame added to Macro-Stack 502 i5 placed ~n one of
Stack Objects 902 through 905. Which Stack ObjPcts 902
~ 5 to g05 gets the frame is determined by the invoked
; procedure's domain o~ execution.
~: Fig. 9 shows the condition of a Process 610's MAS 502
and Secure Stack 50~ af~er the Process 610 has executed
four invocations. Secure Stack 504 has one frame for
10 each invocation; the frames of Process 610's ~AS 502 are
~ound in Stack Objects 902, 904, and 905~ As revealed by
their locations, Frame 1 is ~or an invocation of a ~.-
routine with ROS 706, 710 domain of execution, Frame 2
for an invocation of a routine with the EOS 704 domain of
. 15 execution, and Frames 3 and 4 for invocation~ of routines
-. with the User domain of execu~.ion. Process 610 has not
`~ yet invoked a routine with the Data Base ~anagement ~
~ System (DBMS~ domain of execut.ion. ~he frames in Stack : :
`;` O~je~ts 902 through 905 are li.nked tosather, a~d a ~rame
. 20 i~ added to or remo~ed from Secure Stack 504 every time a
frame is added to Stack Objects 902 through 90S9 MAS 502 : :
. and Secure Stack 504 thereby function as a single logical
stack e~en though logically contained in five separate
. Objects. j
~ 25 8. ~ ::~.
: In the CS 101, calls and retuns are executed by ROS
~: 7~6, 710. When ROS 706, 710 perorms a call ~or a :::
. process, it does the ~ollowing:
~.,, :
. ' . :
,
... . .
, .. . .
, . . . . .
., . ,. .. , ::
~: . . . ,. , - ~.
, .,, . . :
; ~ ' . .. ' ` . :
~,' ' .. . . . , :
.; . . . . . .
76
~60--
It saves the calling invocation's
macrostate in the top frame o Secure Stack
' 504 ~Fig. 3)0
~ locates ~he procedure whose ~ame is
.~ 5 contained in the call~ The location o the
: first S~N in the procedure become~ the new
PBP~
~ - Using information contained in the called
.- procedure, ROS 706, 710 creates a new MAS
~02 rame in the proper Stack Object 902
through 905 and a new Secure Stack 504
~;: fram~ in Secure S~a k 504. FP is updated
.~ to point to the new MAS 502 D I~ necessary,
SDP is also updated.
On~e the ~a~ues of the A~Ps have been updated, the PC
.. is defined, ~mes can be resol.ved, and execution of the
invoked routine can comme~ceO On a retuxn ~rom the :
invocation to the invoking routine, the stask frames are
:"
deleted and the ABPs are set t:o the values saved in the
- 20 invoking routine's macrostate~ The invoking routine then
con~inues execution a~ the poin~ following the
i~vocation.
:~ A Process 610 may be illustrated in detail by puttin~
the FORTR~ statement A + B into a FORTRAN routine called
: 25 EX~MPL~ and invoking i~ ~rom another FORTRAN routine
~ named CALLER. To simpli~y the example, it is assumed
.. that CALLER and E~A~PLE both ha~e the same domain of
"''.. : :
, . :
. ~, . ` ' :
,' ~ . '
:
,''
`.'
,
: ~ , . , , :. i
, -
1~7~ 6
-61 -
.
execution. The parts o EXAMPLE which are o~ interest
look like this:
SUBRO~TIN~ BX~PLE (C)
X~TEGER X,C
: 5 ~NTEGER A,B
: 00-
:~ A - B
, ....
RET~RN
. 10 END
The new elements are a formal argument, C, and a new
local variable, X~ A formal argument is a data item ~ , :
which receive~ its value from a data item used in the
invoking routine. The formal argument's value thus
15 varies from invocation to invoca~ion. The portions of
:, INVOKER whlch are of interest :look like this:
SUBROUTINE INVOR'ER
I~TEGER Z
~ ~ ~
:~ 20 CALL EXAMPLE (Z)
.: .. .~
, . . .
- END
~he CALL statement in INVO~R specifies the Name of
the subroutine b~ing invoked and the actual arguments for
25 the subroutine's ~ormal arguments. During the
invocation, the q~broutinels formal arguments take on the
. values of the a~tual arguments. Thus, during the
' invocation speciied by this CALL statement, the formal
,.
"' .
. ~,
,:,-
. ,
,,
, .. , . . , . - . .~.. .
:. . . ,: . . . . . . . . .. .
, :, . , ,,: .,. ; , .
.. . . .. . . . . . .
, ~ . .. . .. . .
. , , . . ~ ,~:
.,. . , - , . . . .
. ' ~ : : ~
Sr~srA~
3L~7~7~6
~`'' ,.
.
62-
argument C will have the value represented by the
variable Z in INVOKER.
When I~VOgER is compiled, the compiler produces a
CALL SIN corresponding to the CALL statement. The CALL
5 SI~ contains a ~ame representing a pointer to the
beginning of the called routine's location in procedure
object and a list of Names representing the call's actual
arguments. ~hen CALL is executed, th Names are
.~ interpreted to resolve the SI~'s Names as previou~ly
10 describedl and ROS 710 microcode to perorm MAS 502 and
Secure Stack 504 opera~ions.
Fig. 10 illustrates the manner in which the ROS 710
:`: cal~ microcode manipulates MAS 502 and Secure Stack 504.
Fig. 10 includes the followin~ elements:
- Call Microcode 1001, contained in FU 120
Writable Control Stoxe 1014.
~i
;: - PC Device 1002, which contains part of
macrostate belonging to the invocation of.
~ I~UOKER which is executing the CALL
:~ 20 ctatemen~.
Registers in FU Regis~ers 1014. Registers
~` 1004 con~en.ts i~clude the remainder o~
~ macrostate and the descriptors
.~ corresponding to Names for EXAMPL~'s
~-~ 25 location and the actual argumen~ Z.
- Procedure Object 1006 co~tains the entries
for INVOK~R and EXA~PLE, their Name Tables, ~:.
.
:- and their code. ~ ~
, -- .
~'"
j ,~
,; ; .
' :'
. .: :
. . : . , ... ~ ,. ' ,,
:: . .,: ,
,,
... .
L7f~7~
_63W
:~ - Macro-Stack Ob~ect 1008 ~MAS 502) and
- Secure S~ack Object 1010 (Secure Stack 504)
contain the stack frames ~or the
invocations of INVO~ER and EXA~PLE being
S discussed here. EXA~LE's frame is in the
- same Macro-Stack obj~ct as INVOR~R's frame
becau~e both routines are contained in the
same Procedure Object 1006, and therefore
:~ have the same domain o execution~ :
.~ 10 ~S Call ~icrocode 1001 irst saves the macrostate of
.i; INVO~ERI~ invocation on Secure Stack 504. As will be
discusise~ later, when the state is saved, ~05 706 Call
~ Microcode 1~01 uses other ~OS 706 microcode ~o translate
:~ the location information contained in the macrostate into `~ .
15 the kind o~ pointers u ed in ~E~ 112. Then Microcode :;~
. 1001 uses the descriptor for the routine Name to locatP : :
; the pointer to EXAMP~E's entry in Procedure Object 1006.
From the entry r it locates pointers to EXAMPLE's Name :~
~' Table and the beginning of EXAMPLE's code. ~icrocode
20 1001 takes these pointers, uses o~her KOS 706 microcode
o translate them in~o descriptors, and places the
descriptor~ in th~ locations in Registe~i 1004 reser~ed ~ :
for ~ha values of the PBP and NTP. It then updates the
.: : values contained in PC Device 1002 so that when the call
: 25 is finished~ t~e next SIN o be executed will be the
first SI~ in EXAMPL~
' .
.
1 :
, ~
"
. i
. ~ . ,. ~- .- . .. , - ., ; ---- - - ; . . . .-
. ~ .,
,, ~, ,
f~ ~
~ '~
7 ~7 6
-64-
; ::
~.
.^CALL Microcode 1001 next constructs he frames for
EXAMPLE on Secure Stack S04 and Macro~5tack 502. This
discussion concerns itself only with Frame 1102 on Macro-
.~Stack 502. Fig. 11 illustxates EXA~PLE's Frame 1102.
-5 The size of ~rame 1102 is determined by EX~PLE's local
~ariables (X, A~ and B) and ~ormal argum~nts (C). At the
bottom of ~rame 1102 is ~eader 1104. ~eader 1104
contains information used by KOS 706, 710 to manage the
~-stack. Next comes ~ointer 1106 to the location which
,10 contains the value represented by the argume~t C. In the
.:invocation, the actual for C is the local variable Z in
INVOKERo As is the case with all local variables, the
:storage represented by Z is contained in the stack frame
.belonging to INVOKER's invocation. When a name
interpreter re501ved C's name, it placed the descriptor
~............... in a register. Call ~icrocode 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
.-20 last pointer to an actual argument, Call Microcode 1001
can now calcuIate that location, convert it into a
:descriptor, and place it in a FU Register 1004 reserved
for FPo The next step is providing storage ~or EXA~PLE's
local variables. EXAMPLE's Procedure Object 1006
contains th~ size of t~e storage required for the local
..variable~, so Call Microcod~ 1001 obtains this
. information from Procedure Object 1006 and adds that much
~ storage to Frame 1102. Using the new value of ~P and the
,; '
.
,.:
~ w -
. - .,
t..
: ~ ,
.
- ~
,. . . .
766
~65--
information contained in the Name Table Entries for the
local data, Name Interpreter 715 can now construct
descriptors for the local data. For e~ample, A's entry
: in ~ame Table specified ~hat it was offset 32 bits from
5 FP, and was 32 bits long. Thus~ it5 storage falls
between the storage for X and B in Figure l~
As already explainedr a logical descriptor contains
10 an AON field, an offset field, and a length field. Fig. ~ ;
-~ 12 illustrates a Physical Descriptor. Physical
Descriptor 1202 contains a Frame Number (FN) field, a
... Displac~ment (D) ~ieldr and a Length (L) fieldO
I Together, the Frame Number ield and the Displacement
.. 15 field specify the location in ME~ 112 containing the
~, data, and the Length ield specifies ~he length of the
data.
~ As is clear from the above, the virtual memory
: management system must translate the AON-o~fset location
20 contained in a logical descriptor 1204 into a Frame
: ~umber-Displacement location~ It does so by associating
~:` logical pages with ~E~ 112 frames. (~.B: MEM 112 ~rames
are not to be conused with stack frames). Fig. 13,
:~ illustrates how Macros ack 502 Object 1302 is divided
25 into Logical Pages 13 04 in secondary memory and how
Logical Pages 1304 are moved onto Frames 1306 in MEM
112. A FramP 1306 is a fixed-size, contiguous area of
ME~ 112. When the virtual memory management system
:
: .
:
'.:
, ,
.,
.
. , :
. ~ . ,
: , ,
7~ 6
. -6~-
brings data into ME~ 112, it does so in f rame-sized
chunks called Loyical Pages 1308. Thus, from the virtual
:~ memo~y system's point of view, each object is divided
into Lo~içal Pages 1308 and the address o data on a page
consists of the AON of the datals Object, the number of
pages in the object, and its displacement on the page~
In Fig~ 13, the lvcation o~ the local variable B of
EXA~IPLE is shown as it is defined by the virtual memory
system. Bls loc~tion is a UI~ and an o~fset r or, inside
10 JP 114, an AON and an of f set . As defin~d by the virtual
: memory system, B's location is the AON, the paqe number
.: 130~, and a displacement within the page, When a process
references the variable B, the virtual memory management
` sys em moves all of Logical Page 1308 into a ME~ 112 .
Frame 1306. Bls displacement remains the same, and ~he
virtual memory system translates its Logical Page Number
1308 into the number of Frame 1306 in M~M 112 which
contains the page.
The virtual memory management system must therefore
20 per~orm two kinds of translations: (1) AON-of~set
addresses into AO~-page number-displacement addresses,
a~d (2) AON-page number into a rame number.
"~
Bach time a reference is m~de to a~ Object, gOS 706,
25 710 checks whether th~ reference is legal. The ~ollowing
discu~son will first present the logical structure of
access control in CS 101, and then discuss the microcode
and devices which implement ito
,'
, . ~'
, .
'~
.. . . .
.. . . l . :
.. .. ~ . : : .
"'' ~.:, ' ' ;'' ,-''' ' ' '' ', ;~ " ' ":
~ ' .
~ .
7~i
_~7_
: .:
CS 101 defines access in terms of subjects, modes of
access, and Object size. A process may reference a data
item located in an Object if three conditions hold:
: 1) If the process'~ subject has access to the
Object.
~) ~f the modes of access specified for the
subject include those required to perform :~
.: the intended operation.
~ 3) I the da~a itPm is completely contained in
: 10 the Object, i~eO, if the data item's length
: added to the data item's offset do not
exceed the number of bits in the Object.
The subjects which have access to an Object and the
~; kind~ of access they have to l:he Ob~ect are specified by a data structure associated with the Ob~ect called the
Acces~ Control List (ACL). ~1 Object's size i5 one of
.. its attributes. ~either an Object'~ size nor its ACL is ::
- contained in the Object. Both are contained in system
5,':` tahles~ and are accessible by means o~ the Object's UI~I
.. i 20 Fig. 14 shows the logical structure of access control
~,"5 in CS 101~ Subject 1408 has four components: Principal
.;' 1404, Process 1405, Domain 1406, and Tag 1407~ Tag 1407
is n~t implemented in a present embodimen~ o~ CS 101, so
: the followin~ description will deal only with Principal
i 25 1404, Process 140$, and Domain 1406.
;~ - Principal 1404 speci~ies a user for which
~. the proces~ which is making the reference
1:` was created;
i. ,
1'
:.
,
, ~. . . ..
ç , . i ;
,
.. .. . .
.
. ~ ~
:f
. ~ .
:,
-68~
- Process 1405 specifies the process which is
making the reference; and,
Domain 1406 ~peciies the domain of
execution of the procedure which ~he
.~ 5 process is executing when it make~ the
: reference.
Each compQnent of the Subject 1408 is repre~ented by
a UID. If t~e ~ID is a null UID, that component of the
- ~ubject does not affect access checking9 Non-null ~IDs
: 10 are the ~I~s of Objects that contain information about
the subjec~ components. Principal Object 1404 contains
~`. identification and accounting in~ormation regardiny
m system users, Process Object 1405 contain~ process
~ management information, ahd Domain Object 1406 contains
5'~ 15 information about per-domain error handlers~
~` There may be three modes of accessing an Object 1410:
r read, write, and execute. Read and write are self-
i~ explanatory; execute is access which allows a subject to
.~ execute in~tructions contained in ~he Object.
Access Control ~ists tA~hs) 1412 are made up of
.. Entries 1414. Each entry two components: Subject
ç............... Template 1416 and ~ode Speci~ier l~lBc Subject Template
1416 specifie~ a group of subjects that may reference the
`-~ Object and Mode Specifier 1418 specifies the ki~ds of
~ 25 access ~hese subjects may have to the Object. ~o~ically
q speaking, ACL 1412 is checked each time a process
~; re~erences an Object 1410. The reerence may succeed
.: only if the process7s current Subject 1408 is one o~
;
" : .
~,.,.: . ~ .
7.
/, . :
. .
,':::
,~:'
,
J , , ' " , . ' ,
7 ~.
-69- :
~hose 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.
' 5 ~c~d~uD~ky~=b~ .
As previously mentioned, the execution of a program
by a Process 610 cannot take place unles EOS 704 has
bound the Process 610 to a Virtual Processor 612.
Physical execution of the Process 610 takes place only
:: 10 while the process's Virtual Processor 612 is bound to JP
: 114. The foilowing discussion deals with the data bases
belon~ing to a Virtual ~rocessor 612 and the means by
, which a Virtual Processor 612 is bound to and removed
' from ~P 114.
., 15 Fig. 15 illu~trates the devices and tables which ROS
.` 706, 710 uses to implement Virtual Proces~ors 612. FU
.. i 120 WCS contains KOS Microcode 706 for binding Virtual
` Processors 612 to JP 114 and removing them from JP 1140
: Timers 1502 and Interrupt Line 1504 are hardware devices
which produce signals that cause the invocation of ROS
. Microcode 706. Tim~rs 1502 contains two timing devices;
:. Interval Ti~er 1506, which may be set by ~OS 706, 710 to
signal when a Gertain time i5 reached, and Egg Timer
1508, which guarantees that there is a maximum time
25 interYal for which a Virtual Processor 612 can be bound
to JP 114 before it invokes ROS Microcode 706. Interrupt
Line 1504 beco~es active when JP 114 receives a message
: from IOS 116, for example when IOS 116 has finished
loadin.~.a lo~ical page into ~E~ 112.
.
.,~ .,
.-
~
~ . "
::
-. : ~: , '
- .,, ~ :
. : . . , :
,,
~ ' '
. .
~ ~7~7~i~
.,
. ~70-
FU 120 Regis~ers 508 contain state belonging to ~he
Virtual Processor 612 currently bound to JP 114. ~ere,
this Virtual Processor 612 is called Virtual Pxocessor
A~ In addition, Registers 508 contain registers reserved
for the execution of VP Swapping Microcode 1510. AL~
1942 (part of FU 120) is used or the descriptor-to-
pointer and pointer-to-descriptor trans~ormations
required when one Vir~ual Processor 612 is unbound from
JP 114 and another bound to JP 114. MEM 112 contain~
data bases for Virtual Processors 612 and data bases used
by ~OS 706, 710 to manage Virtual Processors 612. ROS
~: 706, 710 provides a ixed number of Virtual Processors
612 for CS 101. Each Virtual.Processor ~12 is represented
by a Virtual Processor State Block (VPSB) 614. Each VPSB
614 contains inormation used by ~OS 706, 710 to manage
~ the Virtual Processor 612, and in addition contains
: information associating the Virtual Processor 612 with a
`: process. ~ig. 15 shows two VPSBs 614, one belonging to
Virtual Processor 612At and another belonging to Vir~ual
: 20 Processor 612B, which will replace Virtual Processor 612A
on JP 114. The VPSBs 614 are contained in VPSB Array
~ 1512. The index of a VPSB 614 in VPSB Arr~y 1512 is
i Vir~ual Processor Number 1514 belonging to the Virtual
ProGessor 612 represented by a VPSB 614. Virtual
;:~. 25 Processor Lists 1516 are lists which ROS 706, 710 uses to
; manage Virtual Processors 612. If a Vir ual Proces~or
612 is able to execute, its Virtual Processor Number 1514
;: is on a list called the Runnable List; Virtual Processors
"`'.' ' ~:
. , ~
, . .
:. .
, . , . .~ . . .
, . . ..
, . . ..
, . .
.
, ' , ~ :
117'~7
; -7 1 -
,
~ 612 which cannot run are on o~her lis~s, depending on the
,~ reason why they cannot run. It i3 assumed that Virtual
Processor 61~BIs Virtual Processor Number 1514 i5 the
first one on the ~unnable List~
~ 5 Whe~ 2 process is bound to a Virtu21 Procesor 612,
': the Virtual Processor Number 1514 i5 copied into the
,~ - process's Process Object 901 and the AONs of the
: process's Process Object gOl and stacks are copied into
~: the Virtual Processor 612's VPSB 614. ~AONs are used
`, . 10 because a process ' s stacks are wired active as long as
; the pro~ess is bound to a ~irtual Processor 612).
: Binding is carried out by ROS 706, 710 at the request of
EOS 704. In Fig. 15, two Secure Stack Objects 906 are
. shown, one belonging to the proc~ss ~o which Virtual
.: 15 Processor 612A is bound, and one belonging to that to
which Virtual Processor 612B ls bound.
~: ~aviny described certain overall operating f ea~ures
of CS 101, a present implement:ation of C5 lOl's structure
:~ will be described fur~her next: below.
E
~'
,....
.:.- Referring to Ei~. 16, a partial block diagram of IOS
~;~ 116 is shownO Major elements of IOS 116 include an
25 ECLIPS~ Burst Multiplexer Channel (B~C~ 1614 and a NO~A~ ;
Data Channel (NDC~ 1~16, an IO Controller tIOC) 1618 and
a Data Mover (DM) 1610. IO~ 116's data channel devicss,
for example BMC 1614 and ~DC 1616, comprise IOS 116's
~,.-; interface to the outside world. Information and
~:: 30 addresses are received from external devices, such as
;,. .
~,' , .
~ ' ' .
~.'
. .... . - . , . . ,,~
, . . . ~ . - - .:
~, , , ~ , .
~ . " ,
,
~3l'7i~7~
-72- :
.
disk drives, communications modes, or other computer
~ystems, by IOS 116's data channel devices and are
transferred to D~ 1610 ~described below) to be written
into MEM 112~ Similarly, information read from MEM 112
is provided through D~ 1610 to IOS 116' 5 data channel
devices and thus to the above describPd external
devices~ These external devices are a part of CS 101's
addressable memory space and may be addressed through UID.
a~dre~ses.
IOC 1618 is a general purpose CPU, for example an
ECLI~S~ computer available from ~ata General
Corporation. A primary function of IOC 1618 is control
of data transfer through IOS 116. In addition, IOC 1618
generates individual Maps for eac~ data channel device
for translating external device addresses into physical
addresses within MEM 112 D As indicated in Fig~ 16, each
data channel device contains an individual Address
Translation Map ~MAP) 1532 and 1636. This allows IOS 116
to assign individual areas of ~EM ll~'s physical address
space to each data channel device. This feature provides ::
protection against one data channel device writing into
or reading from information belon~ing to another data :~
channel device. In addition, IOC 1618 may generate
overlappin~ address translation Maps for two or more data
channel devices to allow these data channel devices to
share a common area of ME~ 112 physical addresæ space.
, . .
.,,~
,
, .... ...
i .- .
.. . .
,: ~ - , .. .. .
, ~ - .. . .
i ' 1 , .. -:
,: . , ' ' :
~: .
. . . .
~ 7~ 5'
: -73-
Data transfer be~ween IOS 116's data channel devices
,~ and ,~E~ 112 is through DM 1610, which includes a Buffer
: memory ~BUF) 1641~ BUF 1641 allows MEM 11~ and IOS 116
~- to operate asychronou31y. DM 1610 also includes a Ring
; 5 Gra~t Generator (RGG) 1644 which controls access of
various da~a channel devices to ~EM 112. RGG 1644 is
designed to be flexible in apportioning access to MEM 112
among IOS 116lS data channel devices as loads ~arried by
;~ various data channel devices varies. In addition, RGG
; 10 1644 insures that no one, or group, of data channel
:.............. devices may monopolize access ~o ~EM 112.
Referring to Fig. 17, a diagramic representation of
RGG 1644's operation is shown. As described further in a
following description, RG& 1644 may be regarded as a
: 15 commutator scanning a number of ports which are assigned
: to various Ghannel devices. For example, ports A, C, E,
.~ and G may be assigned to a BMC 1614 r ports B and F to a
NDC 1616, and ports D and ~ t~ another data channel
: device. RGG 1644 will scan each of these ports in turn
~; 20 and, i~ the data channel device associated with a
',~` particular port is requesting acce~ to ME~ 112, will
~ gra~t access to ME~ 112 to that data channel device~ If
i: no request is present at a given port, RGG 1644 will
continue immediately to the next por~. Each data channel
25 device as~igned one or more ports is thereby in~ured
~ opportunity of access to MEM 112. Unused ports, or
,~. example indica~ing data channel devices which are not
:j presently engaged in information transfer~ are
,
, ' .
,
,, .
, ~ , ' '' ' ''' ' '
.. .. .
~" .
,. ' ` ~ :
~ ~ '7~`7~6
7 4
effectively 3kipped over so 'chat access to MEM 112 is
dynamirally modif ied according to the informakion
transfer loads of he various da'ca chann~l d~vice~. RGG
. 1644 's ports may be reassigned among IVS 116 's various
data cha~nel devices as re~uired to suit the needs of a
5 particular CS 101 system~ If, for example, a particulaE
CS 101 utilizes NDC 1616 more than a BMC 1614, that CS
101 's ~DC 1616 may be assigned more ports while that CS
: 101's BMC 1614 is assigned fewer ports.
2. ~s~o =~ 92ti~b~-L=~91
: 10 Referring to Fig. 18, a partial block diagram of M~M
112 is shown. Major elements of MEM 112 are Main Store
8ank tMSB) 1810, a Bank Controller (BC) 1314, a Memory
Cache (MC) 1816, a Field Interface Unit (FI~) 1820, a~d
Nemory Interface Controller (~IC) 1822~ Interconnections
~: 15 of these elements with input and output buses of MEM 112
; to IOS 116 and JP 114 are indi,cated. :~
MEM 112 is an intelligent, prioritiæing memory having
a single port to IOS 116, comprised of IOM Bus 130, MIO
Bus 129, and IOMC Bus 131~ and dual ports to JP 114. A
~;~ 20 first JP 114 port is comprisecl o~ MOD Bus 140 and PD Bus
: 146, and a second port is comprised of JPD Bus 142 and ~D
.~; Bus 146. In general, all data transfers from and to PIE~
112 by IOS 116 and 3P 114 are of single, 32 bit words;
-~ IOM Bus 130, DqIO 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
t'.. ' data buse~ are not apparent to a user. For example, a
,
.
.
,
:, .
.. !
'' :., ' , '' '' ' ' . ~ .
, . . . ..
, . . . . .
. ,',!, . . ~, '
-
~71~76'~;
: -75-
~ame in a user's program may refer ~o an operan~
cantaining 97 bits of dataO To the user, that 97 bit
data item will appear to be read from MEM 112 to JP 114
in a single operation. In actuality, J~ 114 will r~ad
:. 5 that operand from ~E~ 112 in a series of read opera~ions
reerred to as a string transferD In his example, the
string transfer will comprise three 32 bit read ~ran~fers
and o~e single bit read transferO The final single bit
transfer, containing a single data bit~ will be of a 32
: 10 bit word wherein one bit is data and 31 bits are fill.
Write operations to MEM 112 may be performed in the same
~ manner. If a single read or write request to ~BM 112
~ specifies a data item of le~s than 32 bit~ of data, that
transfer will be accomplished in the same manner as the
15 ~inal tra~sfer described aboveO That is~ a single 32 bit
word will be transferred wherein non-data bits are fill
: bits.
Bulk data storage in ME~ ].12 is provided in MSB 1810,
which is comprised of one or mor~ ~emory Array cards
(~s) 1812. The data path int:o and out of MA 1812 is
~hrough BC 1814, which performs all control and timing
~` ~unc~ions or MAs 1812. BC 1814's unc~io~s include
addressing, t~ansfer 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 M~ 1812 through BC 1814 are in
- blocks o four 32 bit words.
.,: . , .: ., , ~ - :
IJ., . ', . ~' ~, ~;,. -.... :
.
.
~ 7 6
: -75-
:
The variou~ ~s 1812 comprising MSB 1810 need not be
of the same data storage capacity. ~or example, certain
MAS 1812 may have a capaci y of 256 kilobytes while othe~
MA~ 1812 may have a capacity of 512 kilobytesO
Addre~in~ of the ~As 18i2 in MSB 1810 is automatically
adapted to various ~A 1812 configuratlonsO As indicated
;~ in Fig. 18, each MA lal2 contains an address circuit lA)
which receiYes an inpu~ from the next lower MA 1812
~ indicating ~he highe~t address in that next lower MA :~:
:~ 10 1812. The A circuit on an MA 1812 also receives an input
from that ~A 1812 indicating the total address ~pace of
~; that MA 18120 ~he A circuit of that MA 1812 adds the
highest address input fro~ next lower MA 1812 to its own
input rep~esenting it~ own capacity and generates an
!: 15 ou~put to the next MA 1812 inclicating its own highest
address. All P~As 1812 of M5B 1810 are addressed in
' ~ parallel by BC 1814. Each MA 1812 compares such
addresses to its input rom the next lower ~A 1812,
r~presentillg highest address o~ that next lower MA 1812,
20 and its own output, representing its own highes~ address, .
to determine whether a particular address provided by BC
1814 lies within the range of addr~sses contained within
` that particular ~IA 1812. The particular MA 1812 whose
address ,space includes that address will then respond by
accepting the r~ad or write request from B~ 1314.
,
,j,.. ... .
~: ,
f!. ` .
1 .
,.....
~, '-;
,
. ' ,
~,: , ..
~, . ;
" : i .
~, , ,
-77-
~ C 1816 is the data path for transfer of data between
BC 1814 and IOS 116 and JP 114. MC 1816 contains a high
speed cache storing da~a from M~ 1810 which is curre~ly
:; being utili2ed by either IOS 116 or JP 114. MSB 1810
5 thereby ~rovides M~M 112 with a large storage capacity
while MC 1816 provides the appearance o~ a high speed
memory~ In addition 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 ~hrough BC 1814. In addition, MC 1816 includes a c~che
write-back path which allows data to be tran~ferred out
: of MC 1816's cache and stored while further data is
~ transferred into MC 1816's cache. Displaced data from MC
:~ 1816's cache may then be writtlen back into MSB 1810 at a
;~ 15 later, more convenient time. This write-back path
enhances speed of operation of MC lB16 by-avoiding delays
: incurred by transferring data :Erom MC 1816 to MSB 1810
before new data may be written into MC 1816.
E~ 112's FI~ 1820 allows manipulation of data
20 formats i~ writes to and reads from ME~ 112 by both JP
114 and IOS 116~ For example, FIU 1820 may convert
~ u~packed decimal data to packed decimal data, and vice
:~ versa. In addition, FI~ 1820 allows MEM 112 to operate
;: as a bi~ addressable memory. For example, as described
25 all data transfer~ to and from MEM 112 are of 32 bit
:~ words. If a data transfer of less than 32 bits is
required, the 32 bit word containing those data bits may
;
'~
~ :
,,:
,. ,
., : ;:
. . . .. ....
-
, , , - : ,.
76~ :
7~~
~e read from MC 1816 to FIU 1820 and therein manipulated
to extract the requlred data bit~. FI~ 1820 then
~ ~enerates a 32 bit word con aining those required data
:: bit., plus fill bits, and provides that new 3~ bit word
;: 5 to JP 114 or IOS 116~ When writing into MEM 112 from IOS
. 116 through FI~ 1820, data is ~ransferred on~o IO~ Bus
: 130, read into FIU 1820, operated upon, transferred onto
MOD Bus 140, and transferred from MOD Bus 140 to M~
: 1816~ In read operation~ from MEM 112 to IOS 116, data
10 is transf~rred from MC 1816 to MOD Bus 140, written into
;~ FIU 1820 and operated upon, and transferred on~o ~IO Bus
129 to IOS 1160 In a ~ata read from MEM 112 to JP 114,
data is trans~erred ~rom MC 1816 onto MOD ~us 140,
, ~ transferred into FIU 1820 a~d operated upon, and
15 transferred again onto MOD Bus 140 to JP 114 . In write
operations from JP 114 to MEM 112, dat~ on JPD Bus 142 is
transferred into ~IU 182Q and operated upon, and is then
, transerred onto MOD Bus 140 t:o MC 1816. MOD Bus 140 is
.~ thereby utilized as an MEM 112 intarnal bus for FIU 1820
`~: 20 operations.
Finally, MIC 1822 provides primary control of BC
~:i 1814, MC 1816, and ~IU 1820~ MIC 1822 receives cont:rol
-i inputs f~om and provides control outputs to PD Bus 146
and IO~C Bus 131. MIC 18Z2 contains primary microcode
25 control for MEM 112, but BC 1814, MC 1816, and FI~ 1820
each include internal microcode control. Independen~,
:~ internal microcode controls allow BC 1814, MC 1816~ and
FIU 1820 to operate independently of MIC 1822 after their ~.
' . '. .
r,
I'''''i
',
"' ,, , , , ' , ';;~ : ~
~, . 1: 1 ' : '
f'~
`~ ~79-
operations have been initiated by ~IG 132~. This allows
BC 1814 and MSB 1810, MC 1816, and FIU 1820 to operate
independently and asynchronously~ Efficiency and speed
- of operation of ~EM 112 are thereby enhanced by allowing
pipelining of MEM 112 operations.
3 ~
~ A primary function of F~ 120 is to execute SINs. In
:~:` doing ~o, FU 120 fetches instructions and data tSOPs and
~-~ Names) rom ~EM 112, returns resul~s of operations to ME~
:~ 10 112, directs operation of EU 122, executes ins~ructions
of user's programs, and perorms the various functions of
. CS 101's operating systems. As part of these functions,
FU 120 generates and manipulates logical addresses and
descriptor~ and is capable of operating as a general
.,
; 15 purpose CPU.
Reerring to Fig. 19~ a major element of FU 120 is
the Descriptor Processor ~DESP) 1910. DESP 1910 includes
~: General Register File (GRF) 506. &RF 506 is a large
register array divided vertically into three parts which
are addressed in parallel. A first part, AO~GRF 1932 ,
~: stores AON fields of logical addresses and descriptors.
A second part, OFFGRF 1934, stores offset fields of
.~ logical addresses and descriptors and i~ utilized as a 32
bit wide general register array. A third portio~ GRF
~ 25 506, LE~RF 1936, is a 32 bit wide register array for
- ~ storing length fields of logical descrip~ors and as a
~ ~ general register for storing data. Primary data path
s,'.
.,
,~
, . ,
. ~ , .
,.............. .. . .
, .; . ,: '; . .. , . :
,. . .
^ - \
7~i
~o
. ~
from M~ 112 to FU 120 is through MOD ~us 140, which
provides inputs to :)FFGRF 1934 . As indicated in Fig . 19,
data may be transferred from OFFGRF 1934 to inputs o~
AONGRF 1932 and hENGRE 1936 through various
5 interconnections. Similarly, outputs from LENGRF 1936
and ~ONGRE 1332 may be ~ransferred to inputs of AO~GRF
1932, OFFGRF 1934, and LENGRF 1936.
: Ou~put of OF~ÇRF 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 ~eneral purpose arithmetio
and logic operands performed by MUX 1940. Output of ALU
1942 is connected to JP~ Bus 142 to allow results of
~ 15 arithmetic and logic operations to be transferred to ME~
:~: 112 o~ ~U 122~
Also connected from output of OFFGR~ 1934 is
. Descriptor Multiplexer (MUX) 1940. An output of MUX 1~40
: is provided to an input of ALU 1942~ M~X 1940 is a 32
2Q bit ALU, includin~ an accumulator, for data manipulation
- operationsO ~UX 1940, together with ALU 1942, allows
; DESP 1~10 to perform 32 bit arithmetic and logic
operatio~sO MUX 1940 and ~LU 19~2 may allow arithmetic ::
; and logic op~rations upon operands of yreater than 32
25 bits by performing successive operations upon successive
32 bit words of larger operands.
Logical descriptors or addresses generated or
provided by DESP 1910, are p~ovided to Logical De~criptor
."
'' '"
.. ..
, , ~ , ~, ,, ; . .
.
,- . . , : , .
.
~:~7;~766
-81-
: (LD) Bus 1902. LD Bus 1902 in turn is connected to an: input of Address Translation Unit (~TU) 1928. ATU 1928
:~ is a cache mechanism for converting logical descriptors
:~ to MEM 11~ physical descriptors.
~ 5 LD Bus 1902 is also connected to write input of Name
`~ Cache (NC) 1926~ NC 1926 is a cache mechanism for
i storing logical descriptors corresponding to operand
Names currently being used in user's programs. As
previously described, Name Table Entries corresponding to
10 operands currently being used in user's programs are
stored in MEM 112. Certain Name Table Entrieæ for
operands of a user's program currently being executed are
~ transferred from those Name Tables in MEM 112 to FU 120
'~ and are therein evaluated to generate corresponding
~ 15 logical descriptor~ These logical descriptors are then
5~' stored in NC 1926- As will be described further below,
.~ the instruction stream of a user's program is provided to
.~ FU 120's Ins~ruction Buffer (IB) 1962 through MOD Bus
~: 140. FU 120's Par~er (P) 1964 separates out, or parses7
. ! 20 Names from IB 1962 and provides those Names as address
inputs to ~C 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 resulting from evaluation of ~ame ~able
:~ 25 Entries to he written into NC 1926. FU 120's Protections
: Cache (PC) 1934 is a cache mechanism having an input
. connected from LD Bus 1902 and providing information, as
~` described further below, regarding pro~ection aspects of
r....
~;
~f, ~ .
/
:
' ` ' ' ` ,' `' ' ' ' ' .` '
'~ ' " .' "' . : .
~ ' ~ ' ' '
,
. . ' ' ' ' ' '
~' : ' ' . ' ' "
i,
~,
- - -
-82-
references to data in MEM 112 by user's programs. NC
1926, ATU 192a, and PC 1934 are thereby a~celerat~on
mechanisms of, respectivelyr CS 101's Namespace
addressing, logical to phy ical address structure, and
protection mechanism.
Re~erring again ~o DESF 1910, DESP 1910 includes BIAS
1952, connected from output of LENGRF 1936. As
previously described, operands containing more than 32
data blts are transferred beteen MEM 112 and JP 114 by
means of string trans~ers. In order to perform string
.. ~ t~ansfers, it is necessary ~or FU 120 to generate a
.. corresponding succession of logical descrip~ors wherein
: length fields of those logical descripto~s is no greater
than 5 bits, that is, specify lengths of no greater than
. 15 3~ data bits.
:. A logical descriptor describing a data item to be
transferred by means of a string transfer will be stored
`. in GRF 506. AON field of the logical descriptor will
r~side in AONGRF 1932, 0 field in OFFGRF 1934, and L
~ield in LENGRP 19360 At each successive transfer o~ a
32 bit word in the s~ring transfer, O ~ield o~ that
original logical descriptor will be increme~ted by the
number o data bits tra~s~erred while L field will be
` accordingly decrementedO The logical descriptor residing
:: 25 in GRF 506 will thereby describe, upon each successsive
transfer of the string transfer, that portion of the data
item yet to be transferredO O field in OFFGR~ 1934 will
lndicate increasingly larger offsets into that data item,
while L ~ield will in~icate successively shorter
:
: .
,
,
. . . . . : ~ ~
,: . :, , , . . . , '
:. ,, , . : .
7~
-83
:
lengths . AON and O f ields of the logical descriptor in
GRF 506 may be utilized directly as AO~ and O f ields of
- the suc~essive logical descriptors of the string
transfer~ L field of 'che logical descriptor residing in
S LEN~;R~ 1936, however, may not be so used as L fields of
the successive string transfer logical descriptors as
t~is L f ield indlcates remaining length of data item yet
.~ to be transferred. Instead, BIAS 1952 generates the 5
bit L fields o~ ~uccessive string transfer logical
10 descrip~ors while correspondingly decrementing L f ield of
: ~ the logical descriptor in LENGRF 1936. During each
transfer7 BIAS 1952 generates L field of the n~ string
~ transfer logical descriptor while concurrently providing
: L field of the S~ n~ string.transfer logical
, . . .
:~ 15 descriptor~ By doing so, BIAS 1952 thereby increases
:
~ speed of execution of string transfers by performing
si. pipelined L ~ield operations. BIAS 1952 thereby allows
CS 101 to appear to the user to be a variable word length
machine by automatically perfor~ing string transfers.
20 This mechanism is used for transfer of any data item
gr~ater than 32 bits, for example double precision
. 10ating point numbers.
-. Finallyt FU 120 includes microcode circuitry for
~ ..
controlling all FU 120 operations described above, In
:~ 25 particular, ~U 120 includes a microinstruction sequence
control store (mC) 1920 storing sequences of
.- microinstructions for controlling 3tep by s~ep execution
~:~ of all FU 120 operations. In general, these FU 120
: ,
, . .
,
, ~.,
., . , ~
~ ~ .
/
s ,,.
, .
~, . . .
.
.
,,, , :.
- s~
- ~
L'7~76
--8`::
operations fall into two classes. A first claqs includes
: those microinstruction ~Pquences dlrectly concerned with
~ax~cuting the SOPs of user's programs. Th~ second class
includes microinstruction ~equences concerned with CS
101'8 operating systems~ including and certain automatic,
int~rnal FU 12a functions such as evaluation o~ Name
Table Ent,ries.
:: As previously described, CS 101 is a mul~ciple S-
: Language machine. For example, mC 1920 may contain
microinstruction sequences for executiny user 1 5 SOPS in
at least four different Dialects~ mC 1920 is comprised
. of a writeable control store and sets of microinstruction
sequence for various Dialect~ may be transerred into
and out of mC 1920 as requirecl ~or e~ecution of various
user's programs. By storing set of microinstructlon
.~ sequences for more than one Di.alec~ in mC 1920, it is
~ possibl~ for userls programs t:o be written in a mixture
; of' user languages~ For example, a particular user's
,`............. program may be written primarily in FORTRAN but may call
; 20 certain COBOL routines. These COBOL routines will be
correspondingly translated into COBOL dialect SOPs and
executed by CO~OL ~icrcins~ruction sequences stored in mC
:~ 192~ ~
The instruction stream provided to FU 120 ~rom ME~ ;'.
112 has been previously described with reference to FigO
3~ SOPs and ~ames of this instruction stream are
;. transferred from MOD Bus 140 into IB 1962 as they are
provided from ME~ . IB 1962 includes two 32 bit (one
,,, ~:
. . .
,; .
.
. , . . . ~ .
.. . . . .. : . . .. . . : ~
'.~
-B5-
word) registers. IB 1962 also includes prefQtch
- circuitry for reading ~or SOPs and ~ames of th~
in~truction stream from ~E~ 112 in such a manner that IB
1~62 shall always contain at least one SO~s or Name. ~U
5 120 includes (P) 1964 which reads and se~ara~es, or
parses, SOPs and Names from I~ 1962. As previously
described, P lg64 provides those ~ames to NC 1926, which
accordingly provides logical descriptors to ~T~ 1928 so
as to read the corresponding operands from MEM 112.
SOPs parsed by P 1964 are provided as inputs to Fetch
Unit Dispatc'n Table (FUDT~ 1904 and Execute Unit Dispatch
~ Table ~E~DT) 1965. Re~erring first to FUDT 1904, FUD~
:: 1904 is effe~tively a table ~or translating SOPs to
s~arting addresses in mC 1912 of corresponding
~ 15 microinstruction sequences~ This intermediate
:` translation of SOPs to mC 1912 addresses allows efficient
packing of microinstruction se~uences within mC 1912.
: That is, certain microinstruct:ion sequences may be common
to two or more S-Language DialectsO Such
20 micrcinstructio~ sequenc~s may therefore ~e writt~n into
mC 1912 once and may be re~erred to by differen~ SOPs of
different S-Language Dialects,
E~D~ 1966 perform~ a similar function wi~h respect to
~ ~U 122. As will be described below, EU 122 contai~s a
: 25 mC, similar to mC 1912, which is addres~ed through E~DT
1966 by SOPs specifying EU 122 operations. In addi~ion,
F~ 120 may provide such addresses mC 1912 to initiate EU
122 operations as reqiuired to assisl: certain FU 120
. , , .:
,. - : . ~-
-. ~ , - ;
.
. . .
,
7ll7
:~ -8~-
','
operations. Examples of such operations which may be
:~ requested by FU 120 include calculations required in
evaluating ~ame ~able Entries to provide logical
descriptors to be loaded into NC 1926~
S Associated with both F~DT 1904 and EUDT 1966 are
~ialect (D) registers 1905 and 1967. D registers 1905
: and 1967 store information indicating the particular S-
Language Dialect currently being utilized in egecution of
a user5s program. Outputs of D registers 1905 and 1967
~ lO are u~ilized as part of the address inputs to mC 1912 and
; EU 122's mC~ -
-~ 4. ~
. ~ As previously described, EU 12~ is an arithmetic and
`: logic unit provided to relieve F~ 120 o~ certain
~: 15 arithmetic operations. E~ 122 is capable of performing
addition, subtraction, multiplicationt and di~ision
operations on integer, pac~ed and unpacked decimal, and
~:~ single and double precision floating operands. EU 122 is
':.` . an independently operating mic:rocode controlled machine
;-~ 20 including Microc~de Control (mC) 2010 which, as de~cribed
.~ above, is addressed by EUDT 1966 to initiate EU 122
.: opera ions. mC 2010 also includes logic for handling
i. ' mutual interrupts between F~ 120 and EU 122. Tha~ is, F~
120 may interrupt current E~ 122 operations to call upon
.~ 25 EU 122 to assist an F~ 120 operation. For example, FU 120 :~
may interrupt an arithmetic operation currently being
~- executed by EU 122 to call upon E~ 122 to assist in
generating a logical descriptor from a Name Table Entry.
,,........................................................................ :
,
. :-
.,: . .
~,, :
,' ~'.
.
/,: '. , ' ' ' ' ', ' '
7~ 7
-87-
Similarly, E~ 122 may interrupt current FU 120 operations
when EU 122 requires FU 120 assistance in executing a
current arithmetic operation. For example, EU 122 may
:............... interrupt a current F~ 120 operation if E~ 122 receives
.~ 5 an instruction and operands re~uirlng E~ 122 to per~orm a
:: divide by zero.
: Reerring to Fig. 20, a partial block diagram of E~
122 is shown. EU 122 includes two arithmetic and logic
: units. A first arithmetic and logic unit (MULT) 2014 is
10 utili~ed to perform addition, subtraction,
multiplication, and division operations upon integer and
decimal operands t and upon mantissa fields of single and
double precision floating point operands~ Second ALU
: (EX~) 2016 is utilized to perform operations upon single
and double precision 1Oating point operand exponent
fields in parallel with operations performed upon
i 1Oating point mantissa fields by MULT 2014. Both MULT
~014 and EXP 2016 include an arithmetic and logic unit,
respectively MALU 2074 and EXPALU 2084. MULT 2014 and
EXP 2016 also include register files, respectively MRF
2050 and BRF 2080, which operate and are addressed in
: ~ parallel in a manner similar to AON~RF 1932, OFFGRF 1984
. ` and LEI~GRF 193 6 .
~- Operands or E~ 122 to opera~e upon are provided from
ME~ 112 through MOD sus 140 and are tran-~ferred into
Operand Buffer ~O~B) 2022O In addition to serving as an
. input buffer, OPB 2022 performs certain data format
, . .
,:, ' .: '
'"'' '
,. .
.
, : - ,.
.
. , ,:, :
. :..
~' ; ~, ' ..... ' . ', :
~:~7~
--~8--
' ~
~ manipulation operation~ to transform input operands into
: formats most efflciently operated with by EU 122. In
::~ particular, EU 122 and MUhT 2014 may be designed to
.` op~rate e~iciently with packed decimal operands. OPB
5 2022 may trans~orm unpacked decimal operands into packed
` decimal operands9 Unpacked decimal operands are in the
:~ ~orm of ASCII characters wherein four bits of each
;i characters are binary codes speci~ying 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 ASCII charactersO For ~-
:: example, æone f ield bits may specify whether a particular ``.
~8CII character is a number, a letter~ or punctuation.
~ Packed decimal operands are comprised of a series of ~our
:~ 15 bit field~ wher~in each field contains a binary number
i~ specifying a decimal value of between zero and nine. OPB
, 2022 converts unpacked deGimal to packed decimal operands
:: by ex~racting zone field ~its and packing the four `.
numeric Yalue bits of each character into the four bit ~ ~
20 fields of a packed decimal number. ~ -
E~ 122 is also capable o~ trans~orming the results of
arithmetic operands t for example in packed decimal
format, into unpacked decimal format f or trans~er back to
ME~ 112 or F~ 120O In this case, a packed decimal result
:;
25 appearinq at output o~ MALU 2074 is written into MRF 2050
. through a multiplexer, not shown in Fig~ 20, which
.' transforms the four bit numeric code fields of the packed
, .
:'
::
.
. . .
.
':
. ~,.... .
.'~ .
; . . .. . .
: . - .. . . . . .
. . : . . . - .
: . . . .
,: ~ , . . . ... ,., : ,
. .
,' . ' ~ :
~747~i
; .
., .
. -89-
decimal results into corresponding bit~ of unpacked
decimal operand charactPrs, and forces blanks into the
zone ield bits of those unpacked decimal characters~
The results o this operation are then read from MRF 2050
~ 5 to MAL~ 2074 and zone field bits for those unpacked
.~ decimal characters are read ~rom Constant Store (C5T)
2060 to MAL~ 2074. These inputs from MRF 2050 and CST
2060 are added by MA~U 2074 to generate final result
~:~ outputs in unpacked decimal format. These final results
`~ 10 m~y then be transferred onto JPD Bus 142 through Output
;` Multiplexer (OM) ~024O
Considering first floating point operations, in
~ addition or subtraction of floating paint operands it is
,~ necessary to equalize the values of the floating point
15 operand exponent fields. This is re~erred to as
,`~ prealignment. In floating po:Lnt operations, exponent
fields of the two operands are transferred into EXPAL~
. 2034 aad compared to determine the difference between
~xponent fie~ds~ An output representing difference
20 between exponent field5 is provided from EXPAL~ 2034 to
~; an input of floating point control (~PC) 2002. F~C 2~02
in turn provides control output~ to MAL~ 2074, which has
recei~ed the mantissa fields of the two operands. MAL~
2074, operating under direction of FPC 2002, accordingly
. 25 right or le~t shif~s one operand's mantissa ~ield ~o
. effectively align that operand's exponent field with the
~: other operand's exponent field. Addition or subtraction
of the operand's mantissa fields may then proceed.
,
,. j
~ ,
,; . ,: , , ~ ,.
", :~
~, : .
7'~76~i
-sa-
~ EXPALU 2034 also performs addition or subtraction of
- f loating point operand exponent f ield~ in multiplication
or divisisn operations, while MALU 2074 performs
multiplication and division of the operand mantissa
5 fields. Multiplication and di~Jision of floating point
operarld mantissa fields by MAL~ 2074 is performed by :,
successive shifting of one operand~ corresponding
generation of partial products of the o her operand, and
successive addition and subtraction of those partial
10 products. :
i-, Finally, EU 122 performs normalization of the results
of floating point operand operations by left shifting of
~' a final result's mantissa field to eliminate zeros in the
: most signi~icant characters o~: the f inal result mantissa
15 fieldt and corresponding shift:ing of the final result ;~:~
exponent fields. N~rmalization of floating point
. operation results is controlle!d by FPC 2002. FPC 2002
.:~ examines an unnormalized ~loat:ing point result output of
MAL~ 2074 to detect whi~h, if any, of the most
. ~. 20 5ignif icant characters of that: results contain zeros.
FPC 2002 the~ accordingly provides contrsl outputs to
EXP~ 2034 and MALU 2074 to correspondingly shift the
i, expo~nt and mantissa fields of those result~ so as to
eliminate leading character zeros from the mantissa :~
: 25 fieldO Normalized mantissa and exponent fields of
~loating point results may then be transferred from ~ALU
2074 and EXPAL~ 2034 to J~D Bus 142 through OM 2024.
.
.
.". ~,
.
., :
.
.,,, :
. . , ., ~
':
- . , . ,. , . . . - . .... . : .
.. ..
.
.
: .
~:~'7'~76~
,
,. --91--
As described above, EU 122 also performs addition,
subtraction, multiplication, and division operations on
operandsO In this respect, EU 122 uses a leading æero
detector in ~PC 2002 in efficiently performing
multiplication and division operations. FPC 2002's
leading zPro detector examines the characters or bit5 of
two operands to be multiplied or divided, starting from
the highest, to determine which, if any, con~ain zeros so
as not to require a multiplication or division
operation. FPC 2002 accordingly left shifts the operands
to effectively eliminate those characters or bits, thus
reducing the number of operations to multiply or divide
the operands and accordlngly reducing the time re~uired
to operate upon the operands.
.~` 15 Finally, EU 122 utilizes a uni~ue method, with
a~sociated hard~are, for performing arithmetic operations
on decimal operands by u~ilizi.ng circuitry which is
otherwise conventionally used only to perform operations
upon floa~ing point opera~ds. As described above, ~ULT
2074 is designed to operate wi.th packed decimal operands,
that is ope~ands in the form of consecutive blocks o~
our bits wherein each block of four bit~ contains a
binary code representing numeric values of between zero
and nine. Floating point operands are sim'larly in the
~orm of consecutive blocks of four bits. Each block o~
four bits in a floating point operand, however, contains
a binary number representing a hexadecimal value of
"
;. ;
:
~,.
': , ',,
:
.. . . .
.
,., : , :
/ ,
-92-
between zero and fifteen. As an initial step in
: operating with packed decimal operands, those operands
are loaded, one at a time, into MALU 2074 and, with each
such operand7 a number comprised o~ all hexadecimal sixes
5 is loaded into M~L~ 2074 ~rom CST 2060. This CST 2060
i number is added to each packed decimal operand to ..
effectively convert those packed decimal operands into
: hexadecimal operands wherein the four bi~ blocks contain
numeric values in the range o~ six to fifteen, rather
. 10 than in the original range of æeru to nine. M~LT 2014
then performs arithmetic operation upon tho~e transformed
-. operands, and in doing so detects and saves in~ormation
; regarding which four bit characters of those operands
have resulted in generation of carries durin~ the
15 arithmetic operations. In a final step, the intermediate
:.' result resultlng from completion o those ari~hmetic
~ operations upon those transformed operands are
`~, reconverted to packed decimal format by subtraction of
hexadecimal sixes from those c:haracters for which carries
20 have been ge~erated. Ef~ecti~ely, E~ 122 converts packed
decimal operands i~to "Excess Six~ operand~, per~orms
arithmetic operation~ upon tho~e ~Excess Six" operands,
~' and reconverts "Excess Six~ results of those operations
back into packed decimal format~
1 25 Finally, s previously descibed FU 120 con~rols
,, trans~er of arithmetic results from E~ 122 to MEM 112.
~ In doi~ so, FU 120 generates a logical descriptor
.~ describing the size of ME~ 112 address space, or
:,
.. . .
;":.~., :
. . ,
,~ . .,
:,,,
,.: : ' ' " " ' ' ; , ~' ' : '
~, .' , ' ' ' .
' ' . ~ ' ,, ~ :
, .' "' ~ ,, . ' ' . ' ~ ;; ,' . ~ :
' ~ '' , ' . , "
,' . ' ' , '
, ~
'' '' ~ ' '
7~ 7
-93-
"containern, that result is to be transferred into. In
certain arithmetic opera ions, for example lnteger
operations, an arithme~ic resul~ may be larger than
anticipated and may contain more bits than the MEM 112
5 ncontainernO Container Size Check 5ircuit (CSC) 2052
compares actual size of axithmetic results and L fields
; of MEM 112 "container" logical descriptors. CSC 2052
generates an output i~dicating wheth~r an ~E~ 112
;~ "container" is smaller than an arithmetic result.
`~ lO ~aving briefly described certain features of CS 101
: strllcture and operation in the above overview, these and
other features of CS 101 will be described in ~urther
: detail next below i~ a more detailed introduction of CS
lOl structure and operation. Then, in further ~:
: 15 descriptions, thes~ and other features of CS lOl
structure and operation will be described in depth~
, . . .
. 1. ~e~''
-; A. 5~ L=~_C~_3~d_~5 15
,., a r 9e~5~
Refe~ring to Fig. lOl, a par~ial block diagram of
~:~ Computel System (CS) lOllO is shownc Major elements o~
CS lOllO are Dual Port Memory tMEM) 10112, Job Processor
~: (JP) 10114, Input/Output System (IOS) 10116, and
Diagnostic Processor (DP) 101180 JP lOll4 i~clud~s Fetch
25 ~nit (~) 10120 and Execute ~nit (EU~ 10122.
' '
'; ,
"-
' " . ~ :. . . ' ' ' . , ,
. .
'~ ': . ' ' :' . '
: . .. . .
f ~
7 ~ 6
'
--94--
Referriny firs~ to IOS 10116, IOS 10116 i5interconnected with External Deqices (ED) 10124 through
~nput/Output (I/O) Bus 10126. ED 1012~ may include, for
example, other computer sy~tems, keyboard/display units,
and disc drive memories. IOS 10116 is interconnected
with M~mory Input/Output (~IO) Port 10128 o MEM 10112
~hrough Input/Outpu~ to Memory (~O~) Bus 10130 and Memory
to Input/Output (~IO) Bus 10129, and with FU 10120
through I/O Job Processor (IOJP) Bus 10132
DP 10118 is interconnected with, for example~
external keyboard/CRT Display Unit (DU) 10134 through
Diagnostic Processor Input/Output (DPIO) Bus 10136. DP
10118 is interconnected with IOS 10116, ME~ 10112, FU
10120 r and EU 10122 through Diagnostic Processor (DP) Bus
10138.
Memory to Job Processor (~JP) Port 10140 of ~emory
10112 is interconnec~ed with FU 10120 and EU 10122
through Job Processor Data (Jl?D) Bus 10142. An output of
MJP 10140 is connected to inputs of FU 10120 and EU 10122
through Memory Out~ut Data (MOD) Bus 10144. An output of
FU 1012~ is connected to an input of MJP 1014~ through
Physical Descriptor (P~) Bus 10146. FU 10120 and EU
10122 are interconnected through Fetch/Execute (F/E) Bus
10148.
, .
:............ 25 b. ~ LS ~L~5~D~C~
As will be discussed further below, IOS 10116 and MEM
10112 operate independently under general control of JP
10114 in executing multiple user's programs. In this
,.
,;
,", '
. .
,,
~, . .. . ..
r. ' ' ~ : '
~ ' ' ' ' 1:
-95-
regard, ME~ 10112 is an intelligent, prioritiæing memory
having separate and independent ports MIO 10128 and M~P
10140 to IOS 10116 and JP 10114 respectively. MEM 10112
is the primary path for information trans~er between
5 External Devices 10124 (through IOS 10116) and JP 10114.
`: MEM 10112 thus operates both as a buffer for receiving
and storing various individual user's programs ~e.g.,
data, instruc~ions, and results of program execution) and
: as a main memory for JP 10114.
:~ 10 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 IOS 10116
through I/O Bus 10126 i~ a manner and ormat compatible
with ED 10124. IOS 10116 receives and stores this
15 information, and manipulates the information into ~ormats
suitable for transfer into ~EM 10112. IO5 10116 then
indicates to MEM 10112 that new information is available
: for transfer into MEM 10112. IJpon acknowledgement by ME~
10112, this information is transferred into ~EM 10112
Z0 through IO~ Bus 10130 and ~IO Port 10128. ME~ 1011~
. sto~es the information in selected portions o~ MEM 10112
physical address space. At this time, IOS 10116 notifies
IP 10114 that new information is present in MEM 10112 by
providing a ~semaphore" signal to FU 10120 through IOJP
25 Bus 10132. As will be described further below, CS 10110
manipulates the data and instructions stored in ~E~ 10112
into certain information structures used in executing
user's programs. Among these structures are certain
~::
: , .
.
' '' . .: .
,
, ,
~'7~ ~ 6
-96-
structures, discu~sed further below, which are used by CS
10110 in organizing and controlling flow and execution of
user programs.
F~ 10120 and EU 10122 are independently operating
microcode controlled "machines~ together comp~ising the
CS 10110 micromachine for executing user's programs
~tored in ME~ 10112. Among the principal ~unctions of FU
10120 are: (1) fetching and interpreting instructions
and data from ~EM 10112 for use by FU 10120 and EU
10122; (2~ organizing and controlling flQw of user
programs; (3) initiating E~ 10122 operation~; (4)
performing arithmetic and logic operations on data; (5)
controlling transfer of data from FU 10120 and EU 10122
to MEM 10112; andr (6~ main~aining certain "s~ack" and
~register~ mechanisms, describ~ed below. FU 10120 "cache"
me~-hanisms, also described below, are provided to enhance
the speed o~ operation of JP 10114. These cache
mechanisms are acceleration circuitry including, în part,
hi~h speed memories ~o~ staring copies of selected
inormatlon stored in MEM 10112. The in~ormation stored
;, .
20 in this acceleration circuitry is therefore more rapidly
available to ~P 10114. EU 10122 is an arithmetic unit
capable of executing integer, decimal, or floa~ing point
arithmetic operations. The primary function o_ EU 10122
is to relieve FU 10120 from certain extensive arithmetic
25 operations, thus enhancing the e~ficiency of CS 10110.
:: :
~'
'
.
.
:
.
.: ' , , ' .
,
7 6 ~
.~
-g7-
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 M~
10112 address space~
In ope~ation, FU 10120 reads data and in tructions
~rom ~E~ 1011~ by providing physical addresses to ME~
: 10112 by way of PA Bus 10146 and MJP Port 10140~ The
instru~-tions and data are transerred to FU 10120 and EU
10122 by way of ~JP Port 10140 and MOD Bus 10144.
~: Instructions are interpreted by FU 10120 microcode
`~ clrcuitry, not shown in Fig. 101 but described below" and
when necessary, microcode instructions are prsvided to EU
~; 15 10122 from FU 10120's microcode control by way of F/E Bus
: 10148, or by way of ~PD Bus 101~2.
As stated above, FU 10120 and EU 10122 operate
asynchronously with respect to e~ch other's functionsO A
:~ microinstruction from FU 10120 microcode circuitry to EU
~` 20 10122 may initiate a selected operation of EU 101220 EU
10122 may then proceed to independently execute the
selected operation. FU 10120 may p~oceed to concurrently
' ~ execute cther operations while EU 10122 is completing the
elec~ed arithmetic operation. At co~pletion of the
25 selec~ed arithmetic operation, EU 10122 signals FU 10120
that the op0ration results are available by way of a
handshakeH signal through F/E Bus 10148. FU 10120 may
~,
,, ,
r
f~ '
J
,
" : , ' .
f'.
r :, ~. . '
.. . .
,"' . '' ' .
, 1
` -98-
;. then receive the arithmetic op~ration results for further
. processing or, as di~ussed momentarily, may directly
transfer the arithmetic operation results to ~E~ 10112.
As 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 o~ arithmetic
.~ aperations to be performed by E~ 10122.
Information, such as rasults of executing an
.~ instruction, is wri~ten into ME~ 10112 from FU 10120 or
: 10 EU 10122 by way of JPD Bus 10142. FU 10120 provides a
"physical write address" signal to MEM 10112 by way of PA
Bus 10146 and ~JP Port 10140. Concurrantly, the
information to be written into MEM 10112 is placed on JPD
3us 10142 and is subsequently written into ~EM 1011~ at
.; , lS the locations selected b~ ~hè physical write address.
FU 10120 places a semaphore signal on IOJP Bus 10132
~o signal to IOS 10116 that information, such as the
resul~s of executing a user's programr is available to be
` read out o~ CS 10110, IOS 10116 may then transfer t~e
: 20 information from MEM 10112 to IOS 10116 by way o~ MIO
: Port 10128 and IOM Bus 10130. Information stored in IOS
.~ 10116 is then transferred to ED 10124 through I/O Bus
1012~.
During execution o~ a user's program~ 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 10114 may write a request for
information into MEM 10112 and notify IOS 10116, by way
,:
.
. ~ .
. .
,
. ~ ;
-~
.
. .
~:~7~
_99_
of IOJP Bus 10132, that such a request has been made.
IQS 10116 will then read the request and transfer the
desired information from ED 10124 into ~EM 10112 through
IOS 10116 in the manner described above. In such
5 operations, IOS 10116 an~ JP 10114 operate together as a
~ memory manager wherein the memory space addressable by JP
-. 10114 is termed virtual memory space, and includes both
E~ 10112 memory space and all external devices to which
: IOS 10116 has access.
.~
As previously described, DP 10118 provides a second
interace 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 functions which are conventionally
-: 15 provided by a hard (i.e~, switches and lights) console~
: For example, DP 1011~ allows DU 10134 to exercise control
of Computer System 10110 for ~Juch purposes a~ system
initializa~ion and start up, execution of diagnostic
pxocesses~ and fault monitoring and identification. DP ~:
: 2C 10118 has read and write acce~s to most memory and
~ register portions within each of IOS 10116, ME~ 10112, F~
,;. 10120, and EU 10122 by way of DP Bus 10138. ~emories and
~ registers in CS 10110 can therefore be directly loaded or
: initialized during system start up, and can be directly
25 read or loaded with test and diagnostic signals for fault
monitoring and identi~ication. In addition, as described
~ , ,,
,, ~ ,.
. ~`
,
" . .
, , .
, ,,
.. . . . . . .
::, , ,, , :
:. : , . .
.
, . .
-100--
further below, microinstructions may be loaded into JP
10114's microcode circuitry at system start up or as
: requiredO
~av~ng described the genaral struc~urè a~d opera~ion
.: 5 of Computer System 10110, certain features of Computer
System 10110 will next be briefly described to aid in
understanding khe following, more detailed descriptions
of these and other features of Computer System 10110.
. ~ c . ~:~
Certain terms are used relating to the structure and
operation of CS 10110 throughout the following
discussions. Certain of these terms will be discussed
and deined first, to aid in understandi~g the following
. descriptions~ Other terms will be introduced in the
-~. 15 following descriptions as required,
; A ~lS~a~g is a sequence of operational steps, or
instructions, to be executed to perform some operation.
A procedure may include data to be operated upon in
performing the operationO
20 A ~3~m i~ a static group of one or more
procedures. In general, programs may be classified as
user programs, utility programs, and operating system
~: programs. A user program is a group of procedures
genPrated by and priYate to one particular user o~ a
25 group of u~ers interfacing 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
'
''
.. v . - - ~
.
..
.
, . : : .
;' . :'~ .
~7~7~i~
-101--
program~ Opera~ing system programs are groups of
procedures internal to CS 10110 for allocation and
control o~ CS 10110 resources. Operating ~ystem programs
also define inter~ace~ within CS lOllOo For example, as
will be discussed further below all operands in a program
. are referred to by nNA~E". ~n operating system program
: translates operand NAME into the physical locations of
the operands in MEM 10112~ The NA~E translation program
thus defines ~he interface between operand NAME (name
space addresses) and MEM 10112 physical addresses.
A ~¢~g~a~ is an independent locus of control pa~ing
through physical, logical or virtual address spaces, or,
more particularly, a path of execution through a series
:~ of programs (i.e., procedures)O A process wlll generally :-
~ 15 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 Qkig~ is a uniquely identifiable portion of "data
:~ space" acce~sible to CS 10110. An object may be regarded
20 as a container for inormation and may contain data or
:~ procedure information or both. An object may contain for
example, an entire program, 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
~ 25 in~orma~ion containPd in an obje~t need not be
;~ contiguously located ln that object.
~'''
.:, ., , ~.
., ,
::, . .. .
: ... :
. .
. . . , .: : ~: :
766
-ln2-
.
: A ~Qm~l~ is a state of operation of CS 10110 for the
; purposes of CS l0ll0's pro~ection mechanisms~ Each
domain is defined by a set of procedures having access to
;- objects within that domain for their execu~ion. ~ach
object has a single domain of execution in which it is
executed if it is a procedure object, or used, if it is a
data object. CS l0ll0 is said to be operating in a
particular domain if it is executing a procedure having
that domain of execution. Each object may belong to one
10 or more domains; an o~ject belongs to a domain if a
procedure executing in that domain has potential access
:: to the object. CS l0ll0 may, for example have four
-domains: User domain, Data Base Management System (DBMS~
; domain, Extended Operating System (EOS) domain~ and
15 Rernel Operating 5ystem (ROS) domain. User domain is the
: domain of execution of all user pro~ided procedures, such
as user or utility procedures~ D~MS do~ain i5 the domain
~- of execution for operating system procedures for storing,
retrieving~ and handling data. EOS domain is the domain
; 20 of execution of ope ating system procedures defining and
orming the user level interface with CS l0ll0, such as
. 1 procedures for controlling an executiny files, processes,
~ and I/O operations. KOS domain is the domain of
; execution of the low level, secure operating system which
25 manages and controls CS l0ll0's physical resources.
Other embodiments of CS l0ll0 may have fewer or more
domains than those just describedO For example, DBMS
procedures may be incorporated into the EOS domain or EOS
, ~
.
~: .
. ~:
"
f ~ . , . . ' ', ': : . -
. ' ' . . ' . .
~."'
','; ~ ' . ' . , . ~ ; . '.
: ' .' ~ ' :-
,' ~ f ' ~'"
-103-
domain may be divided by incorporating the I/O procedures
into an I/O domain. There is no hardware enforcad
limitation on the number of, of boundaries between,
domains in CS lOllO. Certain CS lOllO hardware functions
and structures are, however, dependent upon domains~
:A ~ is definedr for purposes of CS lOllO's
protection mechanism~, as a combination of the cuxrent
principle ~user), the current process being executed, and
the domain the process is currently being execu~ed in.
:10 In addition to principle, process, and domain, which are
identiied by UIDs, ~ubject may include a Tag, which is a
user assigned identification code used where added
security is required. For a given proces~, principle and
process are constant but the domain is determined by the
procedure currently being executed~ A proc ss's
associated subject is therefore variable along the path
of execution of the procPss.
Having discussed and defined the above terms~ certain
~features of CS lOllO will next be brie~ly ~escribed.
: 2~ d. ~b~l_=i3~zL-~=9~ b~
CS lOllO is capable of concurrently executing two or
more progr~ms and selecting the sequence of execution of
programs to make most ~fective use of CS lOllO's
' resourcesO This i~ referred to a~ multiprogramming~ In
::25 this regard, CS lOllO may temporarily suspend execution
of one program, for example wh n a resource or certain
in~ormation required for that program is not immediately
available, and proceed to execute another pro~ram until
.,
''.'~
.
.
'
' ' ' .
'' ' ~ "` `.' ' "'~ '
7~.~7
-104~
the required resource or inor~ation becomes available.
For example, particular information required by a first
program may not be available in ME~ 10112 when called
for. JP 10114 may, as discussed further below, suspend
execution o the firs~ program~ transfer a request for
tha~ information to IOS 10116, and proceed to call and
execute a second program. IOS 10116 would fetch the
re~uested information from ~D 10124 and transfer it into
ME~ 10112c At some time after IOS 10116 notifies JP
10 10114 that the requested information is available in MEM
10112, JP 10114 could suspend e~ecution of the second
program and resume execution of the firs~ program.
e- ~L~ uuu~D~ e~ nn
As previously descxibed, 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 conqentional computer system, each user level
. language has a corresponding machine language,
20 classically defined as an assembly lanyuage. 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 generali two or three
~;~ S-Language instruction~, referred to as SI~-q. Certain
25 SINs may be shared by two or more high level u~er
- ~ languages. CS 10110, as further described in following
discussions, provides a set, or dialect, of microcode
:: instructions (S Interpreters) for each S-Language. S-
Interpreters interpret SINs and provide corresponding
:' ~
,''' .
: .
.
"' ~
" ; ' ; ' ~
',' ' . I . '
~'' . . ' '
:
:' :
rL~
~7'~ 6
~105-
.
sequences of microin~tructions for detailed co~trol of CS
lQ110~ CS 10110's instruction set and operation may
therefore be tailored to each user'~ program, regardle~s
of the particular user language, so as to most
eficiently execute the user's programO Computer System
10110 may, for example, execute peograms in both FORTRAN
and COBOL with comparable efficiency. In addition, a
user may write a program in more than one high level user
languaye without loss of efficiency~ For example, a user
may write a portion of his program in CO~OL, but may wish
to write certain portions in FORTRAN. In such cases, the
COBOh portions would be compiled into COBOL SINs and
: executed with the COBO~ dialect S-Interpreter. The
FORTRAN portions would be compi~ed into FORTRAN SINs and
executed with a FORTRAN dialect S-Interpreter. The
present embodiment of CS 10110 utilizes a uniform format
:. for all SINs. This feature allows simpler S-Interpreter
. structures and increases efficiency of SI~ interpre~ation
:: because it is not necessary to provide means for
in~erpreting each dialect individually.
f, ~b ~ LJi~
Each object created for use in, or by oper~tion of, a
CS lQ110 is permanently assigned a Unique Xdenti~ier
.: (UID~. An objectls UID allows that object to be uniquely
identified and located at any tima, regardless of which
25 particular CS 10110 it was created by or for or where it
is suhsequently located. Thus each time a new obje~t is
defined, a new and unique ~ID is allocated, much as
,
..
,. ' ; , ~ ',~, , , ' ''; , ~
j ~ , i ,, .
7 ~ 6
106-
social security numbers are allocated to individuals. A
particular piece of information con~ained in an object
m y be located by a loglcal address comprising the
object's ~ID, an off~et from he start of the object of
the first bit of the segment, and the length (number of
bits) of the information segment. ~ata within an object
may therefore be addressed on a bit granular basis. As
will be described further in following discussions, UID's
are used within a CS 10110 as logical addresses, and, ~or
example, as pointers. Logically, all addresses and
: pointers in CS 10110 are UID addresses and pointers. As
pre~iously described and as described below, however,
short, temporary 'lnique identi~iers, valid only within 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 object becomes active in CS 10110 when it is
transferred from backing store CED 10124 to MEM 10112 for
: use in executing a procecs. At this time, each such
- 20 object is assigned an Acti~e Object Number ~ON). AONS
are short unique identifiers and are related to the
object's UIDs through certain CS 10110 information
~ structures described below. AONs are used only within JP
:;. 10114 and are used in JP 10114, in place of ~IDs, to
reduce the required width of JP 10114's address buses and
~; the amount of address data handled in ~P 10114. As with
UID logical addresses, a piece of data in an object may
.' be addressed through a bit granular AON logical address
comprising the object's AOM, an of~set from the start of
. : .
.. ' .
;
: . . . - . . . .
. ~ , .
; .,'.
.
.
~7~766
:: -1 07 -
the object of the first bit of the piece, and the length
of the piece.
~ The transfer of logical addresses, for example
:~ pointers, between ME~ 10112 (UIDA) and JP 10114 (AONs)
5 during execution of a process requires t~anslations
; between UIDs and AONs. 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 ME~ 10112, to physically access information
: stored in M~ 10112, is accomplish~d through CS 10110
~ information structures rela~ing AOM logical addresses to
.~ MEM 1011~ physical addresses.
~ach operand appearing in a program is assigned a
:~. 15 Name when the program i5 compiled. Thereafter, all
.. references to the operands are through their assigned
.~ Names. As will be described i.n detail in a later
discussion, CS lOllO's addres,ing structure includes a
mechanism fsr recogniæing Name~ as they appear in an
~ 20 ins~ruction s~ream and ~ame Tables containing directions
.: for resolving Names to AON logical addresses. AON
; lo~ical addresses may then be evaluated, for example
~` translated into a ME~ 10112 phy ical address, to provide
ac~ual operands~ The use of ~ames to identify operands
. ~5 in the instructions stream (process) (1) allows a
.:.1 complicated address to be replaced by a simple reference
of uniform format; ~2) does not require that an ;~
! ~ operation be directly de~ined by data type in the
' in~truction stream; (3) allows repeated references to an
!,' 30 operand tb be made in an instruction stream by merely
,
",, - ' ' ' .
,, ~ .
.
~: - . . .
. . . . . . : . .. ..
~. ', , ' ', ' : ' ' """'' ' . `. ' . ,.' '
~. ' ' , ' ' '" ' ' ,; . , ,. " ' ' ' , ' ' '; , ' .` '
' ' , , : '' . ~ ' .
," ' ' ~ ' ' ' " "` " ' " ; ,` " ;'
.
.. ..
7'~7 ~ 6
-108-
repeating the operand's Name; and, (4) allows partially
completed Name to address translations ~o he stored in a
cache to speed up operand references. The use of Names
th~re~y sub~tantially reduces the volume of information
5 required in the instruction stream for operand references
and increases CS 10110 speed and efficiency by performing
operands references through a parallel operating,
underlying mechanism.
Finally, CS 10110 address struc~ure incorporates a
10 set of Architectural Ba~e Pointers (ABPs~ for each
process. ABPs provide an addressing framework to locate
~; data and procedure information belonging to a process and
are used, ~or example, in resolving Names to AO~ logical
addresses.
15g. ~5~t~ YeC~L~$L
~ CS lOllO's protection mechanism is constructed to
; prevent a user ~rom (1) gaining access to or disrupting
another user's process, including data, and (2)
inter~ering with or otherwise subverting the operation of
; 20 CS 10110. Access rights to each particular active object
"~ are dynamically granted as a function o~ the currently
i` ac~ive ~ub~ect. A subject is de~ined by a combination of
- the current principle (user), the current proces~ belng
executed, and the domain in which the process is
currently beins executed. In addition 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
- . ~ :
.~'f ~
~`7~L76~ -
-lo~
and process are constant but the domain is de~ermined by
the procedure currently bein~ executed. A process1s
associated subject is therefore variable along the path
of execution of the process.
In a pre~ent embodiment of CS 10110, procedures
having ROS domain of execution have access to objects in
ROS, EOS, DBMS, and User domains; procedures having EOS
domain of execution have access to objects in EOS, D~S,
and User domains; procedures having DBMS domain of
execution have access to objects in DB~S and User
domains; and procedures havins User domain of execution
hav~ access only to objects in Uqer domain. A user
cannot, therefore, obtain access to objects in ~OS domain
of execution and cannot influence CS 10110's low levelt
secure op~rating system. The user's process may,
however, call for execution a procedure havin~ KOS domain
; of execution. At this point the process's subject is in
the ROS domain and the procedure will have access to
certain objects in ROS domain.
In a present embodiment of CS 10110, 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) or each subject having access to
that object. AC~æ specify, or each ubject, access
25 rights a subject has with regard to that object.
There is normally no relationship, other than that
defined by an object's ACL~ between subjects and
objects. CS 10110, however, supports Extended Type
, :-
. :
. ' .
~,' , :
.. . .
.,:
~ " ~
:, , . ~ . . .
r~
-
~.~.7~7~
-110--
9bjects having Extended ACLs wherein a user may
specifically define which subjects have what access
rights to the object.
In another embodiment of CS lOllO, described in a
5 following discussion, access rights are granted on a
dynamic basis. In execu~ing a process, a procedure may
call a second procedure and pas~ an argument to the
called procedurP. The calling procedure will also pass
selected access rights to that argument to the called
10 procedure. The passed access rights exist only for ~he
~: duration of the call.
In the dynamic access embodiment, access rights are
granted only at the tima they are required. In the ACL
.; embodiment, access rights are gran~ed upon object
~`: 15 creation or upon specific request. In either embodiment,
a each procedure to which arguments may be passed in a
;~ cross-domain call has associated with it an Access
~: Information Array (AIA). A procedurels AIA states what
:- access rights a calling procedure (subject) must have
20 before the called procedure can operate on the passed
. argument. CS lOllO's protection mechanisms compare the
~: calling procedure's access rights to the rights required
:~ by the called procedure. This ensures that a calling
procedure may not ask a called procedure to do what the
; 25 calling procedure i~ not allowed to do. Effectively, a
.` calling procedure can pass to a called procedure only the
access rights held by the calling procedure.
''',
" '
, ' ~ .
'.:
f ,~
'
~' ' ,
, ' '
~ . . .
7~ ~
- ~aving described the general structure and operation
: and certain features of CS 10110, those and other
~eatures o~ CS 10110 operation will next be described ln
: greater detail.
B.
~: CS 10110 conta~ns certain information ~tructures and
mechanisms to assis~ in efflcie~t execution of
proces~es, 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 objects comprising a user's process or
: dir~ctly related to execution of a user's process. The
~econd ~ype are ~or mana~ement, control, and execution of
~`~ lS pro~esses. These structures are generally sh~red by all
processes active in CS 10110. The third type are C5 ;-
10110 micromachine information structures and
~ mechanismsO These structures are concerned with the
- eternal operation o~ the CS 10110 micromachine and are
: 20 private ~o ~he CS 10110 micro-machine.
: a~ 5~ ig~
Referring to Flg. 102, a pictorial representation of
CS 10110 (MEM 10112, FU 10120, and EU 10122) is shown .
- . with certain information structures and mechani~ms
. .
25 depicted therein, Xt should be unders~ood that these
information structures and mechanisms transcend or "cut
.: across~ the boundaries between ~EM 10112, FU 10120, EU
. 10122, and IO~ 10116. Re~erring to the upper portion of
:: Fig. 103 Proces~ Structures 10210 contains those
'' ' ', .:
: .
:,,
:: . , , . : , . ;
" .
.. ~ : . . :. . .
. . . , .:
--112-~
inormation structures and mechanisms most closely
concerned with individual processes, the fir~t and third
types of information structures described above. Process
Struc ures 10210 reside in MEPI 10112 and Virtual
S Processes 10212 include Virtual Processes (VP3 1 through
N. Virtual Processes 10212 may contain, in a present
embodiment o~ CS 10110, up to 2S6 VP's. As previously
described, each V~ includes certain objects particular to
a single user's process, or example stack objects
~; 10 previous1y described and fur her described in a following
~ description. Each VP also includes a Process Objec~
;~ containing certain information required to execute the
prooess, for example pointer~ to other proce~s
; information~
~: 15 Virtual Processor S~ate Blocks (VPSBs) 1021B include
VPSBs containing certain table~ and mechanisms for
managing execution of VPs selected for execution by CS
. .
:: 10110.
A particular VP is bound into CS 10110 when a Virtual
20 Process Dispatcher, described in a following discussion
~lects that VP as eligible for execution. The selected
VPs Proc~SS abject, as previously described, is swapped
into a VPSB. VPSBs 10218 may contain, for example 16 or
. 32 State Blocks so that CS 10110 may concurrently execute
~, 25 u~ to 16 or 32 VPs. When a VP asæigned to a VPSB is to
be executed, the VP is swapped onto the information
struc~ures and mechanisms shown in F~ 10120 and E~
10122. FU Register and Stack ~echanism (FURS~) 10214 and
EU Regis~er and Stack ~echanism (EURSM) 10216, shown
,
:
...~
~,',' ' ~ ', :' ,
.. . . .
, ' ' ' , ' ' .: .'
,.
~:~7~7
-11 3--
respectively in FU 10120 and EU 10122, comprise regi~ter
and stack mechanlsms used in execution of VP~ bound to CS
: 10110. These register and stack ~echanlsms, as will be
discussed below, are al50 used for certain CS 10110
5 proce~s mana~ement ~unctions. Procedure Objects (POs~
10213 contain~ Procedure Objects (POs) 1 to N of the
processes executing in CS 10110.
Addressing Mechanisms (AM) 10220 are a part o~ CS
10110's process management system and are generally
10 associated wi~h Compu~er System 10110 addressing
functions as described in following discussions. UID/AON
Tables 10222 is a structure for relating UIDIs and AON's,
:~ previously discussed. Memory Management Tables 10224
:~ includes structures or (1~ relating AO~ logical
- 15 addresses and MEM 10112 physical addresses; (~) managing
MEM 10112's physical address space; (3) managing
transfer of inormation between MEM 10112 and CS 10110's
backing store (ED 10124) and, (4) activating objects
into CS 10110; Name Cache (~C) 10226 and Address
20 Translation Cache (ATC) 10228 are acceleration,mechanisms
; ~or storing addressing information relating to the VP
currently bound to CS 10110. NC 10226, described further ~:
below, contains inf ormation relating operand Names to AON
addresses~ ATC 102~8, also discussed furth~r below,
25 contains information xelating AON addresses to ME~ 10112
physical addresses~
.~,
'' ' :'
... .
. .. .
. ,. , ~
~ ' ' '
.
.':' .
.
~'L7~t~
-11 4-
Protection Mechanisms 10230, depicted below AM 10220,
include Protection Tables 10~32 and Protection Cache (PC)
: 10234. Protec~ion Tables 10~32 contain information
~:; regarding access rights to each objec~ active in CS
', 5 10110. PC 10234 contains protection information relating
~o c~rtain objPcts of the VP currently bound to CS 10110.
Microinstruction Mechanisms 10236, depic~ed below PM
10230, includes Micro-code (M Code? Store 10238, FU
(Micro-code) M Code Structure 10240, and EU Micro-cod~ (M
10 Code) Structure 10242. These struc~ures contain
microinstruction mechanisms and tables for interpreting
. ~
S~Ns and controlling the detailed operation of CS 10110.
Micro-instruction Mechanisms 10232 also provide microcode
tables and mechanisms usedl in part, in operation of the
. ; .
~, 15 low level, secure operating system that manages and
` controls CS lOllO's physical resources.
. Having thus briefly descri:bed certain CS 10110
. .; .
information structures and mechanisms with the aid of
~ig. 102, those information structures and mechanisms
will next be described in further de~ail in the order
mentioned above. In these descriptions it should be
noted that, in representation of MEM 10112 shown in Fig.
102 and in other fi~ures o~ following discussions, the
addressable memory space of MEM 10112 is depicte~.
Cer~ain portions of MEM 10112 address space have b~en
designated as containing certain information structures
and mechanisms. These stru~tures and mechanisms have
real physical existence in ME~ 10112, but may vary in
both location and vslume of MEM 10112 address space they
, .
^:: 30 occupy. Assigning position o a single, large memory to
,
,: ,
,
, .
~''' , ~
,
~, , , :, :'
, :' ' ` '`, ~ .
,. . :
7'
~__ "1 f~ ..D.I~
1 17L,~76~
~115~
contain these structures and mechanisms allows these
structures and mechanisms to be reconfigured as required
~ for most efficient operation of CS 10110. In an
: alternate embodiment, phy~ically separate memories may be
5 us~d to contain the structures and mechanisms depic~ed in
MEM 10112? rather than assigned portions of a single
~: memory.
b.
~eferring to Fig. 103, a partial schematic
representation of Process Structures 10210 is shown.
: Specifically,. Fig. 103 shows a Proce~s (P) 10310 selected
: for execution, and its associated Procedure Objects (POs)
in Process Objects (POs) 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
cla~ity of presentation, EURS~ 10216 is not shown as
20 E~RSM 10216 is similar to FURSM 10214. EURSN 10216 will -
be described in detail in the followiny detailed
idiscussons of CS 10110's structure and operation.
As previou~ly discussed, each process includes
certain data and procedure object. As represen~ed in
~-`25 Fig. 103 for P 10310 the procedure objects reside in POs
10213. The data objerts include Static Data ~reas and
stack mechanism~ in P 10310. POs, for example ROS
. , ~ .
: Procedure Object (ROSPO) 10318, contain the various
. .
.~ .
.'`:, '
;' :; "; .
,
5 i
., ^: ' ` ' ~.
'. ' :~ ' ~ ' ''
:' ` ' ~ ' ' ,i ' ; ~.,
:'` ' ': ' ' '. . '. : '
' ' . , ,` ~ :
:, ' ' ' :' .: .
I
. .
'. : '
, G'~,
~3~'7~76~
procedures of the process, each procedure being a
sequence of SINs defining an operation to be performed in
executing the process~ As will be described below,
Procedure Objects also contain certain information used
.~ 5 in executing the procedures contained therei~. Static
;~ Data ~reas (SDAs) are data objects generally reserved for
storing data having an existence for the duration of the
process. P 10310's stack mechanisms allow stacking o~
: procedures for procedure calls and returns and for
10 swapping p~ocesses in and out of JP 10114l Macro-Stacks
(~AS) 10328 to 10334 are generally used to store
~ automatic data (data generated durlng execution of a
-~ procedure and having an exi~tence for the duration of
that procedure), Although shown as separate from the
15 stacks in P 10310, the SD~s may be contained with MASs
10328 to 1033~. Secure Stack (SS) 10336 stores, in
general, CS 1-0110 micro-machine state for each procedure
: called. Information stored in SS 10336 allow~ machine
state to be recovered upon ret:urn from a called
20 procedure, or when binding tswapping) a VP into CS 10110.
.~ As ~hown in P 10310, each proces is structured on a
domain basic. ~ P ln31~ may therefore inclu~e, for each
domain, one or more procedure objects containing
procedures having that domain as their domain of
25 execution, an SDA and an MASo For example, KOS domain of
P 10310 includes ROSPO 10318, ROSSDA 10326, and ROSMAS
:: 10334. P 10310's SS 10336 does not reside in any single
:~ domain of P 10310, but instead is a stac~ mechanism
: belonging to CS 10110 micromachine.
, .~, .
~.'~`, .. .
~ , .,
,: ~
, ~ .
.
, . . ... .. . .
': - ' , ~ ' ' ': : .
:.
_
: ~L7L'~7~
-~17 :~
~ aving described the overall structure o~ a P 10310,
the individual information structu~es and mechanisms of a
P 10310 will next be described in greater detail.
ROSPO 10318 is typical of CS 10110 procedure objects
and will be referxed to for illustr~tion in the following :~ :
discussion~ ~ajor components of KOSPO 10318 are ~eader
10338, External Entry Descripter (EED) Area 10340,
: Internal Entry Descripter 5IED) Area 10342, S-Op Code
10 Area 1034~, Procedure Environment Descripter (PED) 10348, ~ -
:Name Table (NT) 10350, and Access In~ormation Array (AIA) :
.. Area 10352.
~ead~r 10338 contains certain information identifying :~
: PO 10318 and indicating the number of entries in EED area
15 10340, discussed momentarily. ~: -
lEED area 10340 and IED area 10342 together con~ain an
:.`Entry Descripter (ED) for each procedure in KOSPO 10318.
ROSPO 10318 is represented as containing Procedures 1, 2,
`~and 11, o which Procedure 11 will be used as an example
..20 in the present discussion. E~s ef~ectively comprise an
i,lndex through certain all information in ROSPO 10318 can
be locatedO IEDs form an index to all ROSPO 10318
procedure~ which may be ~alled only from other procedures
contained in ROSPO 10318. EEDs form an index ~o all
~ 25 ~OSPO 10318 procedures which may be called by procedures :~
..external to ROSPO 10318. Externally callable procedures
,:
'5 '
. ~ ., .
' . . '.,, ' ' ' ' ,', ' , ~ :
, ~ , , , , ' , - ' ' ' , :
' ' ~' ' ' . , ' .. ,, ' :
., -
- ,' , . :' ' '" '
76~
.:
, . . .
: are distinguished aid, as described in a following
discussion of CS 10110's protection mechanisms, in
confirming external calling proc~dure's access rights.
Referring to ED 11, ED for procedure 11, three ~ields
5 are shown ~herein. Procedure Environment ~e~cripter
Offs~t (P~DO) field indicates the s~art, relative to
start of KOSPO 10318, of Procedure ll's PED in PED Area
10348~ As will be discussed further below~ a procedure's
P~D contains a set of pointers for locating information
10 used in the execution of that procedure. PED Area 10348
contains a PED ~or 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
~ 15 Pointer (PBP) which will be discussed below, of Procedure
;~ 11's SIN Code and SI~ Code Area 10344. Finally, ED 11'~
Initial Frame Size (IFS) field indicates the required
Initial Frame Size of the ROSMAS 10334 frame storing
Procedure ll's automatic data.
~ 20 P~D 11, Procedure ll's PED in PED Area 10348,
: contains a set of pointers for locating in~ormation used
in execution of Procedure 11. The first entry in PED 11
is a header containing inform~tion identifying PED 11.
PED 11 ' s Procedu~e Base Pointer (PBP~ entry is a polnter
- 25 providing a fixed referen~e from which other information
in PO 10318 may be located . In a specif ic example,
Procedure 1115 CEP indicates the location, relative to
'
.: i
' :
.,
."
.
'~ .
.
.
~7~
--llg--
~BPr of the start of Procedure ll's S~Op code in S-Op
Code Area 10344. As will be described further below, PBP
ic a CS 10110 Architec~ural Base Pointer ~ABP). CS
10110'~ ABP's are a set of archltectural poin~ers used in
5 CS 10110 to facilitate addressing of CS 10110's address
~ ~pace. PED ll's Static Data ~ointer (SDP) entry points
:~ to data, in PO 10318, specifying certain parameters of P
: 10310's KOSSDA 10326. ~ame Table Pointer (NTP~ entry is
a pointer indicating the location, in NT 10350, of Name
10 Table Entry'~ (NTE's) for Procedure 11 's operands. NT :
~ 10350 and NTEIs will be described in greater detail in
:~ the following discussion of Computer System 10110's
.. ,.,. ~ :
`,. Addressing Structure. P~D ll's S-Interpreter Pointer
: ~SIP) entry is a pointer, discussed in grea~er detail in
i 15 a following discussion of CS 10110's microcode structure, :~
.. pointing to the particular S-Interpeter (SINT) to be used
.' in interpceting Procedure ll's SIN Code.
Referring finally to AIA 1.0352, AIA 10352 contains,
~, as previously discussed, information pertaining to access
j 20 rights requixed of any external procedure calling a 10318
i procedure. There is an AIA 10352 entry for each Po 10318
i~ procedure which may be called by an external procedure~
A particular AXA entry may be shared by one or more
procedures having an ED in EED Area 10340. Each EED
.~: 25 contains cer~ain information, not shown for clarity of
;, presenta'cion, indicating that that procedure's
'"' ''I
j; ,,
. .
,
.- . .
.
, --, . .
~ .
- :-
.:' ~, ,; .
,': ' .
,, .
~............... . . . . .
:. . - .,, : . ,
: . .. .
, . . .
, . ' ' , : ::: .
,' ~ ' ' , , '
~" , ",
,
7 ~
120-
corresponding AIA entry must be referred to, and the
; calling procedure's access rights confirmed, whenever
; that procedure i5 called~
; 2. ~
As previously described, ~ 10310's stack mechanisms
include SS 10336, used in part for s~oring machine state,
and ~AS's 10328-to 10334, used to store local data
generated during exeGution of P 10310's procedures. P
10310 is represented as containing an MAS for each CS
~: 10 10110 do~ain. In an alternate embodiment of CS 10110, a
particular P 10310 will include ~AS'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 :-
:~ 15 calls. Procedure 0 has called Procedure 1, Procedure 1
has called Procedure 2, and so on. Each time a procedure
.~ is called, a corresponding stack frame is constructed on
;~. the MAS of the domain in which the called procedure is
executed. For example, Procedures 1, 2, and 11 execute
1 20 i~ ~OS domain; M~S ~rames for Procedures 1, 2, and 11
.. there~ore are placed on ROS~S 10334. Similarly,
PEocedure~ 3 and 9 execute in EOS domain, so that their
stack frames are placed on EOSMAS 1033~. Procedures 5
~ and 6 execute in D8~S domain, so that ~heir stack frames
.~ 25 are placed on DBMSMAS 10330. Procedures 4, 7, 8, and 10
execute in User domain wi~h their stack frames being
::~ placed on ~5ER~AS 10328. Procedure 11 is the most
'"' ~,:
... .
,'~ ...
, .,
.. ~
:: . . ..
:, . , ~ . , . : .
.: , ~. . . .
' , ' ' ,
~, .
~'7'?~7~6
;
recently called procedure and procedure ll's s~ack frame
on ROS~AS 10334 i~ referred to as the curxent frame~
Procedure 11 i~ the procedure which is currently being
: executed when ~P 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 ~AS, for example KOSMAS 10334, is shown.
; ROSMAS 1033~ includes Stack ~eàder 104la and a Frame
10412 for each procedure on KOSMAS 10334. ~ach Frame
.~ 10412 includes a Fr me ~eade~ 10414, and may contain a
'~ Linkage Pointer ~lock 10416, a Local Pointer Block 10418,
.
15 and a Local (Automatic) Data E~lock 10420.
~OSMAS 10334 Stack ~eader 10410 contains at least the
;~' following informa~ion:
' 1 (1) an offset, relative t:o Stac~ ~eader 10410,
indicati~g the location of Frame ~eader 10414 of the
.~ 20 fir~t frame on ROS~AS 10334;
. (2) a S~ac~ Top O~set (STO) indicating location,
.~ relativg to start of ROSMAS 10334, o~ the top of RO~MA~
~ 10334; top of ROSM~S 10334 is indicated by pointer STO
: pointing to the top of the last entry of Procedure 11
: 25 ~ame 10412ls Local Da~a Block 10420;
--: (3) an offset, relative to start of ROSMAS 10334,
,. ~
indicating location of Frame ~eader 10414 of the current
:- top frame of ~OSMAS 10334; in Fig. 104 this sffset is
'' '
'. .,~
t' .
' . ' , :
,, '
t ' ' ' ' ' '' ''" ' , ' '
,
, , , , ' ', ,
"',
' ,
~i ~
'fi~
2~-
represented by ~rame Pointer (FP), an ~BP discussed
further below;
(4) the VP 10310's UID;
(5) a UID pointer indicating location of certain
domain environment information, described further in a
following discussion;
(6) a signaller pointer indicating the location of
certain ro~l~ines for handling certaln CS 10110 operating
system faults;
.~
(7) a UI~ pointer indicating location of ROSSDA ~`
~; 10326; and
.
: (8) a frame label sequencer containing pointers to
:~ headers of frames in other domains; theqe pointers are
used in executing non-local go~to operations.
1 15 ROSMA5 10334 Stack ~eader 10410 thereby contains
`-: information for locating certiain important points in
:~ ROSMAS 10334's structure, and for locating certain
information pertinent to executing ~rocedures in ROS
domain.
~ach Frame ~eader 10414 contains at least the
. following info~mation:
1) of~sets, relative to the Frame ~eader 10414,
:~ indicating the location~ of Frame ~eader~ 10414 of the
previous and next frames of ROSMAS 10334,
.~. 25 (2) an o~fset, relative to the Frame Header 10414,
indicating the location of the top of that Frame 10412;
.: i (3) information indicating the number of passed
,,
arguments co~tained in that Frame 10412;
' '
: ,
;. '~
;
,
~'''
,. . .. . . . .
,~
s ~ .
.
. --
7 6 6
-123-
(41 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/Offset pointer to th environmental
: 5 descripter of the procedure calling that procedure~
~6) a ~rame label sequence containing infoxmation
~ indicating the locations of other Frame Headers 10414 in
.:~ ROSMAS 10334; this information is used to locate other
frames in ~OSMAS 10334 ~or the purpose of executing local
;~- l0 go~to operations. ~rame ~eaders 10414 thereby contain
information for locating certain important points in
.~ KOSMA5 10334 s~ructure, and certain data pertinent to
:. executing the a~sociated procedures. In addition, Frame
~aders 10414, in combination with Stack Header 10410,
: 15 contain information for linking the activation records of
each VP 10310 MAS, and for linking toyether the
activation records o the individual MAS's~
Linkage ~ointer Blocks 10416 contain pointers to
. arguments passed ~rom a calling procedure to the called
20 procedure. ~or example, Linkage Pointer Block 10416 of
:~ Procedure ll's Frame 10412 will contain pointers to
arguments passed to Procedure ll from Procedure 10. The
use of linkage pointers in CS 10110's addressing
structure will be discussed ~ur~her in a foliowing
25 discussion of CS 10110's Addressins Structure. Local
Data Pointer Blocks 1041B contain pointers to certain of
~he associa~ed procedure's local data. Indicated in Fig.
104 is a pointer, Frame Pointer (FP), pointing between
: ` :
:'
, ~ , ,
.. ... .
:~ , , '. , ' '
.
:, ,, ., ' , : ' ' ' :, '
, . ' : ' ' '
,, ;
~ ~L7q'76~Çj
-
- top most Frame 10412 ' 5 Linkage Pointer ~lock 10416 and
Local D~ta Pointer Block lû418l FP, described ~urther in
fol~owing discu~sions, is an ABP to MAS Frame 10412 of
th~ process ' s current procedure ,.
Each Frame 10412'g Local (Automatic) Data Block 1042a
` ; contains certain of the associated procedure's automatic
: data.
..... .
As described above, at each procedure call a ~AS
~; frame is constructed on top of the ~AS of }he 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 KOSMAS
:~ 10334. Procedure ll's linkage pointers are then
.:~ generated, and placed in Procedure ll's Linkage Pointer
~ 15 ~lock 1041~. Next Procedure ll's local pointers are
:~ generated and placed in Procedure ll's Local Pointer
Block 104180 Finally, Procedure ll's local data is
placed in Procedure ll's ~ocal Data Block 10420. During
this operation, USERMAS 10328's frame label sequence is
: 20 updated to include an entry pointing to Procedure ll's
Frame ~ead~r 10414. ROSMAS 10334's Stack ~eader 10410 is
~ updated with respect to STO to the new top o ROS~AS
:~ 10334. Procedure 2's Prame Header 10414 is updated with
; respect to offset to Frame ~eader 10414 o~ 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
',', ~.
j;
,i , : , , ,; .:
ç ,,
.,
.
~: ,
,.~.`4~ _
-125-
constructed on SS 1033~ or Procedure 11. CS 10110 will
: then proceed to execute Procedure 11. During exPcution
~; of Procedure 11, any further local data generated may be
placed on the top of Procedure 11'~ Local Data Block
s 10420. The top of stack offset information in Procedure
~ ll's Frame ~eader 10414 and in KOS~AS 10334 Stack ~eader
: 10410 will be updated accordingly.
IAS 7 S 10328 to 10334 thereby provide a per domain
stack mechanism for storing data pertaining to individual
.: 10 procedures, thus allowing stacking of procedures without
loss of this data. Although structured on a domain
basis, ~AS's 10328 to 10334 comprise a unified logical
stack structure threaded together through information
stored in ~AS stack and ~rame headers.
:. 15 As described above and previously, SS 10336 is a CS
;~ 10110 micromachine stack structure for storing, in part,
m CS 10110 micromachine state fox each stacked VP 10310
procedure. Refexring to Fig. 105, a par~ial schematic
represenkation of a SS 10336 Stack Frame 10510 is shownO
20 SS 10336 S~ack ~eader 10512 and Frame ~eaders 10514
contain information similar to that in MAS S~ack ~eaders
10410 and Frame ~eaders 10414. Again, the information
contained therein locates certain points within SS 10336
structurer and threads together SS 10336 with MAS's 10328
~;
to 10334.
~ SS 10336 Stack Frame 10510 contains certain
; information used by the CS 10110 micromachine in
executing the VP 10212 procedure with which this frame is
.
. ~ ,
'
:,
,
.
'
7~'~7
~26-
associated. Procedure Pointer Block 10516 contains
certain pointers including ABPs, used by CS 10110
micromachine in locating informatio~ within VP 10310'~
information structures. ~icro-Routine FrameY (MRFs)
10518 together comprise Micro~Routine Stack (MRS) 10520
within each S5 10336 Stack Frame 10510. ~S Stack 10520
is associated with the internal operation of C5 10110
microroutines executed during execution of the VP 10212
procedure associated with the Stack Frame 10510. SS
10336 is thus a dual function CS 10110 micromachine
stack. Pointer Block 10516 entries effe~tively define an
interface between CS 10110 micromachine and ~he current
procedure of the current process. MRS lOS20 comprise a
stack mechanism for the internal operation~ of CS 10110
~icromachine.
Having briefly described Virtual Processes 10212,
FURSM 10214 will be described next. As stated above,
EURSM 10216 is similar in oper.ation to FURSM 10214 and
will be described in following detailed descriptions of
CS 10110 s~ructure and operat~on.
3. ~Y~L3ioLlc=~5
:................................ . .
Referring again to Fig. 103, F.URSM 10214 inc~udes CS
10110 micrQmachine informa~ion structures used intexnally
; to C5 10110 ~icrom~chine in executing the procedures of a
P 10310~ When a VP, ~or example P 10310, is to be ~ .
executed~ certain information regarding that VP is
It,~' i trans~erred from the Virtual Pxo~esses 10212 to FURS~
,, .',' .
, . ..
: ~
::
,
' ' ':
.: .-
. :
, . . .
-: ', . ',? :
: ~ :
., . ~, . .
~,,: : : . . ,
: .
::
. . :: : ,.,
~7~'7i~i
--1 27--
10214 for use in executing tha~ procedure. In this
re~pect, FUR5M 10214 may.be regarded as an acceleration
~: mechanism for the current Virtual Proce~s 10212.
~: FURSM 10214 includes General Register File (GRF3
10354, Micro Stack Pointer Register Mechanism (MISP~)
.~ 10356, and Return Control Word Stack (RCWS) 10358. GRF
10354 includes Global Registers (GRs) 10360 and 5tack
Regi~ters (SRs) 10362. GRs 10360 include Architectural
- Base Registers (ABRs) 10364 and ~icro-Control Registers
.~ 10 (MCRs) 10366. Stack Re~isters 10362 include Micro-Stack
IS) 10368 and Monitor Stack ~OS) 10370.
, Referring ~irst to GRF 10354, and assuming for
~ example that Procedure 11 of P 10310 is currently being
: executed, GRF 10354 primarily contains certain pointers
. ~ 15 to P 10310 data used in execut:ion of Procedure 11. As
previously disussed, CS 10110's addressing structure
.~ includes certain Architectural Base Pointers (A~P's) for
each procedure. ABPs provide a ~ramework for excessing
CS lOllO's address space. The ABPs of each procedure
tncIude a Frame Pointer (FP), a ~rocedure Base Pointer
(PBP), and a Static Dat~ Pointer (STP). As discussed
:~ above with reference to ROSPO 10318~ these ABP~ reside in
:~ the proc dure's PEDs. When a procedure i~ called, the~
ABP'~ are transferred from that procedure's PED to ~BR's
: ; 25 10364 and reside therein for the duration of that
j~ procedure. As indicated in Fig. 103, FP point~ between
.~. Linkage Pointer Block 10416 and Local Pointer Blocks
.~ 10418 of Procedure ll's Frame 10412 on ROSMAS 10334. PBP
points to the reference point from which the elements of
: ~ 30 ROSPO 10318 are located. 5DP point to KOSSDA 10326. If
, - .
:
,. . .. .
. `
7~
-l2a-
Procedure 11 calls, for example, a Procedure 12,
Procedure 11l~ ABPs will be transferred onto Procedure
Pointer Block 10516 of SS 10336 5tack Frame 10510 for
Procedure 11. Upon return to Procedure 11, Procedure
ll's ABPs wiil be transferred from Procedure Polnter
Block 10516 to ABR's 10364 and execution of Procedure 11
resumed.
MCRs 10336 contain certain pointers used by CS 10110
`~ micromachine in executing Procedure 11. CS 10110
; 10 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 (SSTO)o NTP and SIP have
been previously described with reference to KOSPO 10318
; 15 and reslde in ~OSPO 10318. ~TP and SIP are transf~rred
: into MCR's 10366 at start of execution of Procedure 11. ~.
.;. PC, as indicated in Fig. 103, is a pointer ~o the :~
.~ Procedure 11 SIN currently bei.ng executed by CS 10110.
.
PC is initially gPnerated from Procedure ll's PBP and CEP
and is thereafter incremented by CS 10110 micromachine as
:l Procedure ll's SIN sequences are executed. SSP and SSTO
~` are, as described in a following discussion, generated
-- from inormation contained in SS 10336's Stack Header
10512 and Frame ~eaders 10514. As indicated in Fig. 103
~ 25 S5P points to start of SS 10336 while SSTO indicates the
.: current top frame on SS 10336, whether Procedure Pointer
Block 10516 or a MR~ 10518 of ~RS 10520, by indicating an
o~fset relative to SSP. If Procedure 11 calls a
subsequent procedure, the contents of MCR's 10366 are
;','~,
"':'
... .
, ~ .
- - . . . .. . .
-
. . ~
. :, ' ~ ' ' ' .
, . . . . .
~i7'~
12~-
.
transferred into Procedure ll's Procedure Pointer Block
10516 on SS 10336, and are returned to MCR's 10366 upon
re~urn to Procedure 11.
Registers 10360 contain furti~er pointers~ described
in following detailed discu~sions of CS 10110 operation,
.- and certain re~isters which ma~ be used to contain the
cur.rent procedure ' s local data .
Referring now to S~ack ~egisters 1036~, MIS 10368 is
an upward extension, or acceleration, of MRS 10520 of the
- 10 current procedure. As previously stated, MRS 10520 is
used by CS 10110 micromachine in executing certain
; microroutines during execution of a particular
. ~ procedure. MIS 1û368 enhances the efficiency of CS 10110
micromachine in executing these microroutines by
15 accelerating certain most recent ~RFs 10518 of that . .
procedure's ~RS 10520 into FU 10120. ~IS 10368 may
oontain, for example, up to the eight most recent MRFs
10518 of the current procedures MRS 10520~ ~s various
microroutines are called or returned from, MRS 10520
~RF's 10518 are transferred accordingly between SS 10336
~: ~ and MIS 10368 so that MIS 10368 always contain~ at least
. .
. the top MRF 10518 o~ MRS 10520, and at most eight MRFs
~; 10518 of MRS 10520. ~ISPR 10356 is a CS 10110
micromachine mechanism for maintaining ~IS 10368. ~ISPR
, ~ 25 10356 contains a Current Pointer, a Previous Pointer, and
,~ a Bo~tom Pointer. Current Pointer points to the top-most
MRF 10518 on MIS l0368. Previous Pointer points to the
previous MRF 10518 on MIS 1036~, and Bottom Poin er
points ~o the bottom-most MRF 10518 on MIS 10368. MISPR
~ 30 10356's Current, Previous and Bottom Pointers are updated
,'.' ~
~; ,
~,,
,~
~ ~ .
" ~. . . . .
~, . . . .
~,. . ,
s,
. ~ . ~ ' ' .
,
!
7'~76Çi
-13Q-
as MRFs 10518 are transferred be~ween SS 10336 and MIS
10368. If Procedure 11 calls a subsequent procedure, all
Procedure 11 MRFs 10S18 are transferred from MIS 10368 to
Procedure ll's ~RS 10520 on SS 10336. Upon return to
Procedure 11, up to seven of Procedure ll's MRFs 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 F~ 10120 and is not an
. extension of a stack residing in a P 10310 in MEM 10112.
: .
:~ ~OS 10370 may contain, for example, eight frames. If
:~ more than eight successive fault or error conditions
occur, this is regarded as a major failure of CS 10110.
Control of CS 10110 may then be transferred to DP 1011B~ ;
As will be described in a foll.owing discussion,
diagnostic programs in DP 10118 may then be used to
~:. diagnose and locate the CS 10110 faults oe errors. In
other embodiments o~ CS 10110 ~OS 10370 may contain more
or fewer stac~ frames, depending upon the degree of self
diagno~is and correction capability desired for CS 10110.
~ CWS 10358 is a two-part stack mechanism~ ~ first
part operates in parallel with MIS 10368 and a second
part operates in parallel with ~OS 10370. As previously
described, CS 10110 is a microcode controlled system.
RCWS is a s ack for storing the current microinstruction
':
,
''',' :
,
,' ~
,
,
,: . ~, , : ,.
: ":
7~7~
:'
being executed by CS 10110 micromachine when the current
procedure is interrupted by a fault or error condition,
: or when a subse~uen~ procedure is called. That portion
o~ RCWS 10358 associated with MI8 10368 contains an entry
for each MR~ 10518 residing in MIS 10368. These RCWS
~` 10358 entries are transferred between SS 10336 and MIS
10368 in parallel with their associated MRFs 10518. When
resident in SS 10336 r thase RCWS 10358 entries are stored
`~ wi~hin their associated MR~s 10518. Tha~ portion of RCWS
10358 associated with ~OS 10370 similarly operates in
parallel wit~ ~OS 10370 and, like MOS 10370 r is not an
extension of an MEM 10112 resident stack.
In summary, each process active in CS 10110 exists as
; a separate, complete, and ~elf-contained entity, or
15 Virtual Process, and is struct:urally organized on a
domain basis. Each Virtual Process includes, besides
procedure and data objects, a set o~ ~AS's for storing
local data of that processes procedures. Each Virtual
Process also includes a CS 10110 micromachine stack, SS
~-; 20 10336 9 for storing CS 10110 mi.cromachine state pertaining
to each stacked procedure of ~he Yirtual Process. CS
10110 micromachine includes a set Of informa~ion
structures, register 10360, MIS 10368, M~S 10370, and
RCWS 10358, used by CS 10110 micromachine in executing
25 the Virtual Process's procedures. Certain of these CS
10110 micromachine in~ormation structures are shared with
the ~urrently executing Virtual Process, and thus are
. efectively acceleration mechanisms for the current
Virtual Process, while others are completely internal to
30 CS 10110 micromachine.
.:,
"'~
. -,
~ .,
~ , , ' ' .'' ~. :
; : ' " ~''''' .;'"''"'"'' :' ~
, .
.. ; . . .
...
--132-
A primary feature o~ CS 10110 is that each process9
macrostacks and secure stack resides in ME~ 10112. CS
10110's macrostack and secure stacks are therefore
e~fectively unlimited in depth.
~: 5 Y~ another feature of CS 10110 micromachine is the
~:~ use of GRE 10~54. GRF 10354 i~, in ~n embodiment of CS
- 10110, a uni~ary register ar~ay containing for example,
256 registers. Certain portions, or address locations,
of ~RF 10354 are dedicated to, respectively, GRs 10360,
~:~ 10 MIS 10368, and MOS 10370~ The capacities of GR 10360,
:~ MIS 10368, and MOS 10~70, may therefore be adjusted, as
. ~ required for optimum CS 10110 efficiency, by reassignment
of GRF 10354's address space. In other embodiments of CS
; 10110, GRs 10360, MIS 10368, and MOS 1037~ may be
implemented a functionally sepa~ate registers arrays.
~avin~ briefly described t:he structure and operation
o~ Proc~ss Struc~ures 10210, VP State Block 10218 will be
:: described next below.
"-~ C. _~
. ~ 20
Referring again to Fig. 102, VP State Blockæ 10218 is
~: ~ used in management and control of process~s. VP S~ate
.~ 81Ocks 10218 contains a VP State Block for each Virtual
Process (VP) selected for execution by CS 10110~ Each
:~: 25 ~uch VP State Block contains at least the following
information:
(1) the state, or identification number of a VP;
,-
,
:
. . : .
;, . ,
: .
: ::
. . ; : ' ' ' . :
,
~7'~
-133-
(2) entries identifying the particular principle and
particular process of the V~;
: (3) an AO~ pointer to that VP's secure stack (e.g.,
~ SS 10336);
-; 5 (4) the AON's of that VPIs ~AS stack objects (2.g.,
. .
MAS's 10328 to 10334~; and,
(5) cert in information used by CS 10110's VP
Managem nt System~
The information contained in each VP Sta~e Block
~ 10 ~hereby def ines the current s~ate of the asocia~ed 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 ob~ects created for
that VP/ micromachine ^ta~e entries~ and a pointer to the
user's program. CS 10110's ROS then generates ~acro- and
Secure~Stack Objects with headers for that process and,
~: as described further below, loads protection lnformation
regarding that process' objects into Protection
:: Structures 10230. CS 10110's ROS then copies this
primitive machi~e state record into a vacant VPSB
selected by CS 10110's YP Manager, thus binding the newly
created VP into CS 10110. At that time a ROS Initializer
; 25 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.
. ' ' ' ' .
. .
,
.... . . .
. . -;
, , - :
.
'
.
~Li ~ ~7~i6
--13~--
: D. _~L =_~=~ :
:" ~L
- As prev1 ously described, the data space acce~sible to
~,
5 CS 10110 is dlvided into segments, or containers,
referred to as objects. In a~ embodiment of CS lOllû~
: ~ the addressable data space o~ each object has a capacity
~ ~ of ~32 bits of information and is structured into 213
: :~ pages with each page containing 214bits of information. ~-
~- 10 Referring to ~ig. 106A, a schematic rep~esentation of
CS lOllû's addre~sing structure is shown. Each object
created ~or use in, or by operation of, a C~ 10110 is
- pennanently as~igned a unique identif lPr (UID) . An
ob~ec~ l ~ UID allows an obj ect to be uni~uely iden~if ied
15 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 o~ject~ wherein each object may
con~ain up to 232 bits of inormation. As indi~ated in
Fig, 106, each 8û bit UID is comprised of 32 bit~ of
. . 20 Logical Allocation Unit Identif ier (LAUID) arld 48 bits o~
Object Serial Number ~OSN). LAUIDs are ass~ciated with
-: individual CS 10110 sys em~. LA~IDs identi~y the
:~ particular CS 10110 system generatin~ a par~icular
.. objec~. Each LAUID is comprised of a Logical ~llocation
,;, ,;
:-. 25 Unit Group Number (LAUGN) and a Logical Allocation Unit
:. Serial Number (LAUSN). LAUGNs are assigned ~o individual
CS 10110 systems ar~d may be guaranteed to be uni~ue ~o a
... ~ . .
,, :
. .
. ~
, ~. ,;
~, '
, .
.,., , , ~ . :. . . . .
,: : ' , . ~ ' ' ' , , '. , ,, , ' ' ' .
: ~ 17'~7
-135-
particular sy~tem. A particular system may, ho~ever, be
assigned more than one LAUGN so that there may be a time
varying mapping between LAUGNs and CS 10110 systems.
LA~S~ are assigned within a particular system and, while
L~USNs may be unique within a pàrticular system, LAUSN-
~
~ need not be unique between sys~ems and need not map onto
;~ the physical structure of a particular systemO
OSNs are associated with individual objects createdby an LAU nd are generated by an Architectural Clock in
:~ 10 each CS 10110. Architectural clock is defined as a 64
bit bin ry number representing increasing ~ime. Least
significant bit of architectural clock represents
increments of 600 picoseconds, and most significant bit
represents increments of 127 years. In the present
15 embodiment of CS 10110, certain most significan~ and
: least significant bits of architec~ural clock time are
disregarded as generally not required practice~ Time
: indicated by architectural clock is measured relative to
~ an arbitrary, fixed point in t.ime. This point in time is
:: 20 the same for all CS 10110s which will ever be.
.
~ sonstructedq All CS 10110s in existence will therefore
,; indicate the same architectural clock time and all UIDs
`.: gen~rated will have a common b~sis. The use of an
~: architectural clock for generation of OSNs is
:~ 25 advantageous in that it avoids the possibility of
~: accidental duplication of OS~s if a CSC 10110 fails and
is subsequently reinitiated~
:
' ~ ' .
.
-~ -. . . ~ .: - -
.
' ' . .' ;', .', , '
, ' '" '' ':
7'~7
-136-
' ~
As stated above, each object generated by or for use
in a CS 10110 is uniquely identified by its associated
- UID~ By appending Offset (O) and Length (L) information
to an object's UID, a UID logical addre~s is generated
5 which may be used to locate particular segments o~ data
~ residing in a particular object. As indicted in Fi~
: 106, O and ~ field~ of a UID logical address are each 32
bi~s. a and L fields can therefore indicate any
~'1 1
particular bitt out of 2JC L bits, in an object and thus
:; 10 allow bit granular addressing o information in objects~
~; As i.ndicated in Fig. 106 and as previously described,
`~ each object acti~e in CS 10110 is assign~d a short
::~ temporary unique identifier valid only within JP 10114 ?
~ and referred to as an Active Ob~eçt ~umber (AO~
.~: 15 Because fewer objects may be active in a CS 10110 than
.~ may exist in a CS 10110's address space, AON's are, in
:~ ~
::: the present embodiment of CS 10110 r 14 bits in length. A
:` particular CS 10110 may therefore contain up to 214
: active objects. An object's AON is u~ed within JP 10114 ~:~
:;.......... 20 in place of ~hat object's UI~. For example, as discussed
above wi~h reference to process structures 10210, a
procedu~e'~ ~P points to start of that procedure's frame
on it~ process ' MAS . When that YP is residiny in SS
: 10336, it is expressed a~ a UID, When that procedure is
` 25 to be executed, FP is transferred from SS 10336 to ABR's
: 10364 and i5 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
' ~:
.", , ', ~.
,, :
;.. . . . , . .. , i . . . : : . ~ .,
. . . . . . . . . .... . . .
,;i ,, ~ , .
,,: . ; . .
7~7
-~ -137-
. an object may be addressed by means of an ~ON logical
:: address comprising the objec~'is AON plus associated 32
bit Offset (O) and Length (L) fields.
~ Each operand appearing in a process ls assigned a
.~ 5 Name and all references to a process's operand~ are
through those as~igned Names. As indicated in Fig~ 106B,
~- ~ in the present embodiment of CS 10110 each Nam~ 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 followin~ discus~ion, Names appearing during
axecution of a process may be re~olved, through a
~; procedure's Name Table 10350 or through Name Cache 10226,
5 ~ ~ to an ~ON logical address. As described below, an AON
logical address corresponding to an operand Name may then
15 be evaluated to a NEM 10112 physical address to locate
the operand re~erred to.
. The evaluation of AO~ logical addresses to ~E~ 10112
physical addresses is represerlted in Fig. 106C. An AON
~ logical address's L field is not involved in evaluation
$~` 20 of an AON logical address to a physical address and, for
purpose~ o~ clarity of presentation, is therefore not
~ ~ represented in Fig. 10SC, AON logical address L field is
6: to be understood to be appended to the addresses
fi ' ~ represented in the various steps o~ the evaluation
,.,;~ 25 procedura shown in Fig. 106C.
r''" As describ~d above, objects are 232 bits structured
'~ in~o 2 18 pages with each page containing a 214 bits of
~, ......................................................................... .
r.,
~,
~ .
: : ,
~: . . . .. . .
:' ' ' , '.'. : '' . : .
:s
., ' . ,, ' . .
~''" ' ' '' , ' .
., ' ~ . :
,r"~, ,
~7~766
-13~
data. ME~ 10112 is similarly physically ~tructured into
frames with, in the presen~ embodiment of C5 10110, each
frame containing ~14 bits of data~ In other embodiments
of CS 10110, both pages and frames may be of different
si2es but th~ translation of AON lo~ical addresses to M~M
~; 10112 physical addresses will be similar to that
.~ described momentarily.
~ An AON logical address O field was previou~ly
:: described as a 32 bit number representing the start,
:; 10 relative to start of the object, of the addressed data
- segment within the object. The 18 most significant bits
of O field represent the number (P) of the page within
~he object upon which.~he first bit of the addressed data
occurs. The 14 least significant bits of O field
. 15 represent the offset (Op), relative to the start of the
: page, within that page of the first bit of the addressed
data. AON logical address O field may therefore, as
;`~ indicated in Fig. 106C, be divided intc a~ 18 bit page
: ~P) field and a 14 bit offse~ within pa~e (Op) field~
20 Since, as described above, MEM 10112 physical ~rame size
is equal to object page size, AON logical address Op
field may be used directly as an offset with m frame (Of)
field of the physical address. As will be described
below, an AO~ logical address AO~ and P fields may then
25~ be related to the fr~me number (FN) of the MEM 10112
frame in which that page resides, through Addressing ~,
Mechanisms 10220.
:. -
. .
,-
,
- ,, - .; . ~::
., :
" . . ~ . . . .
,
:: . ' . ~ '
., ~
7~i
-139-
~aving briefly described the relationships between
UIDs, UID Logical Addresse~, Names, AoNs~ AON Logical
Addresses, and ~2~ 10112 Physical Addresses, Addressing
~ ~echanisms 10220 will be described next below.
: 5 2~ ~
. Ref2rring to Fig. 107, a schamatic representation of
Computer System 10110's Addressing ~echanisms 10220 is
shown. As previously described, Addressing Mechanlsms
10220 comprise ~ID/AON Tables 10222, Memory Mana~ement
10 Tables 10224, Name Cache 10226, and Address Translation
~ Unit 10228.
.. UID/AON Tables 10222 relate each object's UID to its
~! assigned AON and include AOT ~ash Table (AOT~T) 10710,
Active Object Table (AOT) 10712, and Active Object
15 Ta~le Annex (AOTA) 10714.
An AON corresponding to a particular ~ID is
d~termined through AOT~T 10710. The UID is hashed ~o
provide a UID index into AOTHT 10710, which then provides
.. ; the corresponding AON. AOT~T 10710 is e~fectively an
; 20 acceleration mechanism of AOT 10712 to, as ~us~
described, provide rapid translation of UI~s to AONs~
~ AONs are used as indexe~ into AOT 10712, whioh provides a
-.- corre~ponding AOT Entry (AOTE). An ~OTE as described in
following detailed discussions of C5 10110, includes~
25 among other information, the UID correspondin~ to the AON
indexing the AOTE. In addition to providing trans1ation
,
,
.
",
.
,
~:`
~ ,
. .
~L74~6~i
--l~o-- ..
between AONs and UIDs, the UID of an AOTE may be compared
- to an original UID to determine the correctness of an AON
; from AOT~T 10710.
Associated with ~OT 10712 is AOTA 10714~ AOTA 10714
~- 5 is an extension oE AOT 10712 and contains certain
information pertaining to ac~ive objects, for example the
: domain of execution of each active procedure object.
: Having briefly described CS 10110's mechanism for
relating UIDs and AONs, CS 10110's mechanism for
~ lO resolving operand Names to ~ON logical addresses will be
: described next below.
3. ~_
: Referring fir3t to Fig. 103, each procedure object in
a VP, for example ROSPO 10318 in YP 10310, was described
: 15 as containing a Name 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 ~he corresponding Name to
an AON Logical Address, includin~ fetch mode information,
20 typ~ of data referred to by that Name, and length of the
; data segment referred to.
:` Referring to Fig. 108, a represen~ation of an NTE is
shown. As indicated, this NT~ contains seven information
ields: Flag, Base (B), Pxedisplacement ~PR), hength (L), :~
25 Displacement (D), Index (I), and Inter-element Spacing
(IES)o Flag Field, in part, contains information
~-. describing how the remaining fi~lds of the NTE are to b
interpreted, type of information referred to by the NTE,
and how that information is to handled when fetched from
',
.
;;
.
- .,
, ' , .
..
., . , , . , .
, . .: - . .. . . .
.. ' : ,:. . ., ... . ' .' :. . . :
;. . .
~ ~ 74 7
"
-141-
ME~ 10112. L Field, as pre~iously described, indicates
len~tht or number of bits in, the data segment.
Func ions of the other ~E fields will be described
during the followlng discussions,
~ S In a present embodiment of CS 10110, there are five
- types of NTE: (1) base (B) is not a Name, addres~
resolutio~ is not indirect; 12) B is not a Name, address
resolution is indirect; (3) B is a ~ame, address
resolution is indirect; (4) B is a Name, address
10 ~esolution is indirectO A fifth type is an NTE ~electing
a particular element from an array of elements. ~hese
:~: five types of NTE and their resolution will be described
below, in the order men~ioned.
In the first type, B is not a Name and address
15 re~olution is not indirect, B Field specifies an AB~
10364 containing an AON plus offset (AON/G) Poin~er. The
contents 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 ~ame and address
20 resolution is indirect~ B Field again specifies an ABR
10364 containing an AON/O pointer. The contents of P~
Field are added to the O Field of the AON/O pointer to
;: provide an AO~ Logical Address of a Base Pointer~ The .
-; Base Pointer AON Logical Address is evalua~ed, as
25 described below, and the Base ~ointer fetched from ME~
:: 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.
., .
:.
,
.. : ~ : '
.
, . - ':
. ,
:
-14~-
NT~ types 3 and 4 corresporld, respectively to NTE
typ s 1 and 2 and are resolved in the same manner except
that B Field con~ains a NameO The ~ Field Mame is
resolved throuyh another NTE to obtain an AON/O pointer
:~S which is used in place of the AB~ 10364 pointers re~erred
to in discu~sion of type~ 1 and 2.
:The fifth ~ype of NTE is used in references to
;~elements of an array. These array NTEs are resolved in
the same manner as NTE types 1 t~rough 4 above to provide
::10 an AON Logica~ Address o the start of the array. I and
IES Fields provide additional information ~o locate a
particular element ~n the array, I Field is always Name
which is resolved to obtain zn operand value representing
.
; the particular element in the array. XES Field provides
in~ormation regarding spacing between elements of the
array, that is the number o~ bits between adjacent
element of the array. IES Field may contain the actual
IES value, or it may contair. a Name which is resolved to
`............... an AON Logical Address leading to the inter-elemént
spacing value~ The I and IES values, obtained by
,~resolving the X and IE5 Fields as just described, are
multiplied together to determine the offset, relative to ~ :
~he start of the array, of the particular elemen~
referred to by the NTE~ This within array offse~ is
;,~25 added to the O Yield of the AON Logical Addre s of the
..start of the array to prsvide the AON Logical Address of
. the element.
. ,:
. ,
. ~
.. ~.
,. . . .
'
- - . . - . .. . - . .
, ~ , ., - . .
~ ,
" , ~ ~
~17~
-143~
In ~he current embodiment of CS 10110, certain NTE
fields, for example B, Dt and Flag fields, always contain
literalsO Certain other field~, for examplej IES, D,
PRE, and ~ fields, may contain either literals or names
5 to be resolved. Ye~ other fields, for example I field,
always contain names which ~ust be resolved.
~ Passing of arguments from a calling procedure to a
-~ called procedure has been pre~iously discussed with
reference to ~irtual Processes 10212 above~ and more
- 10 specifically with regard to ~A5's 10328 to 10334 of VP
10310. Passing of arguments i5 accomplished through thP
calling and called procedure's ~ame Tables 10350. In
illustration, a procedure W~a,b,c) may wish to pass :~.
arguments a, b, and c to procedure X(u,v~w) r where
arguments, v and w correspond to arguments a, b, and c.
A~ compilation, NTEs are generated for arguments a, b,
: and c in Procedure W's procedure object, and ~TEs are
generated fox arguments u, v and w in Procedure X's
procedure object. Procedure X's NTEs for u, v, and w are
20 constructed to resolve to point to pointers in Linkage
Pointer Block 10416 of Procedure x's Frame 10412 in MAS.
To pas~ arguments a, b, and c from Procedure W to
Procedure X, the NTEs of arguments a, b, and c are
re olved t AO~ Logical Addresses (i.e., AON/O form)~
Arguments a, b, and c's AON Logical Addresses are then
; translated to corresponding ~ID addresses which are
placed in Procedure X15 Linkage Poin~er Block 10416 at
those places pointed to by Pro~edure X's NTEs for u, v,
~ and w. When Procedure X is executed, the resolution of
.. ; ' , .
: ~ .
,'
.;
.
:, . ' ' '
. ..................................... . .
" ' ~' ' ' , , ,
7~;~
. .
-1~4-
.
Proce~ure X'5 NTEs for u, v, and w will be resolved to
losate the pointers, ln Procedure X's Linkage Pointer
: Block 10416 to arguments a, b, and cO When arguments are
passed in this manner, the da~a type and length
5 information ar~ obtained from the called procedure's
NTEs, rather than the calling procedure's NTEs. This
allows the calling procedure to pa~s only a portion of,
for exampl~, arguments a, b, or c, to the called
procedure and thus may be regarded a~ a feature of CS
10 10110's protection mechanisms.
aving briefly de~cribed resolution of Names to
AON/Offset addresses, and having previously described
~ . translation of UID addresses to AON addresses, the
.~ evalua~ion of AON addresses to MEM 10112 physical
: 15 addresses will be described next below. .
4- ~o~ lL~O~ d~ s=~c=~h~
Referring again to Fig. 107, a partial schematic
~ representation of CS 10110's ~emory ~anagement Table
:. 20 10224 is shown. Memory Hash Table (MHT) 10716 and Memory
Frame Table (M~T~ 10718 are concerned with translation o
; A~ addresses into MEM 10112 physical addresses a~d will
~ be discussed first. Working Set Matrix (WSM) 10720 and
.;; Virtual Memory Manager Request Queue (VMMRQ) 10722 are
:- 25 concerned with management o~ MEM 10112'5 available
. physical address base and will be discussed second~
Activ~ Object Request Queue (AORQ) 10728 and ~ogical
."~,` .
,, ~
.. ; ,
. -
, ,.
"'~
.. ~: ,. ; . .: . .. .
. . . .. . .. . .
: ~ . .: ,
,
.. . .
:: . :
: ~ . . .
`
~
7476i~i
~145-
~llocation Unit Directory (L~UD) 10730 are concerned with
locating inactive objects and management of which objects
- are active in CS 10110 and will be discussed last.
Translation of AON/O Logical Addresses to MEM 10112
S physical addresses was previously discu~sed with
referen~e to Fig. 106C. As stated in that discussionr
; objects are divided in~o pages. Correspondingly, the
AON/O Logical Address' O Field is divided into an 18 bit
page nu~lber (P) Field and a 14 bit offset within a page
(op) FieldO MEM 10112 is structured into frames, each of
which in the present embodimeslt of CS 10110 is equal to a
page of an object. An AO~/O address' Op Field may
~ . therefore be used direc~ly a an offset within frame (Of)
~ ~ of the corresponding physical addressO The AON and P
l : 15 fields of an AON address must, however, be translated
into a MEM 10112 frame represented by a corresponding
Frame ~umber (FN).
Referring now to Fig. 107, an AO~ address' AON and P
Fields are "hashed" to generate an ~ index which is
20 used as an index into M~T 10716. Briefly, "hashing" is a
method of indexing, or locating, information in a ~a~le
~: wherein indexes to the information are generated from the
.` information itself through a "hashing ~unction". A
hashing functlon maps each piece of information to the
~; 25 corresponding index generated from it through the hashing
~; function. MHT 10716 then provides the corresponding F~
. of the MEM 10112 frame in which that page is stored. FNs
are used as ind~xes into MFG 10718, which contains, for
. each FN, an entry describing the page stored in that
30 frame. This information includes the AON and P of the
,
, :
:
, .
, ':,, ' :'
, . . .
, .
~", ,
,. . .
76~;
-146-
page s~ored in tha~ MEM 10112 frame. An F~ from M~T
10716 may thereEore be used as an index in~o MFT 10718
and the resulting AON/P of MFT 10718 compared to the
original AON/P to confirm the correctness of the ~N
5 obtained from M~T 10716. MHT 10716 is an ef~ectively
;; acceleration mechanism of MFT 10718 to provide rapid
translation of AON address to hEM 10112 physical
addresses,
MFT 10718 also stores "used'l and "modified"
10 information for each page in MEM 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 written
15 into ME~I 10112 from backing store tED 10124)~ For
example, if a page's modified bit indicates that that
:i page has not been written into, it is not necessary to
write that page back into backing store when it is
deleted from MEM 10112; instead, that page may be simply
- 20 erased.
.Referring finally to ATU 10228, ATU 10228 is an ~.
acceleration mechanism for M~T 107160 AOM/O addresses
: are used directly, without hashing t as indexes ~nto ArU
:~ 10228 and A~U 10228 correctly provides corresponding ~N
.- 25 and O outputs. A CS 10110 mechanism, descxibed in a
. following detailed discussion of CS 10110 operation,
,~:
. . ..
. . ,
.... .
:'
: ,.;
".' '
.: ~ . . . .
:. , .
L7~
7-
continually updates the contents of ATU 10228 so that ATU
: 10228 contain the FN's and Op (Cf ~ of the pages most
frequently referenced by the current process. If ATU
: 10228 does not contain a corre ponding entry for a ~i~en
-~ 5 AON input, an AT~ fault occurs and the FN and O
informati~n may be obtained directly ~rom M~T 10716.
Referring now to WSM 10720 and VMMRQ 10722, as
previously stated these mechanisms are concerned with the
management of MEM 10112's available address spacer For
:~ 10 example, if MHT 10716 and MFT 10718 do not contain an
entry for a page referenced by the current procedure, an
MHT/MFT ault occurs and the reference page must be
~: fe ched from backing store ~ED 10124) and read into MEM
101120 WSM 10720 contains an entry for each page
. 15 resident in ME~ 10112~ These entries are accessed by
~ indexes comprising the Virtual Processor Number (VPN) of
: the virtual process making a p~ge reference and the P of
the page being referenced. Each WSM 10720 entry CQntainS
2 bits stating whether the par~icular page is part of a
20 VP's working set, that isr used by that VP, and whether
that page has ~een referenced by ~ha~ VP. This ~ :
information, together with the in~ormation contained in
that ~FT 10718 entries described above, is used by CS
. lOllO's Virtual Memory Manager (VMM) in transferring
25 pages into and out of MEM 10112.
CS lOllO's VMM maintains VMMRQ 10722, which is used
i by ~MM to control tran~fer of pages into and out of MEM
-: 10112. VMMRQ 10722 includes Virtual Memory Request
.~ Counter (VMRC) 10724 and a Queue of VirtuaL Memory
'
:
.
;- : ", ~ " :
,~
:. ,
" ' ' , ' . :' . .
;6
~148-
. ~
Reque~t EntriPs (VMREs) 107264 As will be discussed
mamentarily, VMRC 107~4 tracks the number o currently
outstanding r~quest for pages. Each VMRE 10726 describes
~-~ a particular page which has been requested. Upon
~- 5 occurrence of a M~T/MFT (or page) fault, VMRC 10724 is
increm~nted, which initiates operation of CS 10110's VM~ -
and a VMRE 10726 is placed in the queue. Each VMRE 10726
comprises the VPN of the process requesting the page and
the AON/O of the page requested. At this time, the VP
10 making the request is swapped ou~ of JP 10114 and another
~` VP bound to JP 10114. VMM allocates MEM 10112 frame to
.~ contain the requested page, using the previously
described informa~ion in MFT 10718 and WSM 10720 to
select this frame. In doing so, VMM may discard a page
15 currently resident in MEM 1011~ for example, on the basis
` of being the oldest page, an unused page, or an
:`3 unmodified page which does not have to be written back
.~ into backing store. VM~ 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, VMM
generates new entries in M~T 10716 and MFT 10718 for the
requested page, cleans the ~r~me in MEM 10112 which is to
be occupied by that page, and.suspend~ op~rationO IOS
.~ 10116 will proceed to execute the I/O operation and
t 25 writes the requested page directly into MEM 10112 in the
frame specified by VMM. IOS 10116 then notifie~ CS
10110's V~M that the paye now resides in memory and can
~be referenced. At some later time, that VP requesting
that page will resume execution and repeat that
..,
, .
, .
''.~'
,
...
: : . ; ~ .: . -
,, ,, .: :
. - ~ ,
, ,
: - ,: '
-: , , ,
' : . , , , , : ,
~ 6 :~.
-149- `
reference Golng first to ATU 10228, that VP will take
an A~U 10228 fault since VP 10212 has not yet been
updated to contain that page. The VP will then go to M~T
~- 10716 and MFT 10718 for the re~uired information and,
5 concurrently, WSM 10720 and ATU 10228 will be updated.
In regard to the above operations, each VP active in
CS 10110 is assigned a Page Fault ~requency 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 mos~
eficien ly and allow~ CS 10110's VMM to be tuned as
required.
The above discussions have as~umed that the page
;~ 15 being referenced, whether fronil a UID/O address, an AON/O
address/ or a Namer is resident in an object active in CS
10110. While an object need rot hav~ a page in MEM 10112
to be ac~ive, the object 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. If 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
~, 25 ~AOM), includin~ Acti~e Object Request Queue (AORQj
; 10728, which are similar in operation to CS 10110's VMM
and VMMRQ 10722~ CS 10110's AOM and AORQ 10728 operate
in conjunction with AOT~T 10710 and AOT 10712 to locate
inactive objects and make them active by assigning ~hem
;, ' ' '
. :
... . . .
.
~ ' ~.~ ' :-' ' .
. ~ , .
: , ,
7~7
' ~
: -150-
; AON's and generating entrles for them in AOT~T 10710, AOT
10712~ and AOTA 10714.
~e~ore a particular object can be made active in CS
10110, it must first be located in backing store (ED
5 10124). All objec~s on backing store are located through
. a Lo~ic~.l Allocation Unit Directory ~LAUD) 10730, which
.~ is resident in backing store. An LAUD 10730 contains
entries for each object accessible to the particular CS
10110~ Each LAUD 10730 entry contains the information
10 necessary to generate an AOT 10712 entry for that
:: ob~ect. An LAUD 10730 is accessed throuqh a UID/O
:.` address contained in CS 10110's V~M~ A reference to an
. LA~D 10730 results in MEM 10112 frames being assigned to
~hat LAUD ~0730, and LAUD 10730 being transferred into
: 15 MEM 10112. If an LAUD 10730 entry exists for the
refe~enced inac~ive objectt the LAUD 10730 entry is
.: transferred into AOT 10712. At the next rererence to a
~ page in that object, AOT 10712 will provide the AON for
.~ that object but, because the page has not ye~ been
.~ 20 transerred in~o ME~ 10112, a page fault will occur.
This page ~ault will be handled in the manner described
above and ~he referenced page tran ferred into MEM 10112.
; ~aving briefly described the structure a~d operatio~
. of CS 10110's Addressing Structure, including the
. 25 relationship between ~IDs, Names, AONs, and Physical
: Addresses and the mechanisms by which CS 10110 manages
,'~
:
~':
, .
,,
: -- - . . . . . . . .
.
:, ~ : :. . ..
.. . .
,' ' , , ' ,, ' ;
,. :, , ,
: ' .
~7 ~ ~ .
-151-
the available address space of MEM 10112, CS 10110's
protection structures will be described next below.
E. ~
Referring to Fig. 109, a schematic representation of
Protection ~echanisms 10230 is shown. Prote~tion Tables
10232 include Active Primitive Access Matrix (APAM)
10910, Activ~ Subject Number Hash Table (ASN~T) 10912,
and Active Subject Table (AST) 10914. Those portions of
: Protection Mechanism 10230 resident in FU 10120 include
;: ~ 10 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
. def ined as a particular combination of a Principle,
~ Process, and Domain (PPD) ~ each o~ which is identified by
~; 15 a corresp9nding UID. Each object has associated with it
- an Access Cosltrol List (~CL) 10918 containing an ACL
: En~ry (ACLE) for each subject having access rights ~o
that objectO
:~`. . When an object becomes active in CS 10110 (i~e., is
:h 20 assigned an AON) each ACLE in that object's ~CL 10918 is
. wri~ten into APAM 10910~ Concurren~ly, each subject
~. haviny access rights to that object, and for which there
:~ is an ACLE in that object's ACL 10918, is assigned an
: Active Subject Number (ASN). These ASNs are written into
-~ 25 ASNHT 10912 and their corresponding P~Ds are written in~o
AST 10914. Subsequently, the ASN of any sub~ect
requesting access to that object is obtained by hashing
~ ~ .
'":' ..
. .
;";.;, .
, : .
.
,
9L7~ .
-lS2
:;:
~` the PPD o~ that subject to ob~ain a PPD index into ASNHT
: 10912. ASN~T 10912 will in turn provide a corresponding
- ASN. An A5N may be used as an index into AST-10914. AST
10~14 will provide the corresponding PPD, which may be
j:; 5 compared to an original PPD to confirm the accuracy of
the ASN.
As described above, AP~M 10310 con ains an ACL 10918
for each objeet active in CS 10110~ The access rights of
any particular active subject to a particular active
10 object are determined by using ~hat subject's ASN and
that ob~ect's ~ON as indexes into ~PAM lOglO. APAM 10910
.: in turn provides a 4 bit output defining whether that
subject has Read (R) Write (W) or Execute (E) rights with
.;~ respect ~o that object, and whether that particular entry
;` 15 is Valid (V).
SN Register 10916 and PC 10234 are effectively
acceleration mechanisms of Protection Tables 10232O ASN
Register 10916 stores the AS~ of a currently active
~ ~ubject while PC 10234 stores certain access right
: 20 information for objects being used by the current
- process. PC 10234 entri~s are indexed by ASNs from ASN
reyister 10916 and by a mode input from JP 10114. Mode
input defines whe~her the curxent procedure intends to
read, write, or execute with respect to a particular
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
''
.~ .
, ,
.
. . .
i':
,. . . ................... . . .. . .
, ~ ' ' '
. ~
7~ ~ 6 6
153-
required to execute ~he intended operation with respect
to that object.
In addition to the above mech~nism, each procedure to
:~ which arguments may be pas~ed in a cross-domain call has
;~: 5 associated with it an ~ccess Information Array (AIA)
10352, as discussed with reference to Virtual Processes
~ 10212. `A procedure' 5 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
~ompare the calling procedures access rights to the
~: right~ required by the called procedure. This insures
: the calling procedure may not ask a called procedure to
~`~i do what the calling procedure is not allowed to do.
~; 15 Effectively, a calling procedure can pass to a called
- procedure only the access rights held by the ~alling
procedure.
Finally, PC 10234, AP~M 10910, or AST 10914 faults
::~ (i.e~, misses) are handled in the same manner as
:: 20 described above with re~erence to page faults in
discussion of CS lOllO's Addressing ~echanisms 10220. As
~ such, the handling o~ pro ection ~isses will not be
:.~ discussed further at this point.
- Having briefly described structure and operation of
::` 25 CS lOllO's Protection Mechanisms 10230, CS lOllO's Micro~ ;
~-, Instruction Mechanisms 10236 will ~e described next
below.
; .
.~ .
~, ~
~ .
. ,
. . , . . . . . . -
". ~ ,, . " ,. ,, . : ,
: . . . . ,~ .. . .
.. ..
; . i ; :
'. , , . I , ..
, ~
, - . .., ,, . ,., " ,. . . .,: , ,
a9~ ~
15~-
.
F~ ~ (Fig. 110)
~s previously described, CS lQllO i~ 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. C5
'~ 10110 provides a set, or dialect, of microcode
instructions, referred to as S-Interpreters (SINTs) for
each S-Language. SINTs interpret SINs and p~ovide
~ corresponding sequences of microin~tructions ~or detailed
: 10 control o~ CS 10110.
: Referrin~ to Fig. 110, a partial schematic
~: representation of CS lOllO's Micro-Instruction Mechanisms
10236 is shown. At system initializa~ion all CS 10110
microcode, including SINTs and all machine assist
, 15 microcode, is transferred from backing store to Micro- ~:
.~ Code Control Store (mCCS) 10238 in ~EM 10112~ The ~icro-
Code is then trans~erred from mCCS 10238 ~o FU Micro-Code
3 Structure (FUmC) 10240 and EU Micro-Code Structure (EUmC)
` 10242. EUmC 102~2 is similar in structure and operation
20 to FUmC lU240 and thus will be described in following
, , ,
detailed descriptions of CS lOllO's structure and
operation. Similarly, CS 10110 machine assist microcode
will be described in following detailed discussions. The
~; present discussion will concern CS lOllO's S-Interpreter
. 25 mechanisms-
CS lOllO's S-Interpreters (SINTs) are loaded into S-
Interpre~ Table (SITT) 11012, which is represented in
:~ FigO 110 as containing S-Interpreters 1 to N. Each SIT
.''', .
. .
'. ' ,~
. ' '~ ' '` ' , '
.' '
~ ~ ~i7~76~
: -155-
:
: contains one or more equences of micro-code; each
~: sequence of microcode corresponds to a particular SI~ in
that S-Lanyua~?e dialect~ S-~nterpreter Dispatch Tahle
(SDT) 11010 contains S-Interpreter Dispatchers (S~s) 1 to
5 ~. There is one SD for each SINT in SITT 11012, and thus
a SD for each S-Language dialect. Each sr? comprises a
set of pointersO Each pointer in a particular SD
;~ corresponds to a particular SIN of that SD's dialect and
points ~o ?the corresponding sequence of microinstructions
~` 10 for interpreting that SIN in that dialect's SIT in SITT
:~ 11012. In illustrationr as previously discussed when a
particular procedure is being executed the SIP for that ::
procedure is transferred into one of mCRIs 10366. That
: SIP points to the start of the SD for the SIT which is to
lS be used to interpret ~he SI~s of ?~hat procedsre. In Fig.
~-. 110, the SIP in mCRs 10366 is shown as pointing to the
start of SD2. Each S-Op appearing during execution of
: that procedure is an offset, relative ~o the start of the
-~ selected SD, pointing to a corresponding SD pointer.
20 ~hat SD pointer in turn poin~s to the corresponding ~:
sequenc~ of microinstructions for interpreting that SI~
in the correspondin~ SIT in SITT 11012. As will be :~
described in following discussions, once the start of a :~
microcode sequence for interpreting an SIN has been
25 selectedl CS 10110 micromachine then proceeds to
sequentially call the microinstruc~ions of that sequence
from SITT 11012 and use those microinstructions to
, ~
control operation of CS 10110. ~
?
` '
;' '
.'','.' ~
; ' :',~ `
, '~ ' .
~'~
'' ~ ' . : ' " ' :, , ;: `: '`
.', , ' ` .
,'. ' ` ~ ' :
; `: ' ' ` ' ' ' ' ' ,, ' ' ' . . . . . ` ' ,.
;. `' ~ "' ` `'` '"` '"""''''.'',': " "' " '" ' `
,' i ' , ' ' ' ` ' ', " ':"
` ~ , '.
;` ' '` ;, ' ' .''
- . -
~L~L7~6~
-156-
'. .
.", ~L~
The above Introductory Overview has described the
~; overall structure and operation and certaln features of
: 5 C5 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 physic~l
~-~ implementation and operation o~ CS 10110's information,
-.~: control, and addres ing mechanisms. Certain of these CS
10110 featur~s are summarized next below to briefly state
the basic concepts of these features as implemented in CS
10110. In addii~ion, possible alternate embodiments o~
~-. certain of these concepts are described.
.~ First, CS 10110 is comprised of a plurality o~
independently operating processors, each processor having
:~ a separate microinstruction control. In the present
;i embodiment of CS 10110, these processors include FU
j
~''! 10120, EU 101~2, MEM 1011~ and IOS 10116. Other such
independently operating processors, for example, special
2~ arithmetic processors such as an array processor, or
multiple PU 1û120 's, may b added to the present CS
1011~. .
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 ME~
. 10112 operates as ~he central communications node of CS
'',
,~ .
- .
. . .
. ~ , . ..
. ., ~ '; ,~, . -
~.~ .. ". ,. ~ ,.
,
, . : . , ~ . . ~
-157
lOllO, as well as performiny memory operations. Further
separate and independent ports may be added to MEM 10112
:; as further processors are added to CS 10110. CS lOllO
. .
may therefore be described as comprised o~ a pluralii~y of
: 5 ~eparat~, independent processors, each having a separate
. ~ microiinstruction control and having a separate and
: ~ independent port to a central communications and memory
: node which in itself is an independent processor having a
: separate and independent microinstruction control. As
:` lO will be further described in a following detailed
;~ description of MEM 10112, MEM 10112 itself is comprised
`: of a plurality o~ independently operating processors,
each performing memory related operations and each having
:~ a separate microinstruction control. Coordination of
15 operations between CS lOllO's processors is achieved by
`~ passing "messages7 between ~he 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 o~ 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 lOllO 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 systems using CS lOllO's
UID addressing~
,~
: .
:
,. ., ~.
'.::' '
, .. ,. . - , - ~ .
... . . . . . ...
, . . . . . . . . .
. ~ . .
, . ~ .
., ,, ". ;.,
~ " ; . . ,, ~ ~:
~; `
~7~7~
;~ ~158-
: Effectively, U~ addressing means that the address
~or memory) space of a particular CS 10110 includes the
:. address space of all systems, for example disc drive~ or
-~ other CS 10110sj to which that particular CS 10110 has
:~ s access. UID addressing allows a~y process in a~y CS
10110 to obtaln access to any object in any CS 10110 to
~: which it has phy~ical access, for example~ another CS
:~ 10110 on the other side of the world. This access is
:::` constrained only by CS 10110's protection mechanism. In
~- 10 alternate embodiments of CS 10110~ certain UIDs may be
set aside for use only within a particular CS 10110 and
may be unique only within that particular CS 10110.
These reserved UI~s would, however, be a limited group
known to all CS 10110 systems as not having uniqueness
15 between systems, so that the unique obj ect addressing
capability of CS 10110's U~D addressin~ is preserved.
~ As previously stated, AONs and physical descriptors
.~ are prasently used for addressing within a CS 10110,
~:~ effectively as shortened UIDs. In alterna e embodiments
20 of CS 10110, other forms of AONs may be used, or AONs may
be discarded entirely and UIDs used for addres~ing within
:~ as well a~ between CS 10110s.
:~ CS 10110's addressing mechanisms are also based upon
- the use of descriptors wi~hin and be~ween C5 10110s.
2~ Each descriptor includes an AON or UID field to identi~y
a particular object, an offset field to specify a bit
granular offset within the object, and a length field to
specify a particular number o~ bits beginning at the
specified offset. Descriptors may also include a type,
~ 30 or ~ormat f ield identifying the particular format of the
- ':
.
; . - . ,, . - ,
?" ~
, , , . , : , : :. ~ :
.
-, : : . : . ,, :. , ... :
~;~7'~6
-159-
'
data referred to by the descriptor. Physical descriptors
are used for a~dressing MEM 10112 and, in this case, the
AON or UI9 field i8 replaced by a rame number ield
: ra~erring to a physical loca~ion in ~E~ 10112.
; 5 As stated above, descriptors are used for addressing
` within and between the separate, independent proces~ors
;: (FU 10120, EU 10122, M~M 10112, and IOS 10116) comprising ~:
`. CS 10110, thereby providing common, system wide bit
~ granular addressing which includes format information.
.: 10 In particular, MEM 10112 responds to the type information
: fields of descriptors by performing ~ormat~ing operations
:~ to provide requestors with data in ~he format specified
by the requestor in the descriptor. MEM 10112 also
accepts data in a format specified in a descriptor and
reformats that data into a format most ef~iciently used
; :~
by ME~ 10112 to store the data.
As previously described, all operands are referred ~o
~ in CS 10110 by Names wherein all Names within a
: ~ particular S-Language dialect are of a uni~or~, fixed
: 20 size and format. A R value specifying Mame size is
provided to FU 10120, a~ ~ach change in S-Language
:~ dialect, and is used by PU 10120 ln parsing Names from
.. ~
.~ the instruction stream~ In an alternate embodiment of CS
.~ 10110, all Wames are the same size in all S-Languase
dialects~ 50 that g values, and the associated circuitry
~' in FU 10120's parser, are not required~
, . . .
".. , ~.
,. .
,'',. `
,~ .
, .
.
, : .
~. :
.;
, .
:. ;. :~ ' ~' . ; :
- ~ . .
.
.. , .. :: ;
,, . ,. :,,
7~
--160-- -
Finally, in descriptions of CS 10110 ' s use of SOPs,
FU 10120's microin~truction circuitry was described as
storing one or more S -Interpreters. S-Interpreters are
sets of sequences of microinstructions for interpreting
5 the SOPs of various S-La~guage dialects and providing
corresponding sequences of microinstructions to control
. CS 10110~ In an alternate embodiment of. CS 10110, these
: ~ 5-Interpreters (SITT 11012) would be stored in ~E~
10112 . FU 10120 would receive SOPs f rom the instruction
10 stream and, using one or more S-Interpreter Base ~oin~ers
` ~ (that is, architectural base pointers pointing to the
SITT 11012 in MEM 10112), address the SITT 11012 stored
in ME~ 10112. ME~I 10112 would respond by providing, from
the SITT 11012 in MEM 10112, sequences of
.~i 15 microinstructions to be used directly in controlling SS
.' 10110. Alternately, the SI~T 11012 in MBM 10112 could
:: provide conventional instructions usable by a
:~ conventional CPW, for example, Fortran or machine
language instruction~. This r for example, would allow FU
: 20 10120 to be replaced by a conventional CPU, such as a
~- Data General Corporation Eclipse3.
:~ Having briefly summarized certain features of CS
10110, and alternate embodimen~s of certain of these
~eatures, the structure and operation af CS 10110 will be
25 described in detail below.
,~:
.:,
7 .
, 'i,`
,. ... .
~'
.. .
~;
'' : '' ' : ' ~.:,.: : -'-
,:',' : . .. :
- ~ : :
: :
,, ' ,:
-161
` 2
~_=~
~ aving previou~ly described the overall structure c~nd
operation of CS 10110, the struc~ure and operation of CS
5 10110's major subsystems will next be individually
described in furthec detail. As previously discussed, CS
10110's major subsystems are, in the order in which they
~;~ will be descrihed, ~E~ 10112, FU 10120, EU 10122, 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
corresp~nding to that shown in Fig. 101~ For the
:: 15 purposes of the following descrlptions, it is assumed
:: that Figs. 201 through 205 have been assembled as shown
in Fig~ 206 to construct such a block diagram. Further
diagrc~ms will be presented in following descriptions as
: required to convey structure cmd operation of CS 10110 to
~ 20 one of ordinary skill in the art.
.. ~ As previously described, ME~ 10112 is an intelligen~,prio~tizing memory having separate and independent ports
MIO 101~8 and MJP 10140 to, respectively, IOS 10116 and
JP 10114. MEM 10112 is shared by and is accessible to
25 both JP 10114 and IOS 10116 and is the primary memory of
CS 10110. In addition, MEM 10112 is th~ primary path for
information transferred between the external world
(through IOS 10116) and JP 10114,
,",~
., :
.: .
,
' `~
- : . ~
"; ' " ' ' '',''",`, ;,
. .
,`: : ,
,
~~ ~a. P ~
~ 7
-162-
As will be described further below, MEM 10112 is a
two-level memory providing fast access to da~a stored
therein. ME~ 10112 ~irst level is comprised of a large
s~t of random acces~ arrays and M~M 10112 second level i5
comprised o a high speed cache ~hose op~ration is
generally transparent to memory users, that is JP 10114
and IOS 10116. Information stored in MEM 10112, in
either level, appears to be bit addressable to both JP
10114 and IOS 10116. In additionf ME~ 10112 presents
simple interfaces to both JP 10114 and IOS 10116. Due to
a high de~ree of pipe lining (concurrent and overlapping
memory operations) MEM 10112 interfaces to both JP 10114
and IOS 10116 appear as if each ~P 10114 and IOS 10116
have full access to MEM 10112. This feature allows data
transfer rates o~ up to, ~or example, 63.6 megabytes per
second from MEM 10112 and 50 megabytes per second to MEM
10112.
In the following descriptions, certain terminology
used on those descriptions will be introduced fir~t,
followPd ~y description o~ ME~ 10112 physical
organization~ Then MEM 10112 port structures will be
described, followed by descriptions o~ MEM 10112's
control organi~ation and control flow. Next, MEM 10112's
interfaces to JP 10114 and IOS 10116 will be described.
Following these overall descriptions the major logical
structures o~ MEM 10112 will be individually described,
~ `:
~ starting at ME~ 10112's interfaces to JP 10114 and IOS
,','.,
,~. .
.. . : .
: - . - : :. .- ~ . . .
,. ' ' ' "' ~ .
' , ' , ' : , ' ' .
.
7 ~7
-163-
.
10116 and proceeding inwardly to MEM 10112's ~irst (or
` bulk) level of data stored~ ~inally, certain features of
; MEM 10112 microcode control structure will be describedO
; A.
a~ ~go~$U~h~5L
Certain terms are used throughout ~he following
descriptions and are definad here below for reference by
the reader.
~ A word is 32 bits o~ data
: 10 A byte is 8 bits of da~a
~: 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
7 bits of starting bit address are equal to zero, that is
: 20 ~he 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
2ero, the starting bit addre~s points to a`boundary
between adjacent words~ A by~e aligned starting bit
~5 address means that the low order 3 bits of starting bit
address are zero, the starting bit address points to a
boundary ~etween adjacent bytea.
: ,
:
'
,::
'', :'`'
: ... . :, .. . . ~ .- : .
.
7'~7
~16~-
Bit granular data has a starting bi~ addre~s falling
within a byte, but not on a byte boundary, or ~he address
i~ aligned on a byte boundary but the len~th of the data
. is bit granular, that is not a multiple o~ 8 bits,
b. ~
~` Referring to Fig. 201, a partial block diagram of MEM
10112 is shown~ Majar functional units o~ MBM 10112 are
: Main Store Bank (MSB) 20110, including ~emory Arrays
(MA's) 20112, Bank Controller (~C) 20114, Memory Cache
: lO (MC) 20116, including Bypass Write ~ile (B~F) 20118,
Field Isolation Unit (FIU) 20120, and Memory Interface
Controller ~ ) 20122.
: ` ~SB 20110 comprises ME~ 10112's first or bulk level
: of storage. MSB 20110 may include from one to, for
15 example, 16 M~ 20112's~ Each MA 20112 may have a storage
capacity, for example, 2S6 K-byte, 512 R-byte, 1 M-byte,
or 2 M-bytes of storase capacity. As will be described
~ further below, ~A 20112's of different capacities may be
:. used to~ether in MSB 20110. Each MA 20112 has a data
20 input connected in parallel to Write Data (WD) Bus 20124
. . ~
and a d~ta output connected in parallel to Read Data (~D)
~us 20126. MA's 20112 also have control and address ports
~i . connected in parallel to address and control (ADCTL) Bus
:~ 20128. In particular, Data Inputs 20124 o~ ~emory Arrays
: 25 20112 are connected in parallel to Write Data (WD) Bus
~;: 20126, and Data Outputs 20128 of Memory Arrays 20112 are
connected in parallel to Read Data (RD) Bus 20130.
''''' '
~ '
:,
"'`, .,
.,
,. . ~ . . . ~ ~ .:
.
.
'~ ' '` ` ' ' ~ ,
,
. .,, ~
-165-
Control Address Ports 20132 of ~emory Arrays 20112 are
connected in parallel to Address and Control (ADCTL) Bus
20134.
Data Ou~put 20136 of ~ank Con~roller 20114 is
connected to W~ Bus 20125 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.
~C 20114's Data Input 20142 is connected to MC 20116's
Data Output 20144 through Store Bac~ Data (SBD) Bus
., .
~ 10 20146. BC 20114's Store Back ~ddress Input 20148 is
: connected to MC 20116 Store Back Address Output 23150
hrough Store Back Address (SBA) Bus 20152. ~C 2Q114's
Read Data Output 20154 is connected to MC 20116'9 Read
:~ Data Input 20156 through Read Data Out (~DO) Bus 20158.
.~ 15 BC 20114's Control Port 20160 is connected to ~emory
.~ 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 thxough MJP Port 10:L40. Control Port 20170 of
1 20 MC 20116 is connected to MCNTL Bus 20}64. Input 20172 of
BYF 20118 is connected to IOM Bus 10130 through MIO Port
` 10128, and Output 20176 is connected to SBD Bu~ 20146
through Bypass Write In (B~I) Bus 20178.
~ Finally, FIU 20120 has an Output 20180 and an Input
: 25 20182 connected tr respectively, MIO Bus 10129 and IOM
: Bus 1013a through ~IO Port 10128v Input 20184 and Port
20186 are connected to, respectively, JPD Bus 10142 and
. MOD Bus 10144 through MJP Port 10140~ Control Port 20188
is connected to MCNTL Bus 20164. Referring f inally to
., .
. 30 MIC 20122, MIC 20122 has Control Port 20190 and Input
... .
.;
~,"-,'.
. :'" '
, ,
. :: .
: ~ : , ' , . ' ', ,: . .
., ,. . ' ~ : .
11~7'~L7~
20192 connected to, respectively, IOMC Bus 10131 and IOM
Bus 10130 through MIO Port 10128. Control Port 20194 and
Input 20196 are connected, respectively, to JP~C Bus
10147 and Physical Descriptor (PD) ~us 10146 through MJ~
5 Port 10140. Control Port 20158 i5 connec~ed to MCNTL Bus
201~4.
,, c. ~=~
Referring first to MEM 10112's interface to IOS
10116, this interface includes MIO Bus 10129, IOM Bus
lQ130~ and IOMC Bus 10131. Read and Write Addresses and
data to be written into MEM 10112 are transferred from
. IOS 10116 to MEM 10112 through IOM Bus 10130~ Data read
from MEM 10112 is transferred to IOS 10116 through MIO
.`~ Bus 10129~ IOMC 10131 is a Bi-directional Control bus
- 15 between ME~ 10112 and IOS 10116 and/ as described further
below, transfers control signals between MEM 10112 and
IOS 10116 to control trans~er of data between MEM 10112
.~ and IOS 10116O
MEM 10112's interace to JP 10114 is MJP Port 10140
and includes ~PD Bu 10142, MOD Bus 10144, PD Bus 10146,
: and JPMC Bus 10147~ Physical descriptors, that is ~E~
10112 physical read and write addresses, are transferred
from JP 10114 to MEM 10112 through PD Bus 10146. S Ops,.
that is se~uence~ of S Ins~ructions and operand name~,
25 are transferred from ~EM 10112 to JP 10114 through MOD
Bus 10144 while data ~o be wri~ten into MEM 10112 from JP
10114 is transferred from JP 10114 to ME~ 10112 through :
:: ~PD Bus 10142. JPMC Bus 10147 is a By-directional
~ .
,~
.
, .
.
.. . . .
- . , ~.
, . . . .. .
,, , . . : , . . -
.
,- ~
, ' :
, . .
,
'. :
; ~167~
Control bus or transferring command and control signals
between MEM 10112 and JP 10114 for controlling transfer
of data between MEM 10112 and JP 10114. As will be
:~ described further below, ~JP Port 10140, and in
particular MOD Bus 19144 and PD Bus 10146, is generally
:~ physically organized as a single port that operates a~ a
dual port. In a first case, MJP Port 10140 operates as a
Job Processor Instruction (JI) Port for transferring S
: Ops from MEM 10112 ~O JP 10114, In a second case, ~OD
10144 and PD 10146 operate as a Job Processor Operand
~0) Port for transfer of operands, from ~qEM 10112 to JP
: 10114, while JPD Bus 10142 and PD Bus transfer operands
from JP 10114 to MEM 10112.
eferring to MSB 20110r MSB 20110 contains MEM
: ; lS lQ112's first, or bulk, level o storage capacity. ~SB
20110 may contain from one to, for exampler 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 R:ilo-bytes, 1 ~ega-bytes, or
20 2 ~ega-byt~s. MEM 10112 may therefore have a physical
~', capacity of up to, for example, 16 Mega-bytes of bulk
: stora~e. A~ will be described further belo~ MA 20112's
of different capacity may be used together in MSB 20110, ~;
for e~ample, four 2 Mega-byte MA 20112's and four 1 ~ega
. 25 byte MA 20112's.
.,
.;
,, ~, ~ '
, : .
.,
",
:'
.. .. . . . .
.. . ..
; -, ...................... . ~ .: . '
~ , ' ' , ' ~ '
~ 6
-16B-
BC 20114 controls operation of ~A's 20112 and i~ the
path for transfer of data to and ~rom ~A's 20112l In
addition, BC 20114 performs error detection and
: correction on dat transferred into and out of MA's
s 20112, re~reshes data stored in ~L~'s 20112, and, during a
refresh operations, performs error detection and
correction of data s~ored in ~A's 20112.
MC 20116 comprises MEM 10112's second, or cache,
level Gf storage capacity and contains, for example 8
~; l0 Rilo-bytes of high speed memory. MC 20116, including BYF
20118, is also the path for data transfer between MSB
20110 (through BC 20114~ and JP lG114 and IOS 10116. In
general, all read and write operations between 3P 1011
and IOS 10116 are through MC 20116. IOS 10116 may,
however, perform read and write operations of complete
; ~ blocks by-passing MC 20116. Bloc~ write operations from
IOS 10116 are accomplished through BYF 20118 while block
read operations are performed through a data transfer
path internal to MC 20116 and shown and described below~
2~ All read and write operations between ME~ 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
... 25 write data regi~ters for receiving data to be written: in~o MEM 10112 from JP 10114 and IOS 10116, and circuitry
: for manipulating data read from MSB 20110 so that MEM10112 appears as a bit addressable memory. FIU 20120, in
, :
.,
~' '"
., .
: ., ~ ..
.. . . .
,: ~ ' ' ' . ' '.~ , , .
~Lt7~-7~
9--
... .
addition to providing bit addressability of ~EM 10112,
~ performs right and left alignment of data, zero fill of
: data~ sign extension operations, and other data
. ~ manipulation operations descr1bed further below. In
performing these data manipulation operations on data
read from ME~ 10112 to JP 10114, MOD Bus 10144 is used as ~:
a data path internal to ~EM 10112 for transferring o~
". da~a from MC 20116 to F~U 20120,and from FIU 20120 to MC
20116. That is, data to be transferred to JP 10114 is
~. :
; . 10 read from ~C 20116, transferred through MO~ Bus 10144 to
FIU 20120, manipulated by ~ïU 20120, and transferred from
. FIU 20120 to JP 10114 through MOD Bus 1014~.
~: MIC 20122 contains circuitry controlling operation of
~EM 10112 and, in particular, controls ME~ 10112's
:. 15 interface ~ith JP 10114 and IOS 10116. MIC 20122
receives ME~ 10112 read and write request, that is read
and write addresses through PD Bus 10146 and IO~ Bus
- 10130 and control signals through JP~SC Bus 10147 and IOMC ':
'; Bus 1û131, and provides control signals to BC 20114, MC
~: 20 20116, and FIU 201~0 through MC~TL Bus 20164.
- Having described the overall structure and operation
Of MEM 10112r the stru~ture and operation of ~EM 10112's
.` - Port, ~IO Port ~0128, and MJP Port 10140, will be
;`~ described next, followed by deqcriptions of ~EM 10112's
25 control struc~ure and the contxol and flow of MEM 10112
i~ read and write requests.
;,.
,:., .
,,
: - ,
: .,
, ."'i ,;
"
.:;
., ,
.
:, : , ,: . , . :
,, . ~ , ,
~,,, ' ' : ~
7~i6
~170-
d. !~ 4~ =~s~
MEM 10112 port struc~ure is designed to provide a
; simple interface to JP 10114 and IOS 10116. While
.; providing fast and ~lexible operation in servicing MEM
: 5 10112 read and write requests from JP 10114 and IOS
10116. In this regard, MEM 1011~ as will be de~cribed
`. 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 addi~ion MEM 10112 is capable of
performing bit granular addressing, block read and write
operations~ and data manipula~ions, such as alignmen~ and
fillingr to enable JP 10114 and IOS 10116 to operate most
.~
: ef~iciently.
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 ~O Ports,
,
described above, to ~P 10114 These three ports share
~ the entire address base of MEM 10112, but IOS 10116, for
~ example, may b~ limited from ~taking full use of MEM
20 10112's address space. Each port has a differe~t set of
~:~i allowed operations. For example, JO Port can use a bit
.granular addresse~ but can reference only 32 bits o~ data
: on each requestO JI Port can make read requests only to
word align 32 bit data items . IO Port may ref erence bit
.~ 25 granular data, and, as described ~urther below, may read
or write up to 16 bytes on each read or write request.
: ~ . The characteristics of each of these ports will be
.. ~ discussed next below.
, .
~ .
. :,. ' . .
.: .
" , . , .
. ' .' : .. ', ~' ,:
.: , .
:' ,, '' ~
, .
~,' ~ . . . ~ ,
7~;~
171-
1. ~ _
IOS 10116 may acces~ ME~I 10112 in either o~ two
modes" The fix~t mode is block transfers by-passing or
through ~he ca he in MC 20116, and the second is non-
block t3:ansfer through the cache and MC 20116.
Bloclc by-passes may occur for both read and write
operations. 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 b~ a control signal indicating that an
encache (load into MC 20116's cache) opera~ion is to be
perf ormed . A by -pass operation takes place only if the
block address, that is the physical address of the block
in ME~ 10112 does not address a currently encached block,
that is the block is not pr`ese:nt in MC 20116 ' s cache . If
the block is encached in MC 20116 ' s cache, the read or
write transfer is to MC ~û116 ' s cache.
Partial block references, tha~ is non-~ull block
transfers will go through MC 20116's cache. If a cache .
miss occurs, that is the reference data is not present in
MC 20116's cache, ME~ 10112's control structures transfer
the data to or from MSB 20110 and update MC 20116's
cache. It should be noted that partial blocks may be as
short as one byte, or up to 15 bytes long. A starting
byte address may be anywhere within a block, but the
partial block ' s length may not cross a block boundary .
-5
.
': '
' ','' -' ' ' '
.
. :' .
., ,
~ .''' ' ''' ~ ' '' ' . , ' ' '~' ' " ' . " '' ' - ' '
: ' .. , ' ' ' : ', ''
.. . ' , ' , ' ', :
.,. , , . : , . .. .
,,
`, ' '. ' ,' , " ' ~ . :
'' ' , '' , :
'; ' , , :
,
766
-172-
Bit length ~ransfers, that is transfers o~ data items
: having a length of 1 to 16 bits and not a multiple of a
byte, or where address i5 not on a byte boundary, go
through MC 20116's cache. These operations may cross
byte, wordr or block bou~daries but may no~ cross page
boundaries. These specii~ operations re~ue~ted by IO
:` port determines whether a read or write request is a
.
partial block or bit length transfer.
2. ~9t~s$l=~l~L:~=t~
. 10 All read or write requests from JO Port must ~o
: through ~C 20116's cache; by-pass operations may not be
performedO The data transferred between M~M 10112 and JP
10114 is always 32 bits in length but, of the 32 bits
~: passed, from zero to 32 bit- may be valid data. JP 10114
~; 15 determines the location of valid data within the 32 bits
by referring to certain FIU specification bits provided
`; as part of the read or write request. As will be
described further below, FIU speci~ication bits, and
other control bits, are prov~ided to MIC 20122 by JP 10114
20 through JP~C Bus 10147 when each read or write request is
: ~ made.
i:~ While MEM 10112 does not perform block by-pass
operations to JP 10114, ~EM 10112 may perform a cache
read through operation. Such operations occur on a JP
25 10114 read re~ue~t wherein the requested data is not
present in ~C ~0116's cache. I~ the JP 10114 read
request is for a full word, which i5 word aligned, MEM ~ .
, . . .
'... ,:
, .
.~,
s .
r
.. . . . .
~ - .- . :
i . .~, .,
' ' ' ' ~ . . . ,
.~ . : " . ~ :
~17~76~;
,~
-173-
10112's Load ~anager, discussed below, transfers the
requested data directly to JP 10114 while concurrently
loading the requested data into ~C 20116's cache. This
:~ operation is referred to as a "hand~off" operation.
S These operations may also be performed by IO Port for 16
bi~ half words aligned~on the right hand half word of a
32 bit wordr or if a full block is handed left and loaded
~; into MC 20116's cache.
. 3- ~L=~ 5~ L~ ==S~
.- 10 All JI Port requests are satisfied through MC 20116's
cache; MEM 10112 does not perform by-pass operations to
JI PortO JI Port requests are always read requests for
full-word aligned words and are handed off, as described
above, i~ a cache miss occurs; In most other respects,
15 JI Port requests are similar to JO Port requests. :~ .
~aving described the overall structure and operation ~ :
: of ~E~ 10112, including MEM 10112's inpu~ and output
ports to JP 10114 and IOS 10116, ME~ 10112's control
structure will be described next belowO
-~ 20 e~ ~a~5b~_L~ e= =~ d 9~ AO
, Referring to ~ig. 207, a more detailed block diagræm
`~ of MIC 20116 is shown. Fig. 207 will be referred to in
conjunction with Fig. 201 in the following discussion of
~EM 10112's control structure.
: ,,, 1. 0~5~
-................... Referrin~ rirst to Fig. 207, MCNTL Bus 20164 is
~: represented as including MCNTL-BC Bus 20164A, MCNTL-MC
:
Bus 20164B, and MCNTL-FIU ~us 2016~C. Buqes 20164A,
. ,
,
. . .
:..
. . ., -
.. '~. .
: .. ,. : , . . ... .. . . ~
.. . . . . ~ . .
. . ,: , - . : ~
: . .. - ,. :
:. ' . '
.
7~7
~: ~17~-
. .
20164B, and 20164C are branches of ~CNTL ~us 20164
connected to, respectively, BC 20114, MC 20116, and FIU
; 20120. Also represented in Fig. 207 are PD Bu~ 10146 and
~ JPMC ~us 10147 to JP 10114, and IOM BU5 10130 and IOMC
: 5 Bus 10131 to IOS 10116.
JO Port Address Register (JOPAR) 20710 and JI Port
Addres~ Register (3IPhR) 20712 have inputs connected from
PD Bus 10146. IO Port Address Register (IOPAR3 20714 has
an input connected from IOM Bus 10130~ Port Control
Logic (PC) 20716 has a bi-directional input/outputs
connected from JPC 10147 and IO~C Bus 10131~ By-pass
Read/Wri.~e Control Logic (BR/WC) 20718 has a bi-
:~ directional input/output connected from IOMC Bu~ 10131.
Outputs of JOPAR 20710, JIPAR 20712~ and IOP~R 20714
are connected to inputs of Port Request ~ultiplexer
~ (PRMUX) 20720 through, respecl:ively~ Buses 20732, 20734,
`` 20736. PRMUX 20720's output in turn is connected to Bus
.~ 20738. Branches o~ Bus 20738 are connected to inputs of
~ Load Pointers (LP) 20724, Mis~; Control (~IISSC~ 20726, and
:. 20 Re~uest ~anager tRM) 20722, and to Buses MC~TL-MC 20164B
and MCNTL-FIU 20164C~
Outputs of PC 20716 are connected to inputs o~ JOPAR
20710, JIPAR 20712, IOPAR 20714, PRMUX 207~0, and LP
20724 through Bu~ 20738. Bus 20740 is connected between ~ :
an input/output of PC 20716 and in input/output of RM
20722.
""''
.: '
. ~,
.
. . . .
,:,
:. ~
. . .. ~ ,. :: .. : :
:. : .; ., . ~ ~:
. ,.''' ': ,'~
,, .
,
~ ~7~7~6~
: -175-
An ou~put of ~R/WC 20718 is connected to MCNTL-MC ~us
20164~ through Bus 20742. Inputs of BX/WC 20718 are
eonnected from outputs of RM 20722 and Read Queue (RQ)
; 207~8 through, respectively, Buses 20744 and 20746.
X~ 20722 has outputs connected to MCNTL~BC Bus
20164A, MCNTL-FI~ Bu~ 20164C, and input of MISSC 20726,
.~ and an input of LP 20724 through, respectively, Buses
20748, 20750, 20752, and 20754. MISSC 20726's output is
connected to MCNTL-BC Bus 20164A. Outputs of LP 20724
are connected to MC~TL-~C Bus 20164B and to an input of
LM 20730 through, respectively, ~uses 20756 and 20758.
. RQ 20728's input is connected from MCNTL MC Bus 20164B
;~ ~hrough Bus 20760 and RQ 20728 has outputs connected ~o
:;, an input of LP 20724, through ~us 20762, and as
-~. previously described to an input of BR/WC 20718 through
`.`~ 15 Bus 20746. ~inally, LM 20730's output is connected to
MCNTL-MC Bus 20164B through Bus 20764.
aving described the structure o~ MIC 20716 with
reference to Fig. 207, and having previously described
,~ the structure of ME~ 10112 with reference to Fig. 201 r
- 20 MEM 10112's control structure opera~ion will next be
~ described with reference to both figure~ 2Ql and 207.
.~ 2. ~LllbLL2~C ==9~ c-e~
.
. ~ Referriny first to Fig. 207, JOPAR 20710, JIPAR
~ 20712, and IO~R 20714 are, as previou~ly described~
:. :. 25 connected from PD ~us 10146 from JP 10114 and IOM 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 addre~ses ~or
....
,
: .
-
, . .
.. . . .
,
,. .
,
,
~E~7~766
-17 6
subsequent service by ~EM 10112. A~ will be de~cribed
further below, these address inputs from JP 10114 and IOS
10116 include FIU information specifying what data
manipulation operations must be performed by FIU 20120
before requested data is transferred to the requestor or
written into ME~ 10112, information regarding the
: destination data read from ~EM lQ112 is to be provided
to~ information regarding the type of operation to be
performed by MEM 10112, and informa~ion regarding operand
0 leng~hO Request address information received and stored
in JOPAR 20710, JIPAR 20712, and IOPAR 20714 is retained
therein until MEM 10112 has initiated service of the
~- corresponding re~uests. MEM 10112 will accept further
. request address in~ormation into a given port register
:- 15 only after a previous request into that port has been
serviced or aborted. Address in~ormation ou~puts from
. JOPAR 20710, JIPAR 20712, and IOPAR 20714 is transferred ~.:
through PRMUX ~0720 to Bus 20738 and from there to RM
... 20722,~MC 20116, and FIU 20120 as service of individual
. 20 re~uests is initiated. ~s will be described below, this
address i~formation will be transferred through PR~UX
X0720 and Bus 20738 to LP 20724 for ~se in servicing a
cache miss upon occurrence of a MC 20116 miss.
PC 20716 receives command and control signals
pertinent to each requested memory operation from ~P
.: 10114 and IOS 10116 through JPMC Bus 10147 and IOSC Bus
10131. PC 2~716 includes request arbitration logic and
:',
' ~;;
. ~
, - , , , :: ,
. . .
.. . .
' ' ~ ,' ~ ' ', , ,
~17~'~66
-177~
,
port state logicf Request arbitration logic determin~s
the sequence in which IO, JI, ~O ports are servic~d, and
;:
when each port i5 to be serviced. In determining the
sequence of port service, request arbi~ration logic usas
5 present port state information for each port from the
port state logic, information from JPMC Bus 10147 and
IOMC Bus 10131 regarding each incoming request, and
information from R~ 20722 concerning the present state of
operation o~ MEM 10112, Port s~ate.logic s~l~cts each
10 particular port to be serviced and, by contro} sisnals
through Bus 20738, enables transfer o~ each port's
request address information from JOPAR 2n710, JIPA~
20712, and ~OP~ 20714 through PR~UX 20720 to Bus 20738
for use by the remainder of M~ 10112 ' s control logic in
~, 15 servicing the selected port. In addition to re~uest
information received from JP 10114 and IOS 10116 through
JPMC ~us 10147 and IOMC Bus 10l31, port state logic
utilizes information from R~ 20722 and, upon occurres~ce
of a cache miss, from LM 20730 (for clarity of
~ 20 presentation, this connection is not represented in ~ig.
- l 207) . Port state logic al50 controls various por~ state
~lag signals, for example port availability signals,
~ signals ind icating valid requests, and signals indica~ing
.` that various ports are waiting ser~ice.
~1 20722 control~ execution o~ service for each
request. RM 20722 is a microcode controlled "micro
machine" executing programs called for by requested MEM
101i2 operations. Inputs of R~ 2û722 inclu~e request
addres~ information from IOPAR 20714, JIPAR 20212, and
f. : ~.
.,
"
~,
:.`
,'~ ' ` .
. .
' ' '
. ~ , '; , . ''. ~ '
~, ' , ' ' ' ` ' ', , ' .
.
~L~L79~76~;
--1 7 8--
JOPAR 20210, including information regarding the type of
ME~ 10112 operation to be performed in s~rvicing a
particular request, interrupt signals from other MEM
10112 control element.~, and, for exampl~, start signals
from PC 20716's request arbitration logic, ~M 20722
; 5 provides control signals to FIU 20120, MC 20116, and most
other parts of MEM 10112's control structure.
Referring to Fig. 201, ~C 20116's cache is, for
b example, an 8 ~ilo-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 recently used by JP
- 19114 or IOS 10116. MC 20116's cache, described further
below, includes tag store comparison logic for
determininy 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 in~ormation regarding missed cache reference~, foc
- example modify bits and replacement page numbers. Inputs
o 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),
''~' ' :.
:, .
,
, ~
, . , . . ~ . . .~
,
- ,:.,,.~j
~7~761
--1 7 9--
the data requestors ~JP 10114 and IOS 10116), and a MC
20116 Write Back File (described ~urther below).
As previously described, FIU 20120 include~ logic
n~c~ssary to make MEM 10112 appear bit addressable. In
. 5 addition, FI~ 20120 includes logic for performing certain
.- data manipulation operations as required by the
;~ requestors (JP 10114 or IOS 10116~. Data is trans~erred
into FIU 20120 from MC 20116 through that portion o~ MOD
Bus 10144 internal to MEM lûll2, is ~anipulated as
required, and is then transferred to the requestor
through MOD Bus 10144 or MIO Bus 10129. In the case of
writes re~uiring read-modify-write of encached data, the
.~ data is transferred back to MC 20116 through ~OD Bus
10144 a~ter manipulation. In general, data manipulation
. 15 operations include locating relquested data onto selected
.:`' MOD Bus 10144 or MIO Bus 10139 lines and filling unused
bus lines as speci~ied by the requestor. Data inputs to
.. FI~ 20120 may b~ provi~ed ~rom MC 20116 or JP 10114
through ~OD Bus 10144 or from IOS 10116 through IOM Bus
20 10130. Data outputs from FIU 20120 may be provided to MC
20116, JP 10114, or IOS 10116 through these same buses.
C~ntrol information îs provided to FIU 20120 from RM
: 20722 through Bus 20748 and MCNTL-FIU Bus 20164Co
Address information may be provided to FIU 20120 from
: 25 JOPAR 20710, JIPAR 20712, or IOP~R 20714 through PRMUX
20720, Bus 20738, and MCMTL-FIU Bus 20164C.
.:
: . .
''. .
,
.. .
. I
.,;, ~ .
. .
., , , , . ~ ,.. ~ .
.. . . . . . . .
':' ,' ' '. , ` ' : ' ~ '
.
.::, , ' : '
-180-
Returning to Fig. 207, ~ISSC 20726 is used in
handling ~C 20116 misses. In the event of a request
referring to data not in ~C 20116's cache, MISSC 20726
, ~ stores block address o tha reference and type of
:~ S op~ration to be performed, this informa~ion being
: provided from an address register in MC 20116 and from RM
20722. MISSC 20726 utilizes this inor~ation in
.~ generating a command ~o BC 20114, through MCNTL-BC Bus
.; 20164A, for a data read from MSB 20110 to obtain ~he
referenced data, BC 20114 places this command in a
queue, or register, and subsequently executes the
commanded read operation. MISSC 20726 also generates an
~ entry into RQ 20728 (described further below) indicating
: ~ the type of operatio~ to be plerformed when referenced
, ~ 15 data is subsequently read from ~S~ 20110G
RQ 20728 is, for example, a three-level deep queue
s oring information indicating operations associated with
~:: . data being read ~rom MSB 20110. Two kinds of operation
~; ~ may be indic ted: block by-pass reads and cache loads.
.~^ 20 Xf a cache load is specified, that is a read and s~ore to
~ MC 20116~s cache, is indicated, R~ 20722 is interrupted
: and ~orced to place other MEM 10112 operations in idle
;`~ until cache load is ~ompleted. A block by-p~ss read
~: operation results in by-pass read control (described
.~- 25 below) assuming control of the data from MSB 20110.
'- Inputs to RQ 20728 are control signals from RM 20752,
, MISSC 20726, and BC 20114. RQ 20728 provides control
': ~
.
.
!
~: '
.
-
.
:; . .
~,' : " :
7~;
,
~ -181-
. .
: QUtpUtS ~0 LP 20724 (described below) LM 20730 (described
below) RM 20722, and by-pass read control (described
below)~
LP 20724 is a set of regi~ers for storang
information necessary for servicing MC 20116 misses that
result in order to load ~C 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
include the address of the missing reference, provided
.~ from JOPAR 20710, JIP~R 20712, or IOPAR 20714 through
:: PRMUX 20720 and Bus 20738, commands from RM 20722, and a
control signal from RQ ?0728O LP 2072~ outputs include
addresses of missed references to MC 20116, through Bus
: - 15 20756 and MNCTL-MC 20164B, ancl command signals to LM
20730 and BR/WC 20718.
.: L~ 20730, referred to above, controls loading of MC
:`. 20116'~ cache with data from ~ISB 20110 after occurrence
-~ of a cache miss~ RQ 20728, referred to above, indicates,
: 20 for each data read from ~SB 20110, whether the data read
~: is the result of a ~IC 20116 cache miss. If the data is
read from MSB 20110 as a result of a cache miss, LM 20730
:~ proceeds to issue a sequence of con~rol signals for
loading the data ~rom MSB 20110 and its associated
25 address into MC 20116's cache. This data is trans~erred
into MC 20116's cache data store while the block address,
from LP 20724 is transferred into the tag store
`
'.'
,~ -
. '" ': :
.
7~ ~ 6
~182-
(described in the following discussion) of MC 20116 ' s
cach~. If the transfer of data into MC 201161s cache
replaces data previously re~ident in that cache, and that
previous data is "dirty~, that is has been written into
æo as to be different from an original copy of the data
s~ored on ~SB 20110, the modified data resident in MC
20116lS cache must be written back into MSB 20110. This
operation is performed through a Write Back File
~ contained in ~C 20116 and described below~ In the event
.~ of such an operation, LM 20730 initia~es a write back
10 operatian by ~C 20116 and ~C 2011~ f 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 mi5s may result in a "hand-offn, that is a read operation
of a full 4 word block. Handoff operations also may be
of single 32 bit words wherein a 32 bit word aligned word
is transferred from JP 10114 or a 16 bit operand aligned
on th2 right half-word is transferred from IOS 10116. In
; 20 such a handoff operation, LM 7.0730 will send a valid
re~uest signal to the requesting port and a handoff
operation will be performed. O~herwise, a waiting signal :;
will be sent to the requesting port a~d the request will
,.~ re-enter the priority queue of PC 2Q716 for subsequent
; ~ 25 execution. To accomplish these operations, LM 20730
receives input from RQ 20728, (no~ shown in FigO 207 for
. ~ ..
,."~ ,.
,, ,
,,:, ~.
, ~,
:.. . ;
.. ~ .
~, : . .; , ~ ~
... .
. - ~
,, . :~ . . , :,
, . .
' . . ~ . , :
i : 7
,
~' ', "',: , , , , ' '' ~ : "; .. ... ,. ;',: .
~183-
: . .
`; clarity of presentation) and LP 20724~ LM 20730 provides
outpu~s to port state logi o~ PC 20716, to ~C 20116, ~C
20116 ' s Write Back File and ~IC 20116 l s Write Back Address
~:: Register and to BC 20114.
:: 5 Referring to Fig. 201, as previously discu~s~d IOS
20116 may request a full block write operation directly
.~ to ~SB 20110~ Such a by-pass write request may be
honored i~ the block being transferred is not encached in
MC 20116's cache. In such a case, RM 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 signals through IOMC
Bu~ 10131, and load the data block into BYF 20118 and ~C
20116~ ~ISSC 20726 will provide a by-pass write command
to BC 20114, through ~NCTL-PC Bus 20164A. BC 20114 will
- then tanC~er the data block from BYF 20118 and into MA's
20 20112 and MSB 20110.
, As previously described, BYF 20118 receives data ~rom
IOM Bus 10130 and provides da~a output to BC 20114
through BWY Bus 20178 and SBD Bus 20146. BYF 20118 is
. capable of simultaneously accepting data from IOM Bus
- ~ 25 10130 while reading data out to BC 20114~ Control of
wri~ing data into BYF 20118 is provided from BR/WC
20718's By-Pass Write Conkrol logic.
~,,
, ~ -
~.-
, ~ ;, .
~,..
,.:
,
:
, .
~, , ." . .
'':
,
~74~7~i~
IOS 10116 may, as previously described, request a
~ull block read operation by passing MC 2011~'s cache.
In such a case, BR/WC 20718's by-pass read control
handles data transfer to IOS 10116 and genera~es required
hand shaking signals to ~OS 10116 through IOUC Bus
10131~ The data path for by-pass read operations is
through a data path internal to ~C 20116, rather than
through BYF 23118. This internal data path is RDO Bus
20158 to MIO Bus 10129.
A5 previously described, BC 20114 manages all data
transfers to and from MA's 2011~ in MSB 20110. BC 20114
receives requests for d~ta transfers from RM 20722 in an
. ~
internal queue register. All data transfers to and from
MS~ 20110 are full block transfers with block aligned
. 15 addresses. On data write operations, BC 20114 receives
data from BWP 20118 or from ~C: 20116's Write Back ~ile
~` and transfers the data into MA's 20112, During read .
.: operations, ~C 20114 fetches t;he data block from MA's
~; 20112 and places the data bloc:k on RDO Bus 20158 while -
'.. ~ 20 signalling to ~IC 20122 that t:he data is available. As
described above, MIC 20122 traoks and controls transfer
of data and BYF 20118, MC 20116, a~d MC 20116's Write
Back Fil~, and directs data read from MSB 20110 to the
appropriate destination, ~C 20116's Data Store, JP
25 1011~, or IOS 10116.
In addition to the above operations, BC 20114
controls refresh of MA's 20112 and performs error
detection and correction operations. In this regard, BC
20114 performs two error detection and correction
.:
., ,
,: ~
~ . . . .
.:
. . . .
,: , . .
,; , , ~ . , :.
~: . - ....... : ,: , :
, . . : ~. . ..
. .
~, ................. ' '': , : :
,, . , . ,,, . , , . . . ~ j.
~ , . ; , , :
- ~ - ~
~7~
.
1~5-
.~ operations. In the firs~, BC 20114 detects single and
double bit errors in data read from ~SB 20110 and
~ corrects single bit errors. In th~ second, BC 20114
: reads data ~tored in MA's 20112 during refresh operations
and perform single bit error d~tection. Whenever an
.~ error is detected, during either read operations or
; refresh operations, BC 20114 makes a record o~ that error
in an error log contained in BC 20114 ~described further
in a following description). Both JP 10114 and IOS 10116
10 may read BC 20114's error log, and in~ormation from BC
20114'~ 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 transerred to ~P 10114 or IOS 10116 in the
~: same manner as data stored in MSB 20110.
` Referring inally to MA's 20112, each MA 20112
~$ ~ contains an array of dynamic semiconductor random access
::` memories. Each MA 20112 may contai~ 256 ~ilo-bytes, 512
- 20 ~ilo-by~es, 1 Mega-~ytes, or 2 Mega-bytes of data
~:- storageO The storage capacity of each ~A 20112 is
organized as sagmenks o~ 256 ~ilo-bytes each. In
addressing a particular MA 20112, BC 20114 selects that
particular MA 20112 as will be describ~d fulther below.
;,, ~.
y~ 25 BC ~0114 concurrently selects a segment within that MA
~. ~ 20112, and a block o~ 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 transf erred between BC
s
, : : ` ,:' -. : -
,~ .
~" ' '
~ , .' : , .. . - ::
~'' ' ' ' . ~, ' .
~"~/~lh. " ' ''
~ 1747~G
-186-
''' ;
20114 and MA's 20112 during each read and write
operationO Having briefly descri~ed the general
structure and operation of MEM 10112, certain types of
operations which may be performed by MEM 10112 will be
described next below.
fO ~ lit.~ t~3~
; MEM 10112 may perform two general types of
operation. The first type are data transfer operations
and the second type are memory maintenance operations.
10 Data transfer operations may include read, write, and
read and setO Memory maintenance operations may include
read error log, repair block, and flush cache. Except
during a flush cache operation, the existence of MC 20116
~-~ and its op~ration is invisible to the requestors, that is
JP 10114 and IOS 10116.
;` A MEM 10112 read operation transfers data from ~S
10112 to a requestor, either JP 10114 or IOS 10116. A
read data transfer is as~nchronous in that the requestor
cannot predict elapsed time between submission of a
,
memory operation re~uest and return of requested data.
Operation o a requestor in MEM 10112 is coordinated by a
requested data available si~nal transmitted rom MEM
10112 to the requestorO
A MEM 10112 write operation transfers data from
- 25 either JP 10114 or IOS 10116 to MEM 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
. .
,,' :
,`.
: .
."
, ,~,.
:,.
.
':. .
:, . . . . .
, ,, - ~ . . .
;.~
.
., ~ . : :
',. ', ' ~" '' ' . ;'"'`''''"''"''1' .. ~,,.;
, .. . .. .
~17476
87-
~ 10114 has been accepted. JP 10114 may tran~fer data to
~E~ 10112's JO Port whenever a JO Port available signal
-- from MEIq 10112 is present; read data is accepted
immediately without further action or waiting required o~
JP 10114A Word write operation~ from IOS 10116 are
performed in a similar manner. On block write
operations, ho~everr ~OS 10116 is required to wait for a
; data taken ~ignal from ~E~ 10112 before sending the 2nd,
~: 3rd and 4th words of a block.
~EM 10112 has a capability to perform "lock bit"
operations. In such operations, a bit granular read of
the data is performed and the enti`re operand is
transmitted to the requestor. At the same time, the most
significant bit of ~he operand, that is the Lock Bit, is
~ 15 set to one in the copy of data stored in MEM 10112. In
:- the operand sent to the requeC;tor~ the lock bit remains
~`~ at its previous value, '~he value before ~he current read
and set operation. Test and ~iet operation~ are performed
by performing read ana set operations wherein the data
item length is specified to be one bit.
. . . ~
~- As previolusly described, ~EM 10112 performs certain
maîntenance operations, including error detection~ ME~
. ~ 10112's Error Log in BC 20114 is a 32 bit register
containing an address field and an error code f ield. 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 of the data containing the error are stored in BC
~ 20114's Error Log Register~ An interrupt signal
'':
~ '~
~,; - . . , .. - . .: " ~ , - :
~ .. - . -... .. - , . ..
: , ~ . . ~ ., -
. . ..
,
,, , ~ ,
7'~7
-188-
indicating detec~ion of an error is raised at the same
that information regarding the error is stored in the
Error Log. If mul~iple errors occur before Error Log i5
read and reset, the information regarding the first error
5 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 reyuest a read Error Log operation
. ~
referred to as a "Read Log and Reset~ operation. In ~his
operation, ~EM 10112 reads the entire contents of Error
:
Log to JP 10114, resets Error Log Resister, and resets
the interrupt signal indicating presence of an error.
IOS 10116, as discussed further below, is limited to
reading 16 bits at a time from ME~ 10112. It therefore
re~uires 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
~ 20 low order 16 bits of Error Log aLe read to IOS 10116.
i ; MEM 10112 performs repair block operations to correct
., ~
parity or ERCC errors in data stored in MC 20116's ~ache
or in data stored in MA's 20112. In a r~apair block
~ procedure, parity bits for data stored in MC 20116's
,-~ 25 Cache, or ERCC check bi s o~ data stored in MA's 20112,
are modified to agree with the data bits of da~a stored
` therein. In this regard, repaired uncorrectible error~,
: . such as ~wo bit errors of data in MA's 20112, will have
good ERCC and parity values~ Until a repair block
., ~, .
~- ;~, .
,,
.~
,~ : . ,
'~
llti1~7~6
-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 there~ore allow such data to be
read as valid, for example to be used in a data
correction op~ration. 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 MEM 10112's internal operation does not
10 require a read-modified-write procedure. Only byte -
aligned writes of integral byte length data residing in
MC 20116 and word aligned writes o integral word leng~hs
of data in M5P 20110 do not re~uire read-modified-write
operation. By utilizing such write operations~ it is
15 therefore possible to overwrit:e bad data by use of normal
write operations before or instead of repair block
operations.
ME~ 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 ~uch an event, only ~A's
20112 and BC 20114 remain 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 of normal write operations. After conclusion of
these write operations, both JP 10114 and IOS 10116
transmit a flush cache request to ME~ 10112b Upon
.
,................................ .
~ .~
~.',
;
', "..,
~.
, . .
.
. ., ~ .
,
. . .
. ..
"
7 ~7 ~ 6
19Q-
receiving two flush cache requests, ME~ 10112 flushes MC
~0116's Cache so that all dirty data encached in MC
2011~'s Cache i5 transferred into MA's 20112 b~fore power
. . ,
is lost. If only JP 10114 or IOS 10116 is operating, DP
: 5 10118 wlll detec this fact and will have transmitted an
enabling signal (FLUSHOR) to ME~ 10112 during system
initializationO FLUS~OR enable~ MEM 10112 to perform
cache flush upon receiving a single 1ush cache request.
After a cache flush operation, no further MEM 10112
- lO operations are possible until DP 10118 resets a power
failure lock-out signal to enable ME~ 10112 to resume
normal operation~
I Having described MEM 10112.'s overall structure and
`i operation and certain operations which may be performed
by MEM 10112, MEM 10112's interfaces to JP 10114 and IOS
10116 will be described next belo~v
.~ ~
;~ As previously described, ~IJP Port 10140 and ~IO Port
:~ 20 10128 logically function as three independent ports.
~ These ports are an IO Pvrt to IOS 10116, a JP Operand
.~ Port ~o JP 10114 and a JP Instruction Port to JP 10114.
:~ Referring to FigsO 209, 210, and 211, diagramic
r~presen~ations of IO Port 20910, JP Opexand (JPO) Port
21010, and JP Instruction (JPI) Port 21110 are shown
-;
, respectivelyO
;~: IO Port 20910 handles all IOS 10116 requests to ~E~
` 10112, including transfer of both instructions and
:.,
"
, .. .
;; ~ ,
, ~ `
,::
.. .. . . .. . .
, . ;........ .... ... . .
:. , ' ; . . . :
~7~7
191-
:
operands. JPO Port 21010 is used for read and write
operations of operands, for example numeric values, to
and from JP 10114. JPI Port 21110 is used to read SINs,
~ that is SOPs and operand NAMEs, from MEM 10112 to JP
: 5 10114. Memory service requests to a par~icular port are
; ~erviced in the order that the re~uests 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, ~ollowed by ~PO 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 following
15 des~riptionsr ME~ 10112 operat:ions are pipelined. This -
pipelining allows interleaving of requests from IO Port
20910, JPO Port 21010, and JP]: Port 21110, as well as
overlapping service of request;s at a particular port. By
: overlapping operations it is meant that one operation
servicing a particular port begins before a previous
: op~ration servicing that port has been completed.
.. ; 1. ~=3
, ,~
.. Referring first to Fig. 209, a diagramic
represen~ation o~ IO Port 20910 i~ shown. Signals are
~. transmitted between IO Port 20910 and IOS 1011~ through
":: MIO Bus 10129, IOM Bus 10130, and IOMC Bus 10131. MIO
.
,,:, .,
' ' ':
-
- -
": ~ , ~
: :-, ~ . ,
`
; . ; ' `: ~ '
. , . : .
, ~
`~ ~ ~
~i79L7~6
-1 9 2-
Bus 10129 is a unidirectional bus having inputs from ~C20116 and FIU 20120 and dedicated to transfers of data
and instructlons from ME~ 10112 to IOS 10118. IOM Bus
10130 is likewise a unidirectional bus and is dedicated
. 5 to the transfer, from IOS 10118 to MEM 10112~ of read
addresses, write addresses, and data ~o be written into
MEM 10112. IOM Bus 10130 provides inputs to BYF 20118,
FIU 20120, and ~IC 20122c IOMC Bus 10131 is a set of
:~ dedicated signal lines for the exchange oE control
~10 signals between I3S 10118 and MEM 10112.
`.Referring first to MIO Bus 10129, MIO Bus 10129 is a
36 bit bu~ receiving read data inputs from MC 20116's
Cache and from FIU 20120. A single read operation from
~E~ 10112 to IOS 10116 transfers one 32 blt word (or 4
;~15 bytes) of data (MIO~0-31)) and four bits of odd parity
(MIOP(0-3)), or one parity bit: per byte.
Referring next to IOM Bus 10130, a single ~ransfer
from IOS 10116 to MEM 10112 includes 36 bits of
."information which may comprise either a memory request
.~20 comprising a physical address, a true length, and command
bitso These memory requests c~nd data are multiplexed
;,onto IO~ 10130 by IOS 10116.
;.-Data transfers from IOS 10116 to ME~ 10112 each
.;:~comprise a single 32 bit da~a word (IO~(0-31)) and four
i~25 bits of odd parity (IOMP(0-3)) or one parity bit per
byte. Such da~a transfers are received by ei~her BYF
~: 20118 or ~IU 20120.
,..
,......................................................................... .
'~
, .
,,
.
A ' ,
, ' ' ' ; . , . ' ' ' . . . ~.
", ' , ' . ` . ~ ; , ~ ! ' .;
, . ' ~ ' . ' ' ' '
~1 7d~766
--1 s3--
Each IOS 10116 memory request to MEM 10112, as
;
described above, an address fleld, a length field, and an
' ~ op~ration code field. Address and length ~ields occupy
~; the 32 IOM Bus 10130 lines used ~or transfer o~ data to
~E~ 10112 in IOS 10116 write operations~ Length f ield
includes four bits of information occupying bits (IOM(0-
i. 3)) of IOM Bus 10130 and address field contains 27 bits
of information occupyiny bits (IOM~4-31)) of IOM Bus
10130 . Together, address and length f ield specify a
physical starting address and true length of the
particular data i~ em to be wr itten into or read from MEM
10112, Operation code field specifies the type o~
operation to be performed by ~EM 10112. Certain basic
operation codes comprise 3 bits of information occupying
; 15 bits (IOMP (32-36)) of IOM 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 MEM 10112 by IOS 10116 are, together with
their corresponding command code fields, are;
. 20 000 ~ read,
001 ~ read and set,
. 010 - write,
011 = error,
. :~ 100 = read error log (first half),
101 = read error log (second half~ and reset,
110 - repair bloc~, and
111 = flush cache.
f ~
-~
J,~
~; , ~ ,.
~ç ,~ ., , '
:,, ,
s ~ - . , , , j , . ..
: ~ : , . . , , ~
,~ , .
,. . .
~ , .: , ,
,, ~ .
,. . . . . .
~';' .
7 ~ 7 ~ 6
-194-
Two further command bits may specify further
operations to be performed by ~EM 10112~ A fi`rst command
bit, indicates to MEM 10112 during write operations
whether it is desirable to encache the data being written
înto MEM 10112 in MC 20116's Cache. IOS 10116 may set
this bit to æero if reuse of t~e data is unlikely,
thereby indicating to MEM 10112 that ME~ 10112 should
avoid enchachin~ the data~ IOS 10116 may set this bit to
one if the data is likely to be reused, thereby
indicating to MEM 10112 that it is pr ~erable to encache
the data. A second command bit is referred to a C~CLE.
CYCLE command bit indicates to ~EM 10112 whether a
particular data transfer is a single cycle operation,
that is a bit granular word, or a four cycle opera~ion,
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 a~d MEM
. 10112 to coordinate operation of IOS 10116 and MEM
10112. A f irst uch signal i5 Load IO Request ~LIOR)
from IOS 10116 ~-o MEM 10112~ When IOS 10116 wisheq to
. load a memory seques~ into ~EM-10112, IOS 1011~ asserts
LIOR ~o MEM 10112. IOS 10116 must assert LIOR during the
-. same system cycle during which the memory request, that
- 2S is address, length, and command code fields, are valid.
If LIOR and IO Port Available (IOPA) signals, described
-` below, are asserted during the same clock cyle, M M
10112's port is loaded ~rom IOS 10116 and IOPA is
~'"'', ~
:' ' .
:,..
. .
... ~
, -:
. . " .
,, ,,. . . , ,' ~ ~
.. . . .
, ., . , : .
~ ~L7~766
--lg5--
dropped, indicating the request has been accepted. If a
load of a request is attempted and IOP~ is not asserted,
MEM 10112 remains unaware of the reque~t, LIOR remains
active, and the request must then be repeated when IOPA
is asser~ed.
~: IOPA is a signal from MEM 10112 to IOS 10116 which is
: ~ asserted by ME~I 10112 when ~IEM 10112 is available to
accept a new request from IOS 101:16. IOPA may be
asserted while a previous request from IOS 10116 is
completing operation if the address, length, and
.~ operation code fields of the previous re~ue~t are no
longer required by MEM 10112, for example in servicing
bypass operations.
. ~ IO Data 'raken ~TIOMD) is a signal from ~qE~ 10112 to
~; 15 IOS 10116 indicating that ~EM 10112 has accepted data
~? ~ rom IOS 10116. IOS 10116 places a first data word on
:~ IOM Bus 10130 on the next system clock cycle a~ter a
write request is loaded; that is, LIOR has been asserted,
a memory request presented, and IOPA dropp2d. MEM 10112
20 then takes that data word on l:he clock edge beginning the
next system clock cycle. At this point, PIE~ 10112
asserl:s TIOMD 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 ME~ 10112 if
2~ XO Port 20910 was available. On block operations, a
` ; first data word is alway~ taken but a delay may occur
~- between acceptance of fir~t and second words. IOS 10116
, ~ .
', .
, . .
..
",.,
: , . . .
, ~ . .
.
.
.. .
~ . . . .
;.
~'747 ~ 6
-195-
is required to hold the second word valid on IOM Bus
10130 until ~EM 10112 resp~nds wi~h TIOMD to indicate
tha~ the block operation may proceedO
.: Data Available for IO (DAVIO) is a signal asserted by
.~; 5 MEM 10112 to IOS 10116 indica~ing that data requested by
IOS 10115 is available. DA~IO is asserted by ~EM 10112
:~ during the system clock cycle in which ME~ 10112 places
the requested data on MIO Bus 10129, In any single word
: type transfer, DAVIO is active for a single system clock
transfer. In block type trans~ers, DAVIO is normally
active for four consecu ive system clock cycles. Upon
. . ,
event o~ a single cycle "bubble" resulting ~rom detection
and correction of an ERCC error by BC 20114, DAVIO will
remain high for four non-conslecutive ~ystem clock cycles
,
`~ 15 an.d wi~h a single cycle bubblle~ a non-assertion, in DAVIO
` corresponding to the detection and correction of the
`.~ error.
: IO ~emory Inte~rupt (IMI~T) is a signal asserted by
MEM 1011~ to IOS 10116 when BC 20114 places a record of a
: 20 detected error in BC 20114's Error Log, as described
~ above.
: Previous MIO Transfer In~alid ~PMIOI) signal i~
similarly a signal a~serted by MEM 10112 to IO5 10116 ~:
:~ regarding errors in data read from ME~ 10112 to IOS
: 25 10116. If an uncorrectible error appears in such data, -
that is an error in two or more da~a bits, the incorrect
data is read to IOS 10116 and PMIOI signal asserted by :.
,, .
,.- .
"~. ,.
:
;
,: ~
.,
.',
~ .... . ~ , . . :
,. ., : . :. ~ ` ~ ,
` ` ` : ., ' ., , ` ' ,, :. '.
, :,, " , : "
~. , ' . . ', ' .
... .
~17~7~
-197-
MEM 1011~. Correctible, or single bit, errors in data do
not result in asser~ion of PMIOIo ~E~ 10112 will assert
PMIOI to ros 10116 o~ the next system slock cycle
following ~E~ 10112's asser~ion of DAVIO~
EIaving described MEM 10112's interface ~o IOS 10116,
and certain operations which IOS 10116 may re~uest of MEM
10112, certain ME~ 10112 operations within the capability
.~ of the interface will be described next. First, operand
ransfers, for example of numeric data, between MEM 10112
and IOS 10116 may be bit granular with any length from
10 one to sixteen bits. Operand transfers may cross
boundaries within a page but may not cross physical page
boundaries. As previously described, MIO Bus 10129 and
IOM 8us 10130 are capable of l:ransferring 32 bits of data
at a time. The leas~ significant 16 bits of ~hese buses,
. 15 that is bits 16 to 31, will contain right justified data
during operand transfers. The contents of the most
~: significant 16 bits of these buses is generally not
`` de~ined as ~EM 1011~ generally does not perform fill
oeration~ on read operations to IO Port 20910, nor does
~` 20 IOS 10116 fill unused bits during write operations.
During a read or write operation, only those data bits
indicated by length field in the corresponding memory
;~:; request are of significance~ In all cases, however,
parity must be valid on all 32 bits of MIO Bus 10129 and
: Z5 IOM Bus 10130 a
,~ :
..
~,.,
l.. ' '
.
....
,.... .
~, '', , , . '
' " '' .
~j, ~ ' . . , ' ' , .
'
.
,/ i , , "
7~
. -19~~
:. :
: Re~erring to Fig. 204, IOS 10116 includes Data
Channels 20~10 and 20412 ea~h of which will be described
further in a following detailed description of IOS
10116. Data Channels 20410 and 20412 each possess
~5 particular characteristic~ deining c~rtain IO Port 20910
i ~operations. ~ata 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 blocks have byte aligned addresses and lengths of
~:10 1 to 15 bytes; a partial block transfer must be within a
1, ~block, that is not cross block boundaries. A full 4 word
block will be trans~erred between IOS 10116 and MEM 1011~
i iin either case, ~ut only those blocks indicated by length
o~ field in a corresponding M~ 10112 request are of
:15 actual significance in a write operation. Non addressed
bytes in such operations may contain any in~ormation so
long as parity is valid for the entire data transer.
Data Channel 20412 preferably reads or writes 16 bits at :`
a time on double byte boundar:ies. Such reads and writes
~`:. 20 are right justi~ied on ~IO Bus 10129 and IOM Bus 10130.
The most signi~icant 16 bi~s o~ these buses may contain
any informa~ion during such operations so long as parity
` is valid for the entire 32 bits. D~ta Channel 20412
.;~ operations are similar to IOS 10116 operand read and
, ~ 25 wri~a operations with double byte aligned addresses and
:lengths of 16 bits. Finally, instructions, for example ~ :
controlling IOS 10116 operation, are read from ~EM 10112
~ '
:t;:
. , .
,`,"~''' - ', ' ~,
,~ . . .: , . :
. . . . . .
,. , : : :. , ~ :
~: . ~, . . .. . .:
,;. ' , ' , , ,: . ~
, ~ . . :
.s . .
19~-
to IOS 10115 a block at a ~ime. Such operations are
: identical to a full block data read.
Having described the operating chaxacteristics of IO
i~; Port 20910, the operating characteristic~ o~ JPO Port
21010 will be described next.
2. ~St~s~ lf~ cC~ 9
Lb_ ~
~ Referring to ~ig. 210, a diagramic representation of
.~ JPO Port 21010 is shown. As previously describedj, JPO
Port 21010 is utilized for transfer of operands, or
.~ example numeric data, between ~EM 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 clata output from MC 20116
and FIU 20120 to 32 bit MOD Bus 10144, and bi-directional
control inputs and outputs bet:ween MIC 20122 and J~MC Bus
'~ 10147.
Referring first to JP~ Port 21010's read data outpu~
to ~OD Bus 10144, ~OD Bus 10144 is used by JPO Port 21010
. to trans~er data, for example operands, to JP 10114. MOD
Bu~ 10144 is also utili~ed internal to ME~ 10112 as a bi-
~ directional bus to transfer data between MC 20116 and FIU
.:- 20120, In this manner, data may be transferred ~rom MC
. 25 20116 to FIU 201~0 where certain data format operations
~ ~ are performed on the data before the data is transferred
t:; to JP 10114 through MOD Bus 10144. Data may also be used
~ o transer data from FIU 20120 to MC 20116 after a data
,:~ format operation is performed in a write operation. Data
s' ' ' . '
'',~.' -
,. ,~
:. .
, . .
.
: ' ~ . :. ' -
, . .: .. ~ . . .
, , ,
, ~ , .~ :, . '
~ ~L'7~7~ ti
:
-200~
-~ may also be transferred directly from ~C 20116 to JP
10114 through MOD Bus 10144. Xnternal to MEM 10112, ~OD
Bus 10144 is a 36 bit bus for concurrent ~rans~er of 32
: bits of data, M9D Bus 10144 bits (MOD(0-31)), a~d 4 bits
of odd parity, 1 bit per byte, ~OD Bus 10144 bits
: (MODP(0 3)). External to ME~ 10112, MOD Bus 10144 is a
. ~ 32 bit bus, comprising bits (MOD(0-31)~; parity bits are
not read to JP 1011~
', Data is written into MEM 10112 through JP~ Bus 10142
to FIU 20120. As just described, data format operations
may then be performed on this data before it is
transferred rom FI~ 20120 to MC 20116 through MOD Bl~s
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 ME~ 10112 as this
data iis transferred into ME~ 10112.
Memory requests are also tran~mi~ted to MEM 10112
rom JP 10114 through JPD Bus 10142, which op~rates in
~ 20 ~his regaird as a 40 bit bus. Each such request includes
'~ an address field, a length ~ield, an FIU ield specifying
. data formating operations to be performed, operation code
` ~ field, and a destination ciode field specifying
.: destination of data read from MEM 10112. Address field
; - 25 includes a 13 bit phy~ical page number field, (JPP~(0-
12)), and a 14 bit physical page offset field, (JPPO(0-
-~ 13)). Length field includes 6 bits of length
i~ "
t
:s:
i" .,
... .
.
, .
: .
,.,,". , ~.;
.: .
; :
,.
,
' ~ :, . . . .
,. .
:,: ' , . , . :
~, . , . ; ' ' :
:,.; . . ,, . - .
,; . ' . , ' -
, . . . : . . . .
;": . . ~
7~i~
~- -201
information, tJLNG(0-5))~ and expresses true length o~
: the data item to be written to or read from MEM 10112P
.- As JPD Bus 10142 and MOD Bus 10144 are each capable of
tran~ferring 32 bits of data in a single ~E~ 10112 read
or write cycle, 6 bit~ of length information are required
to express true length~ As will be described in a
following description, ~P 10114 may provide physical page
offset and length information directly to MEM lU112,
performs logical page number to physical page number
translations r and may perform a Protection Mechanism
10230 check on the resulting physical page number. As
such, MEM 10112 expects to receive (JPPN(0 12)) later
than (JPPO(0-13)) and (JLNG(0-5)). (JPPO(0-13)) and
;. (JLNG(0-5)) should, however, be valid during the system
15 clock cycle in which a JP 10114 memory request is loaded
into ~EM 10112.
. Operation code field provi.ded to MEM 10112 from JP
~ 10114 is a 3 bit code, (JMC~D(0-2)) specifying an
,. operation to be formed by MEM 10112. Certain operations
20 which JP 10114 may re~uest of MEM 10112, and their
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.
~ .
~,;
,
;.
, -, .: . . . ..
, . . -
' . ' '-- ' ,
,, ... , . , , .. . . ~.
~ . . , -
76i6
--20 2--
Two bit FIU field, (J~IU(0-1) ) specifies data
manipulation operat:ions to be perormed in executing read
and write operations. Among the data manipulation
operations which may be requested by JP 10114, and their
FIU fields, are:
00 - right justified, zero fill;
01 - right iustified, sign extend;
: ~ 10 - left justify, zero ~ill; and,
11 = left justify, blank fill.
~; 10 For write operations, JPO Port 21010 may respond only
to ~he most significant bit of FIU field, that is the FIU
field bit specifying alignmenl~
~inally, destination field is a two bit field ~:
specifying a JP 10114 destinal:ion for data read from MEM -
10112. This field is ignored for write operations to ME~
10112. A first bit of des~ination field, JPMDST,
~` identifies the destination to be FU 10120, and the second
field, EBMDST, specifies EU 10120 as the destination.
~: JP~C Bus 10147 includes dedicated lines for exchange
o~ con~rol sign~ls b~tween JPO Port 21010 and JP 10114.
':~ Among ~hese control signals is Load JO Request (LJOR),
:~ which is asserted by JP 10114 when JP 10114 wishes to .
.~ load a request into ~EM 10112. LJOR is asserted
concurrently with pre~entation 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 reques~ from JP 10114. If LJOR
f.
~, ~ and JOPA are asserted concurrently, MEM 10112 accepts the
;, memory request from JP 10114 and MEM 10112 drops JOPA to
, 30 i~dicate that memory re~uest has been accepted. As
..
; .
. .
,,
~-~7~7~6~;
-203-
'
previously discussed, ~M 10112 may asser~ JOPA while a
previous request is being executed and the PD Bus 101~6
information, that i~ ~he memory requ2st prev~ously
provided concerning the previous request, is no longer
requiredO
If JP 10114 submits a memory r~quest and JOPA is not
asserted by ~EM 10112, ME~ 10112 doe~ not accept the
:~ re~uest 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 th~ other fields of the request, ~E~ 10112 ~ill delay
loading of JPPN field for a particular request until the
next system clock cycle after the request was initially
submit~ed. ME~ 10112 may als0 obtain this JPPN field at
~he same time it is being loaded into the port regicter
by by-passing the port register.
JP 10114 may abort a memory request upon asser~ing
Abort JP Request (ABJR). ABJR will be accepted by MEM
10112 during system clock cyc'Le af~er accepting memory
20 request from JP 10114 anfl ABJR will result in ~ .
~; cance~lation of the requested operation. A single ABJR
` line is provided for b~th JPO Port 21010 and JPI Port
: 21110 because, as dPscribed in a following description,
~E~ 1011~ may accept only a single reque~t from JP 10114,
~ 25 to either JPO Port 21010 or to JPI Port 21110, during a
. .
sinyle system clock cycle.
;,:
r . -~
.
'
~,;, ' ~
~, ' ' ':
': ' ~.
.. . . . .
~ ' ' .
"' . ' . : ' ''':
;. ', ''.
7~7 6
-204--
~. ~
- Upon completion of an operand read operation
requested through JPO Port 21010 ~M 10112 may assert
~:~ either of two data available signals to JP 10114. These
signal~ are data available for FA(DAVFA) and data
available for EB(DAVEB)o As pre~iously described, a part
of e~ch read request from JP 10114 includ~s a destination
field speciying the intended destination of the
-:` requested data. AS will be described further below, MEM ~.
. :: 10112 tracks such destination information ror read
~ 10 re~ue.~-its and returns destination information with a
;l; corresponding information in the form of DAVFA and
.:.- DAVEB~ DAVFA indicates a destination in FU 10120 while
~' DA~EB indicates a destination in EU 1012~. ~E~ 10112 may
also~assert signal zero filled (ZFILL) specifyin~ whether
1 15 read data for ~PO Port 21010 is zero filleid. ZFILL is
-i , valid only when DAVEB is asserted.
.' For JPO Port 21010 write r.equest, the associated
~rite data word should be valid on same system olock
., cycle as t~e request, or one ~itiystem clsck cycle later. ~ :
- 20 Jp 10114 a~serts Load JP Wri~e Data (LJWD) during the
sys~em clock cycle when 3P 10114 places valid write data
on ~PD.Bus 10142.
As previously discussed, when ME~ 10112 detects an
error in servicing a 3P 10114 request ME~ 10112 places a
record of this error in MC 20116's Error Log. When an
~ entry is placed in Error Lo~ for either JPO Port 21010 or.:~ IO Port 20910, MEM 10112 asserts an interrupt flag signal
~. . ..
:, .. .
~.
. `
~', '~.,
~.; .
. ,
, .... . . . .. . ..
,,: . , ,, - , . ~
~''-:; '' . . ,, , ` , : '
:, ~ , - :, .. .
;.. ~ . .
, ~ .
- ~~
76~;
.
.; .
` -205-
indicating a valid Error Log entry is present. DP 10118
detec~s this flag signal and may dlrect the ~lag signal
to either JP 10114 or IOS 10116, or both. IOS 1011~ or
JP 10114 r as selected by DP 10118~ m~y then read and
reset Error Log and reset the flag. The interrupt flag
~; signal is not necessarily directed to the requestor t 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 bi~ of a single data word, is detected in
. 10 a read operation ~he incorrect data is read to JP 10114
and an invalid data signal asserted. A signal, Previous
. MOD Tran~fer Invalid (PMODI), is asserted by MEM 10112 on
the next system clock cycle followin~ either DA~FA or
D~VEB. PMODI is not asserted for single bit errors,
:: 15 instead the data is ~orrected and the corrected data read
;i to JP 10114~
~¢:~ ~aving described JPO Port 21010's structure, and
; characteristics, JPI Port 211:L0 will be de~cri~ed next
; below.
' Reerring to FigO 211, a diagramic representation of
JPI ~ort 21110 is shown. JPI Port 21110 includes an
address input ~rom PD Bus 10146 to FIU 20120, a data
output to MOD Bus 10144 from MC 20116, and bi~directional
,:. control inputs and outputs from Mrc 20122 to JPMC Bus
10147. As previously describedl a primary function of
JPI Port 21110 is the transfer of SOPs and operand NAMEs
~!',';',, from MEM 10112 to JP 10114 upon request from JP 10114.
'-?`
.':
' ' '
',~,", ~
!
~?
~" '''
s., . . :
!,~ . . ,~ .
~ 7~6
.~ ~20~- :
.. ~
JPI Port thereby per~orms only read operations wherein
each read operation is a transfer of a single 32 bit word
having a word aligned address.
Ref~rring to JP~ Port 21110 input from PD Bus 10146,
: 5 read requests to M~M 10112 by JP 10114 for SOPs and
operand NAMEs each comprise a 21 bit word address. As
described abover each ~PI Port 21110 read oparation is of
a single 32 bit word~ As such, the five least
signif icant bits of address are ignored by MEM 10112.
. .
.~ 10 For the same reason, a JPI Port 21110 request to ~E~
10112 does not include a length field, an operation code
~ieldr an FIU ~ield~ or a destination code field.
Length, operation code r and F~:U code fields are not
required since JPI Port 21110 performs only a single type
`.15 o~ operation and dçstination code ield i5 not required
~`~because destination is inherent in a JPI Port 21110
,,
request.
The 32 bit words read from MEM 10112 in response to
JPI Port 21110 requests are transferred to JP 10114
through MC 20116's 32 bit output to MOD Bus 101440 As in
:the case of JPO 21010 read outputs to JP 10114, JPI Port
:
illlO does not provide parity information to JP 10114.
~Control signals exchange between JP 10114 and JPI
.~Port ~1110 through JPMC Bus 10147 include Load JI Request
;25 (LJIR) and JI Port Available (JIPA), which operate in the
: same manner as discussed with reference to JPO Port
~. 21010. As previously described, JPO Port 21010 and JPI
:
':: '
..
~'" .
~,
': .' - , ' ' : . .. ~ -
,
~, :. , .
.
,. ~ . : . .. :
7~ 6
-207-
Port 21110 share a single Abort JP Request (ABJR)
command. Similarly, JPO Port 21010 and JPI Port 21110
share Previous ~OD Tran~fer Invalid (PMODI) ~rom ~EM
10112. As described above, a JPI Port 21110 request does
not include a destin tion field as destina~ion is
: implied. MEM 10112 does, however, provide a Data
- Available Signal (DAVFI) to JP 10114 when a word read
from MEM 1011~ in response to a JPI Port 21110 request is
present on ~OD Bus 10144 and valid.
Having described the overall structure and operation
o ~EM 10112, and the structure and operation of ME~
10112's interace to JP 10114 and IOS 10116, the
, ,~ . . .
structure and operation of FI~ 20120 MEM 10112 will nex~
: be described in further detail
h ~IL~IL~ Y~ 2~=22~1
~ As previously described, E~IU 20120 performs certain
:~ data manipulation operations, including those operations
. necessary to make ME~ 10112 bi.t addressable. Data
5.: ~ manipula~ion operations may be perormed on data being
writ~en into ME~ 10112, for example, JP 10114 through JPD
Bus 10142 or ~rom IO9 10116 through IOM Bus 1913G. Data
manipulations operations may also be performed on data
. ~ belng read from ME~ 10112 to JPD 10114 or IOS 10116. In
case of data read to JP 10114, MOD Bus 10144 i5 used both
as a MEM 10112 internal bus, in transferring data ~rom MC
i 20116 to FIU 20120 for manipulation, and to transfer
5 ~
" .
, ~ .
r, ~
t. .,
:, ' :
i:' ' ' ~:
~',.,~
/r , ' ' , ' ' '' `'''" '': . ' : . ; , . . '
.
~; ';
~' ' " ' . . .
"' ' ' ~
~L~.7~7~i~
-~08-
manipula~ed data ~rom ~EM 10112 to JP 101140 In case of
data read to IOS 10116, ~OD Bus 10144 is agaln used as
~EM 10112 internal bus to read data from MC 20116 to FI~
20120 or subsequent manipulation. The manipulated data
. 5 is then read from ~U 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
~our distinct operations, and FIU 20120 may manipulate
data in any possible manner which may be achieved through
i:~ performing any combination of these operations. These
four possible operations are ~election of data to be
manipulated, rotation or shift.ing of that data, masking
~: 15 of that data, and transfer of that manipulated data to a
. selected destination. Each Fl:U 20120 data input will
. comprise a thirty-two bit dataL word and, as described
~ above, may be selected from input provided ~rom JPD Bus
:. 10142, MOD Bus 10144, and IOM Bus 10130. In certain
; 20 cases, an ~IU 20120 data input may comprise two thirty-
: two bit words, for example, when a cross word operation
ls performed generating an output comprised of bits from
~:: each of two different thirty-two bit words. Rotation or
~:: shifting of a selected thirty-~two bit data word enables
; ~ 25 bit~ within a selected word to be repositioned with
respect to word boundaries. When u~ed in conjunction
~-~ with the masking operation, described momentarily,
.~ rotation and shifting may be reiterably performed to
,:
,;-.
.,
::;
.. .
~;-,,
,,~: , . . . . . .
~,': ~, , , '. ' ~ :
.~,
"
7~;
-209-
:
tran~er any ~elected bits in a word to any selec~ed
locations in that word. As will be described further
below, a masking operation allows any selected bits of a
word to be affectively erased, thus leavin~ only cer~ain
5 other selected bits, or certaln selected bits to be
forced to predete.rmined values. A masking operation may
be performed, ~or example, to zero fill or sign extend
. ~ por~-ions of a thirty-two bit word. In conjunction with a
; rotation or shifting operation, a masking operation may,
.: lO for example, select a single ~it 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 of ~IU 20120 i9 a thirty-tw~ ~it data word
s~ and, as described above, may be transf erred on to ~OD Bus
10144 or onto MIO 3us 10129.. As will be described below,
: selection of a particular sequence of the above four
operations to be performed on a particular data word is
: ` determined by control inputs provided from MIC 20122.
These control inputs from ~IC 20122 are decoded and
~-~ 20 executed by microinstruction con~rol logic included
. within FIU 20120.
~ Referring ~o ~ig. 230~ a partial block diagram of ~IU
.: 20120 is shown~ As indit:ated therein, FI~ 20120 includes
Data Man.ipulation Circuitry ~DMC) 23010 and FIU Control
Circuitry ~FIUCj 23012~ Data Manipulation Circuitxy
23010 in turn includes FIUIC) circuitry (~IUIO) 23014,
,-~ Data Shifter (DS) 23016, Mask Logic (MSR~ 23018, and .
~ As~embly Register ~AR) logic 23020. Data manipulation
", ~,
.~'. ~ ,
.
r : ' ' ', , ' . '
~. . ' ~ ,
3 ~
. . .
, . . .
~L 7~61~
: -210-
.'
: circuitry 23010 will be described first followed by FIUC
23012. In descrbing data manipulation circuitry 23010,
FI~IO 23014 will be described first, followed b~ D5
23016, MSK 23018, and AR 23020, in thak order.
Referring to FIUIO 23014, FIUIO 23014 comprises FIU
, ~ 20120's data input and output circuitry. Job Processor
Write Data Regis~er ~J~DR) 23022, IO System Write Data
` ~ Register (IWDR~ 23024r and Write Input Data Register
RID~) 23026 axe connected from, respectively, JPD Bus
.~ 10 10142, IOM Bus 10130, and MOD Bus 10144 for receiving
.,:
data word inputs from, respectively, JP 10114, IOS 10116,
~; and M~ 20116. J~DR 23022, IWDR 23024 and RIDR 23026 are
:.; each thirty-six bit registers comprised, for example, of
: ~ SN74S374 registersA Data words transferred into IWDR
:~ 15 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 ar~, howevex, as
previously described, thirty-two bi~ data words without
parity. Job Processor Parity Generator (JPPG) 23028
~; 20 associated with JWDR 23022 is. connected from JPD Bus
.- 10142 and g~nerates four bits of pa~ity for each data
.~ input to JWDR 23022. JWDR 23022's thirty--six bi~ input
thereby comprises thirty-two bits of data, directly from
JPD ~us 10142, plus a corresponding ~our bit$ of parity
' from 3PPG ~3028.
~ .
':;
... .
~ .
,.. .
:~'. ',
, :
~, .
~, .
-211~
;~ Data words, thirty-~wo bits of data plus four bits of
. parity, are transferred into JWDR 23022, IWDR 23024, or
: ~IDR 23026 whan, respecti~ely, input enable signals Load
JWD (LJWD), Load IWD (LIWD) or Load RID ~LRID) are
S asserted. LJWD is provided from F~ 10120 ~hile LIWD and
LRID are provided ~rom MIC 20122.
Data words resident in JWDR 23022, IWDR 23024, or
RIDR 23026 may be selected and ~ransferred onto FIU
20120's Internal Data ( B) Bus 23030 by output enable
signals JWD Enable Output (JWDEO), IWD Enable Output
` (IWDEO)~ an RID Enable Output (RIDEO). JWDEO, I~DEO, and
~ RDIEO are provided from FIUC 2301~ described below.
`~ As will be de cribed further below, manipulated data
words from D5 23016 or AR 23020 will be transferred onto,
15 respectlvely, Data Shifter Output (DSO) Bus 23032 or
Assembly Register Output (AS~'RO) Bus 23034 ~or subsequent
transfer onto MOD Bus 10144 or M~O Bus 10129. Each
- manipulated data word appeari,ng on DSO Bus 23032 or ASYRO
Bus 23034 wil~ b~ comprised o 32 bit~ of data plu5 4
bits of parity. Manipulated data words present on DSO
~ Bu~ 23032 may be transferred onto MOD Bus 10144 or MIO
:. Bus 10129 through, respectivel~, DSO Bus To MOD Bus
Driver Gate (DSMO~) 23036 or BSO Bus ~o MIO Bus Driver
.; .
. Gate (DSNIO) 23038. Manipulated data word~ present on
ASYRO Bus 23034 may be transferred onto MOD Bus 10144 or
~: MIO Bus 10129 through, respectively, ASYRO Bus ~o ~OD Bus
D~iver Gate (ASYMOD) 23040 or ASYRO Bus To ~IO Bus Driver
::~ Gate (ASYMIO) 23042. DS~OD 23036, DSMIO 23038, ASY~OD
:
. . . .
..
.. ~
: :. . . -,
., . . ~,! , - -
: ,. . ..
: , . ... . .
.:.. . . .
7 ~
-~12-
: ~3040, and ASYMIO 23042 are each comprised of, for
:? example, SN74S244 drivers. A manipulated da~a word on
- DSO Bus 2303~ be transferred through DSMOD 23036 to MOD
. . Bus 10144 whan driver gate enablP signal Drlver Shift To
:; 5 MOD (DR~S~F~OD~ to DSMOD 23036 is asserted. Similarly~ a
~ manipulated data word on DSO ~us 23032 will be
; transferred through DS~IO 23038 to MIO Bus 10129 when
driver gate enable signal Drive Shift Through MIO Bus
; ~ (DRVS~FMIO) to DSMIO 23038 i5 asserted. Manipulated data
~ 10 words present on ASY~O Bus 23034 may be transferred onto
.. ~ MOD Bus 10144 or MIO Bus 10129 when, respectively, driver
: gate enable signal Drive As~embly To Mod Bus (DRVASYMOD)
to ASYMOD 23040 or Drive Assembly To MIO Bus ~DRVASYMIO)
; to ASYMIO 23042 are as~erted. DRVS~FMO9, DRVS~FMIO,
.- 15 D~ASYMODr and ~RVASYMIO are provided, as described
::. below, from F~UC 23012.
.~: Registers IARM 23044 and B ~ ~R 23046, which will be
~ described further in a following description of DP 10118,
-: are used by DP 10118 to, respectivelyr write data words
~ 2~ onto IB 23030 and to Read data words from MO~ Bus 10144,
.
or example ~anapulated data words from FIU 20120. Data
~ word writt~n into IARM~ 23G44 from DP 10118, tha~ is 32
i~ bits of data and 4 bit~ of parity, will be transferred
onto IB 3us 23030 when register enable output signal IARM
, ~ 25 enable output (~ EO) from ~IUC 23012 is asserted.
Similarly, a data word present on MOD Bus 10144,
,. .
comprising 32 bits of data plus 4 bits of parity~ will be
written into BARMR 23046 when load enable signal Load
.:
^~
,, , - .
, . , . -
-- - - . .
~............. : , . .. :
,- , , . ~
-
-213-
~ARMR (LDBARMR) to BARMR 23046 is asserted by MIC 20122.
A data word written into ~ARMR 23046 from ~OD Bus 10144
( may then subsequently be read to DP 10118. IARMR 23044
.-. and BA~MR 23046 are similar to JWDR 23022, IWDR 23024,
~! 5 and IRDR 23026 and may be comprised, for example, of
....
S~74S299 registers.
.~: Referring finally to IO Parity Check Cir~uit (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 particular, determines
validity of parity and data o~ data words written into
FIU 20120 from IOS 10116. IOPC 23048 generates output
: 15 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,
s~ and Bit Scale Logic ~BSL) 23054. BYNL 23050, P~L 23052,
s ~ 20 and BSL 23054 may respectively be compr.ised of, for
example; 25S10 shifters. B~NL 23050 is connected from IB ~
Bus 23030 for receiving and shifting the 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
25 Bus 23030 to receive and shift the 4 parity bits of a
, :: data word selected and transferred onto IB Bus 23030.
Output~ of BYNL 23050 and PRL 23052 are both connected
onto DSO Bus 23032, thus providing a 36 bit FIU 20120
;' ~
. .,: ::
',f: .'
,j,
; :
~.'
," .,
,,. ~. .
, . ' ' ;': '. '' :
,, :
'` ,,
ri , . . , , ~ :. ,:
r,l, ` , , ,:
~L~74L`7~
-214-
.~
da~a word output direc~ly from ~YNL 23050 and PRL 23052.
BYNL 23050's 32 bit data output is also connected to BSL
23054's input. BSL 23054'g 3~ bit output is in turn
pxovided to MS~ 23018.
A5 previou~ly describedl DS 23016 prforms data
manipulation operations involving shifting of bits within
a data word. In general, data shift opera~ions performed
~- by DS 23016 are rotations wherein data bi~s are right
shifted, with lea t significant bits of data word being
shiftPd into most significant bit position and most
significant bits being translated towards least
significant bit positions. DS 23016 ro~ation operations
are performed in two stages. First stage is performed by
BYNL 23050 and PRL 23052 and comprises right rotations on
a ni~ble basis (a nibble is defined 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 nibble basis may, for example, be performed
when RM 20722 asserts FLIP~ALE~ previously described.
FLIP~ALF is asserted for IOS 10116 half word read
operations wherein the request data resides in the most
significant 16 bits of a data ward from ~C 20116. BYNL
23050 will perform a right rotation of 4 nibbles to
~ransfer the desired 16 bits of data into the least
~ignificant 16 bits of BYNL 23050'~ ou~put. Resulting
BYNR 23050 output, together PRL 23052's parity bit output
would then be transferr~d through DSO 23050 to MIO Bus
10129. In addition to performing data shifting
: . .
~: .;
., .
;
... .. :.
; - . , . ~ :. :.: ~: ..
~ . - . .
'' . .. ,' , . . . ': , ' ., '
., .. . ~ , ;,........ ~
, . . .. . .
- -215-
operations, DS 23016 may transfer a data word, t~a~ is
the 32 bits of data, directly to M5K 23018 when data
manipulation to be performed does not require data
shifting, that is shifts of 0 bits may be performed.
~ 5 Because data bits are shifted by BYNL 23050 on a
:~ nibble basis, the relationship be~ween 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 da~a bits. ::
-. 10 This relationship is true if the data word is shifted in
i multiples of 2 nibbles, that is 8 bits or 1 byteO PRL
~;. 23052 right rotates the ~ parity bits of a da~a word by`~' an amount corresponding to right ro~ation o~ ~he
corresponding 32 data bits in BYNL 23050. Right rotated
outputs of BYNL 23050 and PRL 23052 thereore comprise a
.~ valid data word having 32 bits of data and 4 bits of
. parity wherein tne parity bits are correctly related ~o
, the data bits. A right rotated data word output from
` BYNL 23050 and PRL 23052 may be transferred onto DSO Bus
; ` 20 23032 for subsequent transfer to ~OD Bus 10144 or MIO Bus
I ~ 101~9 as described above. DSO 23032 is used as FIU
20120's output data path for byte write operations and
~-u ~rotate read operations wherein the required
manipulation of a particular data word requires only an
integral numer of righ~ rotations by bytes~ Amount of
~: right rotation o 32 bits of data in BYNL 23050 and 4
bits of parity in PRL 23052 is controlled by input signal
shift (S~FT) (0-2) ~o BYN~ 23050 and P~L 23052. As will
... .
i, `' :'
,.~
, .
.:
',,:
i, ' ' ' - . . .. - . . ~ . . ~ . .. .
~ ................. ` ` . , :
~ :` ''` ' :,: : ` , ,
, ` . ~ .
.
. ' `' .
-~16-
be described below, SHFT ~0-2) is generated, together
with SHFT (3-4) controlling BSL 23054, by FIUC 23012.
BYNL 23050 and PRh 23052~ lik~ BSL 23054 described below,
are parallel shift logic chips and entire rotation
-
~:; 5 operation of BYNL 23050 and PRL 23052 or BSL 23054 may be
performed in a single clock cycle.
~ Second stage of rotatlon is performed by BSL 23054
:~ which, as described abovet receives the 32 data bits of a
~` data word from BYNL 23050. BSh 23054 performs right
rotation on a bit by bit basis with the shift amount
being selectable between 0-3 bitso ThereEore, ~SL 23054
may rotate bits through nibble boundariesO BYNL 23050
-~ ~ and BSL 23054 therefore comprise a data ~hifting circuit
capable of performing bit-by-bit right ro~ation by an
`; 15 amount from 1 bit to a full 32 bit right rotation.
: Referring now to MSK 23018, MSK 23018 is comprised of
: 5 32 bit Mask Word Generators (MWG's) 23056 to 23064.
MSR 23018 generates a 32 bit output to AR 23020 by
~ selectively combining-32 bit rnask word outputs of MWG's
.. : 20 23056 to 23064. Each mask word generated by one of MWG's
23056 to 23064 is e~fectiv~ly comprised a bit by bit
combination of a set of enabling bits and a pre-
.~ determined 32 bit mask word, generated by FIUC 23012 and
~ MIC 20122. MWG's 23058 to 23064 are each comprlsed of
;~ 25 for example, open collec~or NAND gates for performing
these func~ions, while NWG 23056 is comprised of a PROM.
- :
i ~ -
;
.
, ~ - ,,
~".,
~-. ;
~"~,, ,
,
:. ~ , , :
. . .
..
, ~ , .. .
," ~: ' .,, : ~.:,,
476~
~217-
. .
' :
As just described, outputs of ~WG's 23056 to 23064
are all open collector cir~uit.~ so that any selected
combination of mask word outputs from MWG's 23056 to
230~4 may be ORed together to comprise the 32 bit output
: 5 o~ ~S~ ~3018.
MWG 23056 to MWG 23064 generate, respec~ively, mask
word outputs Locked Bit Word (LBW) (0-31), Sign Extended
:: Word (SEW) ~0-31), Data Mask Word (DMW) (0-31), Blank
~: Fill Word (BWF) (0-31), and Assembly Register Output
` 10 ~ARO) (0-31). Referring first to ~WG 23064 and ARO (0-
31), the contents of As embly Re~ister (ASYMR) 230Ç6 in
AR 23020 are passed through MWG 23064 upon assertion of
ena~ling signal Assembly Output Register (AS~MO~). ARO
;; (0-31) is thereby a copy o~ the contents of ASY~R 23066
and MWG 23064 allows the contents of ASYMR 23066 to be
` ORed with the selected combination of LBW (0-31), SEW (0-
31), DM~ (0-31), or BFW (0-31).
, ~; DMW (0-31) from MW~ 23.Q60 is generated by ANDing
- enable Input Data Mask (DMS~) (0 31) with the 32 bit
,~ 20 output of DS 23016. DMSR (0~31~ is a 32 bit enabling
word generated, as described below, by FIUC 23012. FIUC
23012 may ~enerate 4 different DMS~ (0-31) patterns~
... Referring to Fig. 231, the 4 D~SKs (0-31) which may be
;;`- generated by FIUC 20132 are shown. DMSRA (0-31) is shown
in Line A of Fig. 231. In DMSKA ~0-31) all bits to the
leEt of but not including a bit designated by Le~t Bit
.Address ~LBA) and all bits to the right of and not
.including a bit designated by Right Bit Address (RBA) are
,., :
i .
~,; ............. ~
. ~,.,, ~
. .-:
j,.'~:"
, ;. -"
,., :
,; ~
5 ' :'~ ' : , . . - . .
,,', ', ' ' ' '''," ', ' ', ':, . '',' ;', . '~, ,,,,, .;
~, ' ' ' ";. ,' '' ''' '' '; :
, "; ' ' ~ ' ~'': . ', ' ' '. ' ., ' . ' ' , , ' , ' ' ':
~ ~7'~
-~ -218-
0. All bi~s between, and including, those bits
designated by L~A and RBA are l's. D~SKB ~0-31) is shown
~ in Line B of Fig. 231 and is D~S~A (0-31) inverted.
.~ DMS~C (0-31) and D~SRD (0-31) are shown, respectively, in
Lin~s C and D of Fig. 231 and are comprised of, ..
r spectively, all O's or all l's. As ~tated above DMS~
(0-31) is ANDed with the 32 bit output o~ DS 23016. As
such, DMSKC (0-31) may be used, for example, to inhibit
S 23016's output while DMSRD (0-31) may be used, for
~: 10 example, to pass DS 23016's output to AR 23020~ DMSKA
: (0~31) and DMSKB (0-31) may be usPd, for example, to gate
i;.~. selected portions of DS 23016's output to AR 23020 where,
or example, the selec~ed portions of DS 23016's output
may be ORed with other mask word outputs MSR 23.018.
~ .......... 15 ~eferring next to ~WG 23062, MWG 23062 generates BFW
; ~ (0-31) 7 BFW (0-31) is used in a particular operation
: wherein 32 bit data words containing 1 to 4 ASCII blanks
: are required to be generated wherein 1 bit/byte contains
. a logic one and remaining bits con~ain logic zeros. In
this case, the ASCII blank bytes may contain logic l's in
bit positions 2, 10, 18, and 26.
Referring again to Fig~ 231, Line E ~herein shows 32
bit right mask (RMSR) (0-31) which may be generated by
FIUC 23012. In the most general case~ RMS~ contains
~ 25 zeros in all bit positions to the left Qf and including a
'~. bit position designa~ed by RBA. When used in a blank
fill oparation, 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
:''!
r, '''`~'
.
~S -'
., ;~ .
':
r' :'.':,,.
., ., ' ` "', : : ~'' ': ,, :. ' ,, , :
: :::' :. " .' ' ' ': '. '
. ' . ,
~: ' , , ~ , '; : '.''" '
.", , . ' '
-219
containing ASCII blanks; these bytes to the right of RBA
are determined by RMSK (0-31). RMSK (0-311 i5 enabled
through MW& 23062 as BWF (0-31) when ~WG 23062 is enabled
~ by blank f ill (BLNRFI~L) provided from FIU 23012.
:; 5 As described above, I~G's 23058 ~o 23064 and in
particular ~WG's ~3060 and MWG 23062 are NAND gate
~: operations. Therefore, the outputs of MW~s 23056 through
23064 are active low signals. The inverted output of
ASYMR 23066 is used as an output to ASYRO 23034 to invert
these outputs to active highO
. MWG 23058, generating SEW (0-31), is used in
generating sign extended or f illed words . In ign
extended words, all bit spaces to the left of the most
signif icant ~it of a 32 bit data word are f illed with the
~: 15 sign bit of the data contained therein, the lef t most
bits of the 32 bit word are f illed with 1 ' s or 0 ' s
depending on whether that word ' s sign bit indicates ~hat
` ~ the data contained therein is a positive or negative
number .
Sign Select Multiplexor (SIGNSEL) 23066 is connected
.
;`~` to receive the 32 data bits of a word present on IB Bus
~: 23030. Sign Select (SGNSEL) (0-4) to SIGMSEL 23066 i
-- derived from SBA (0-4) j, that is from SBA Bus 21226 from
PR~UX 20720. As previously described, SBA (0-4) is
Starting Bit Address identifying the f irs~ or most
. - signif icant bit of a data word . When a data word
contains a signed number, most signif icant bit contains
sign bit of that num~er. SGNSEL (0-4) input to SIGNSEL
23066 is used as a selection input and, when SIGNSEL is
'~''
"'
.
:
.:
:: .. . :, ,
., . . : . ...
, . .. ~
.. .
.: , , ,
766
2~0-
.~ .
enabled by Sign Extend (SIGNEXT) from FIU 23012, selects
the sign bit on IB Bus 23030 and provides that sign bit
as an input to MWG 23058.
~:~ Sign bit input to MWG 23058 is ~NDed with each bit of
left hand mask (L~SR) (0-31) from FIUC 23012. Referriny
; again to Fig. 231, LMSK (0~31) is shown on Line F
~hereof. L~S~ (0-31) contains all 0's to the right o~
and including the bit space identified by LBA and l's in
all bit spaces to the left of that bit space iden~ified
'oy LBA. SEW (0-31) will there~ore contain sign bit in
all bit spaces to the left of the most significant bit of
the data word present on output of ~WG 23058. The data
word on IB Bus 23030 may then be passed through ~S 23016
: and subjected to a DMSR operation wherein all bits to the
left of the most significant bit are forced to 0. SEW
; (0-31) and DMW (0-31) outputs of MWG's 23058 and 23060
.` may then be ORed to provide the desired find extended
, word outpu~.
~-~ LBW (0-31), provided by ~WG 23056, is used in locked
bit operations wherein ~he most signi~icant data bit of a
data word is in ME~ 10112 forced to logic 1. SIGNSEL (0-
4) is an address input to MWÇ 23056 and, as previously
.~ described, indicates most significant data bit of a data
~; word pres~nt on an IB Bus 23030. ~WG 23056 is enabled by
input Lock (hOCK) 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
~ . ~
': ~
s
~ . " .
s,,~ ~ '
,, ~ ! , ` . ' . `
S'''` ,.
~, , . , , . ~ ''' ,
~` ' " ' ' `:
, ` : ` '
~ .
r~
::11 11 7476~ -
-221-
. ~ then be passed through DS 23ûl6 and ~fWG 23060 to be ORed
with LBW ~0-3l1 so that that data words most significant
dat~ bit is forced to logic l.
Re~erring to AR 23020, AR 23020 includes ASYMR 23066,
5 which may be comprised for example of a SN74Sl75
:~ registers, and Assembly Register Parity Generator (ASYPG)
23070. As previously described, ASY~qR 23066 is connected
~rom PISR 23018 32 bit output. A 32 bit word present on
-~ MS~ 23018's output will be trans~erred into ASYMR 23066
: 10 when ASY~R 23066 i5 enabled ~y Assembly Register Load
: (ASYMLD) from MIC 20122. The 32 bit word generated
through DS 23016 and MSR 23018 will then be present on
SYRO Bus 23034 and may, as described above, then be
transferred onto ~qOD Bus 10144 or MIO Bus 10129. ASYPG
` . 15 230~0 is connected from ASYMR 23066 32 bit output and
,~ will generate 4 parity bits for the 32 bit word presently
on the 32 data lines of ASYRO Bus 23034. A9YPG 23070's 4
bit parity output is bused on the 4 parity ~it lines of
; ASYRO ~us 23034 and accompany the 32 bit da~a word
~:` 2Q present th~reon.
~a~Jing described structuxe and operation of Data
Manipulation Circuitry 23010~ FIUC 23012 will be
~ . . .
described next below.
. Referring again to Fig. 230, FI~C 23012 provides
- 25 pipelined microinstruction con~rol of FIU 20120. Tha~
is, control signals are received from MIC 20l22 during a
first clock cycle and certain of the control signals are
: decoded by microinstruction logic ~o generate further
,:
, :
, .
. . ~.
~, .
,
7~
222- -
: FIUC 23012 control signals. During the second clock
cycle, control signals received and generated during
fir~t clock cycle are provided to DMC 23010, some of
which are fur~her decoded to provide yet other control
signals to control operation of FIUC 230120 FIUC 23012
includes Initial Decode hogic (IDL) 23074, Pipeline
Registers (PPLR) 23072, Final Decoding Logic (FDL) 23076,
and Enable Signal Pipeline Register (ESPR) 23098 with
Enable Signal Decode Logic tEsDL) 23099.
IDL 23074 and Control Pipeline Register (CPR) 23084
of PPLR 23Q72 are connec~ed from control outputs of MIC
20122 to receive control signals therefrom during a first
clock cycle as described above. IDL 23074 provides
~: outpu~s to control pipeline registers Right Bit Address
Register (RBAR) 23086, Left Bit Addres6 Re~ister (LBAR)
:
~ 23088 and Shift Register (SHFR) 23090 of PPLR 23072. CPR
''''.''! 23084 and S~FR 23090 provide control outputs directly to
DMC 23010. As described abov~e these outputs control DMC
~ 23010 durin~ second clock cycle.
: 20 CPR 23084, ~BAR 23086, and LBAR 23088 provide outputs
to FDL 23076 during second clock cycle and F~L 23076 in
turn provi~es certain outputs directly to DMC 23010.
. ESPR 23098 and ESDL 23099 receive enable and control
signals from MIC 20122 and in turn provide enable and
`:~- 25 ~ontrol signals to DMC 23010 and certain other portions
: of MEM 10112 circuitry.
.':-.~, .
: .-
,. ..
.~ . .
,, .~ .
~, .
,. . .. .. .. . . . . ..
- .
.
~., . . : .
,. . . ~ .
..
,
,
,. . . . .
, ~ .
--223--
IDL 23074 and FDL 23076 may be comprised, Eor
!: example, of PROMs. CPR 23084r RBAR 23086, LBAR 23088,
.~ - S~FR 23090, and ESPR 23098 may be comprised, for example
. ~ of SN74S194 registers. ESDL 23099 may be comprised of,
5 ~or example, compatible decoders, such as logic gates.
. ~ Referring first to IDL 23074, Il)L 23074 performs an
initial decoding of circuitry control signals from MIC
20122 and provides furth.. r control signals used by FIUC
~::. 23012 in controlling FIU 20120. II)L 23074 is comprised
.~ 10 of read~only memory arrays Right Bit Address Decoding
.~ Logic (RBADL) 23078, Left Bit Address Decoding Logic
(LBADI,) 23080, and Shi~t Amount Decoding Logic (S~FAMTDL)
-............. 23082. RBADL 23078 receive~ as address inputs, Final
~: Bit Address (~}3A~ (0-4) r Bit Length Number (BLN) (0-4),
`;~` 15 and Starting Bit Address (SBA) (0-4). FBA, BLN and SBA ~:
define, respectively, the final bit, length, and starting
bit of a requested data item as previously discussed with
reference to PRMUX 20720. RBADL 23078 also receives chip
, salect enable signals Address Translation Chip Select
~ 2~ (ATCS) 00, 01, 0~, 03, 04, and 15 from MIC 20122 and, in
i . particular, RM 20722. When FIU 20120 is requixed to
~-~ execute certain MSK 23018 operations, inputs FBA (û-4),
'~ BLN (0-4)~ and S~A (0-4), together with an ATCS input,
.: are provided to RBADL 23078 from MIC 20122. RBADL 23078
. 25 in turn provides outpuk RBA (Right Bit Address) (0-4), ;~ 1whi h has been described above with reference to D~S~ (0- -
,, ~
. 31) and ~MSK (0-31). LB~DL 23080 is similar to RE~ADL
: ~ 2307 8 and is provided with inputs BLN (0-4), FBA (0-4), ..
... .. .
:
: .
~',''' .
,...
-
,. ~
; ., ~:-
, ,
.. :~ . ' . , . . .: . ~
.
, : . : ' . ' ; , '
;' . . . ..
,. . .
~1~47~;~
-224-
SBA (0-4), and ATCS 06, 07, 08, 09, and 05 from MIC
20122. Again, ~or certain MSR 23018 operations, LBADL
23080 will generate Lef~ Bit Address (LBA) (0-4), which
has been previously discussed above with reerence to
DMS~ (0-31) and L~ISK (0~31).
RBA (0-4) and LB~ (0-4~ are, respectively,
~ transferred to RBAR 23086 and LBAR 23088 at start of
! second clock cycle by Pipeline Load Enable signal PIPELD
: provided from ~IC 20122. RBAR 23086 and LBAR 23088 in
turn respectively provide outputs Register Right Address
:~ (RRAD) (0-4) and Register Left Address (RLAD) (0-4) as
address inputs to Right ~ask Decode Logic (RMSKDL) 23092,
: Left Mask Decode Logic (LMSKDL) 23094, and FDL 23076 at
start of second clock cycle. RRAD ~0-4j and RLAD (0-4)
correspond respe~tively to R~A (0~4) and LBA (0-4).
RMSKDL 23092 and LMSXDL 2'3094 are RO~ arrays, having,
as just described, RRAD (0-4) and ~LAD (0-4) as,
respectively, address inputs and Mask Enable (~SKENBL)
rom CPR 23084 as enable inpul:~. Together, ~MSK~h 23092
~-: 20 and L~SKDL 23094 generate, re~pectively, R~S~ (0-31) and
~ LMSK (0-31) to MSK 230187 ~MSK (0-31) and LMSR (0-31)
- . are pro~ided a~ inputs to Exclusive Or/Exclusive Nor
gating (XOR/XNOR) 23096~ XOR/XNOR 23096 also receives
~: enable and selection signal Out Mask (OUTMS~) from CPR
25 ~3084. RMS~ (0-31) and LMSK (0-31) inputs to XO~/XNOR
23096 are used, as selected by OUTMSK from CPR 23084, to
generate a selected DMSK (0-31) as shown in ~ig~ 231.
DMSR (0-31) output of XOR/XNOR 23096 is provided, as
. described above, to MSK 23018.
~,, ,;
,
. .
, "
~''' .
. .
~ ' ..
.
,~, . ,.................................................. '
, , . ~
, .~
7 6
-225~
,
Referring again to IDL 23074, S~FAMTBL 2308~ decodes
certain control inputs from ~IC 20122 to generate~
through SHFR 23090, control input~ S~P~ (0-4) and SGNSEL
(0-4~ to~ respectively, DS 23016, SIGNSEL 23068 and ~WG
23056O Address inputs to the PROMs comp~ising SHFAMTBL
23082 include FBA tO-4), SBA (0-4), and FLIPHALF
(FLIP~ALF3 from ~IC 20122. FBA (0-4) and SBA (0~43 have
been described aboveO FLIP~ALF is a con~rol signal
; .~
; ~ indicating that, as described above, that 16 bits of data
: 10 r~que5ted by IOS 10116 resides in the upper half of a 32
bit data word and causes those 16 bits to be transf erred
: to the lower half of FIU 20120's output clata word onto
, MIO Bus 10129. ~qIC 20122 also provides chip enable
signals ATCS 10, 11, 12, 139 and 14. Upon receiving
,~
~: 15 these control inputs :erom MIC 20122, S~FAMTDL 23082
generates an output shift amount tSHFA~T) (0-4) which,
ogether with S~A (0-4) from ~IC 20122, is transferred
::. into S~FR 23090 by PIPELD at start of second clock
, .
~ cycle. S~FR 23090 th~n provides corresponding outputs
t.`- ' 20 S~FT (0-4) and SIGNSE~ (0 4) . As described above,
SIG~SEL (0-4) are provided to SIGNSEL 23068 and MWG 23056
and MSK 23018. SHFT (0-4) i3 provided as SHPT (0~2) and
~ S~FT (3-4) to, respectively, BYNL 23050 and BSL 23054 and .
::: DS 23016.
s 25 Referrin~ to CPR 23084, as descxibed above certain
control signals are provided directly to FIU 20120
circuitry without being decoded hy IDL 23074 or FDL ~:
23076 . Inputs to CPR 23084 include Sign Extension ~.~
' -: '
.
,.',, ~
.
., .
., .,,
~'',' ~.
, , : . . . .. . . .. . . . .
, . . . . .
~. . :, . . . ..
' ' . , . , ; : , ,
~ ~747~;
--226--
(SIG2~EXT) and Lock (LOCK) indicating, respectively, that
FIU 20120 is to perform a sign extension operation
through ~WG 23058 or a lock bit word operation through
23û56. CPR 23084 provides corresponding outpu~s
5 SIGNEXT and WC~ 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 ou~:put of ~SY~R 23066 as a mask or to
indicate that MSK 23018 is to generate a blank filled
word through ~lWG 23062. Inputs OUTMSK and MS~E~BL ~o CPR
23084 are prov.ided, as discussed above, as enable signals
OUTMSR and MSKENBL to, respectively, EXOR~ENOR ~3096 and
:~ RMSRDL 23092 a~d LMSKBL 23094 and generating XMSR (0-31),
15 LMSK (0-31), and DMSR (û-31) clS described aboveO
:; Referring finally to ESPR 23098 and ESDL 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 MEM 10112
. 20 circuitry. ESPR 23098 ~eceives inputs Drive ~OD Bus
(DRVMOD) (0-1), Drive MIO Bus (DRV~IO) (0-1), and Enable
- Regist~r (ENREG) (0-1) from MIC 20122 as previously
descr ibed . DRVMOD ( 0-1 ), I:)RVMIO ( 0-1 ), and ENREG ( 0-1 )
are transferred into ESPR 23098 by PIPELD as previously
. ;~ 25 described with refererlce to PPLR 23072. E~PR 23098
provides corresponding outputs ~o ESDL 23099, which in
turn decodes DRVMOD (0-1), DRVMIO (0-1), and ENREG (0-1)
: ~o provide enable signals to FIU 20120 and other MEM
,'
.
5 ',
,.: ' ~ ..
' ~
.. , :, ' ' ', . : ' " : : '
:: ' .' , `
:
: : . :
3 ~ 7~i6
-227-
10112 circuitr~. Outputs DRVSHFMOD, DRVASYMOD,
DRVS~FMIO, and DRYASYMIO are provided to DSMOD 23036,
DS~IO 2t038~ ASYMO~ 23040, ASYMIO 23042, and FIUIO 23014
to control transfer of FIU 20120 manipulated data words
~- S on~o MOD Bus 10144 and ~IO Bus 10129. Output~ IARMEO,
JWDEO, IWDEO~ and RIDEO are provided as output enable
signals to IARM~ 23044, ~W~R 23022, IWDR 23024, and RIDR
23026 to transfer the contents of these registers onto IB
Bus 23030 as previously described. Outputs DRVCAMOD,
DRVA~IO, DRVBYMOD, and DRVBYMIO are provided to MC 20116
~: for use in controlling transfer of information onto ~OD
Bus 10144 and MIO ~us 10129.
~aving described the structure and operation of MEM
10112 above, the structure ancl operation of FU lU120 will
be described next below.
. B~ o =--r2-z=~9~s==~ e-=
'
As has been previously described, FU 10120 is an
.` independPntly operating, microcode controlled machine
. ~ .
.~ 20 comprising, together with EU 10122, CS 10110's
micromac.hine for executing user's programs. Principal
functions of F~ 10120 include: (1) Fetching and
interpreting instructions, that is SINs comprising SOPs
and Names, and data from MEM 10112 for use by FU 10120
. 25 and EU 10122; (2) Organizing and controlling flow and
execution of user programs; (3) Initiating EU 10122
operations; (4) Performing arithmetic and logic
; opera~ions on data; (5) Controlling transfer of data rom
., `i , ' ~ .
. ~
': .
',''' , :
,
' ' .
~ ,.... . . . . . . . . . . .. .
. .
.. .. .
s ~ . - . .
.
.
.. . . . .. .
:. - . -
. , .
. . .
66
-~28- .
FU 10120 and EU 10122 ~o MEM 10112; and, (63 Main'caining
certain stack register mechanisms. Among ~hese stack and
register mechanisms are Name Cache (NC) 10226 ~ Address
Translation Cache (ATC) 10228, Protection Cache ~PC)
10234, Architectural Base ~egisters (~BRs) 10364, ~icro-
Control Registers (mCRs) 10366, Micro-Stack (MIS) 10368,
onitor Stack (MOSJ 10370 of ~eneral Register File (GRF)
10354, Micro-Stack Pointer Register Mechanism (~ISPR)
10356, and Return Control Word Stack (RCWS) 10358. In
addition to maintaining these FU 10120 resident stack and
register mechanisms, FU 10120 generates and maintains, in
whole or part, certain MEM 10112 resident data
structures. Among these MEM 10L12 resident data
. .~
.~: structur~s are Memory Hash Table (MHT) 10716 and Memory
~ 15 Frame Table (~FT) 10718, Working Set ~atrix (WS~) 10720,
.
.. j Virtual ~emory Management Reqi~est Queue (VMM~Q) 10721,
~o; Active Object Table (AOT~ 107:12, Active Subject Table
AST) 10914, and Virtual Proclessor State Blocks (VPSBs)
10218. In addition, a primary function of FU 10120 is
the generation and manipula~ion of logical descriptors
: which, as previously described, are the basis of CS
10110's internal addressing structure. As will be
~ described ~urther below, while FU 10120's 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~
~ ........................................................................... .
r ~
~ ;. ', . , '~
' ' ';
. .~ . .
~'`'.,.
i, '
~ ' ''' '' ' "'
5, ~ . :
'': ' '' ,
,,. : :
.: ' ' ' :
::
,, . :
~ 7
-229-
Referring to Fig. 202, a partial block diagr~m o FU
10120 is sho~n. To enhance clarlty of presen~ation,
certain interconnectisns within FU 10120, and between FU
101~0 and EU 10122 and ME~ 10112 are not sho~n by line
connections but, as described further below, are
otherwise indicated, such as by common signal names.
Major functional elements o~ FU 10120 include Descriptor
Processor (DESP) 20210, ME~ 10112 Interface Logic
(MEMINT) 20212, and ~etch Unit Control Logic (FUCTL)
20214. DSP 20210 is, in general, an arithmetic and logic
unit for generating and manipulating entries for ~EM
10112 and FU 10120 resident stack mechanisms and caches,
a described above, and, in particular, for generation
, .
-~ and manipulation of logical descriptors. In addition, as
15 stated above, DSP 20210 s a general purpose Central
processor Unit (CPU) capable of performing certain
; arlthmetic and logic functions.
DESP 20210 includPs AON Processor (AONP) 20216,
Of~set Processor (OFFP) 20218, Length Processor ~LENP~
~- 20 20220. OFFP 20218 comprises a general, 32 ~it CPU with
additional structure to optimize generation and
manipulation o offset fields of logical descriptors.
AONP 20216 and LENP 20220 comprisel respectively,
processo~s for generation and manipulation ~f AON and
length fields of logical descriptors and may be used in
. .
conjuction with OFFP 20218 or execu~ion of certain
arithmetic and logical operations. DE5P 20210 includes
GR~ 10354, which in turn include Global Registers (GRs)
.
~ 10360 and Stack Registers (SRs) 10362. As previously
, . .
, . . .
: ,. .
. :~
'''.,i ,
.. . - - . : . . . .
.. . . , , -
. . - : . -
.
. - - - . . . . . . .
.. . . . . . . ..
: . . : . ~ . .
,. ~: . .
~ ' :~: : '':
-
-230-
-
described, GR's 10360 includes AB2s 10364 and mCRs 10366
::~ while SRs 10362 includes MIS 10368 and ~OS 10370.
~E~INT 20212 comprises FU 10120's interface to MEM
10112 for providing Physical Descriptors (physical
addresses) to ~E~ 10112 to read SINs and data rom and
wrlte data ~o ME~S 10112. MEMINT 20212 includes, among
other logic circuitry, MC 10226, A~C 10228, and PC 10234.
~: FUCTL 20214 controls fetching of SINs and data from
MEM 10112 and provides sequences of microinstructions for
con rol of FU 10120 and EU 10122 in response to SOPs.
FUCTL 20214 provides Name inputs to ~C 10226 ~or
subsequent fetching of corresponding data from ME~
: 10112D FUCTL 20214 includes, 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 stxucture o~ FU 10120,
in particular with regard to previous descriptions in
Chapter 1 of this description, DESP 20210, MEMINT 20212, -
; and FUCTL 20214 will be descri.bed in further detail
-:~ 20 below, and in that order.
: ~ ~5 described above, DESP 20210 comprises a 32 bit CPU
-~ for perorming all usual arithmetic and logic operations
: 25 on data. In addition, a primary function of DESP 20210
... .
is generation and manipulation of entries for, for
example, Name Tables ~NTs) 10350r ATC 10228, and PC
10234, and generation and anipulation of logical
'
:,
:
.,~`
. , .: , , . . . .. , : , . . . .. . , ~, : .
,. ...
,.: ~- :: , -
,: ::
''; ':
,
~ 7 6
; -231~
descriptorsO As previously described, with reference to
,: CS 10110 addressing structure, logical descriptors are
logical addresses, or pointers, to data stored in MEM
:. 10112. LogicaL descriptors are used, for example, as
architectural,,base pointers or mi.crocontrol pointers in
ABRs 10364 and mCRs 10366 as shown in Fig. 103, 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 ~ames appearing in ~ .
,` SINs fetched from MEM 10112 to provide rapid translation ` ',
.~; between operand Names and corresponding logical
descriptors.
~' 15 As has been previously discusised with reference to CS
.'~' 10110 addressing structure, logical descriptors provided
:.J to ATU 10228, from DESP 20210 or NC 10226, are translated
"!' by ATU 10228 to physical descr.iptors which are actual
'`` physical addresses o~ corresponding data stored in ~E~
~ 20 10112. That data subsequently is provided to JP 10114,
:.,, , and in particular to FU 10120 or EU 10122, throug~ MOD ~ -
':',''' ~us lal44~ :
As has been previously discussed with reference to
ME~ 10112, each data read to JP 10114 ~rom ~EM 10112 may
~' 25 contain up to 32 bits of inormation. 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,
- . .,
.' . ,
.. . .
. .. .
: ' ,'
.,
.. . .
.. .
. .' .
. .. . : .-.
-,
. . -.
.
. . . ~
.. . . .
, . ~ , ,: . '
~'' .'~ ' , ..
~ 7~7~
-232-
each logical descriptar re~erring to 32 bits or less of
: information, until the entire data item ~as been read
from ME~ 10112. In this regardr it should be noted that
NC 10226 may contain logical degcriptors only for data
: 5 items of 255 bits or less in length. All requests to MEM
:~ 10112 for data items ~reater tha~ 32 bits in length are
generated by DESP 20210. ~ost of data items operated on
by CS 10110 will, however, be 32 bits or less in length
so that NC 10226 is capable of handling most operand
Names to logical descriptor translations.
As described above, DESP 20210 includes AONP 20216,
OFFP 20218, and LENP 20220. OFFP 20218 comprises a
~neral purpose 32 bit CPU with additional logic
; circuitry for generating and rnanipulating table and cache
entries, as described above, ~md for generating and
manipulating offset fields of AON pointers and logical : :
descriptors. AONP 20216 and ].ENP 20220 comprise logic
: circuitry for generating and manipulating, respectively,
:~ AON and le~gth fields of AON pointers and logical
descriptors. As indicated in Fig. 202, GRF 10354 is
ver~ically divided in three parts. A first part resides
~` : in ANOP 2G216 and, in additon to random data, contain~
~O~ fields of logical descriptors. Second and third
parts residet respectively, in OFFP 20218 and LENP 20220
and, in addition to containing random data, respec~ively
contain offset and length fields of logical descriptors.
AON, Ofset, and length portions of GRF 10354 residing
respectively in AONP 20216, OFFP 20218, and LENP 20220
s ~,,
, .:
. .
", ' .
,"~ ~ .
s.
r ~'
'"' " ' , ' ~ ' , , ~ ' ' ~'
. . . I ~
,'.' '. . ' . '' ~ , ~' ' " , '' ' , , :
.'
'' . . ' ' ' . : .
~'; ' ', ' , . ' ~ ~ '' '
-233-
are designated, ~espectively, as AONGRF, OFFGRF, and
LENGRF. AONGRF portion of GRF 10354 is 28 bit~ wide
while OFFGR~ and ~NGRF portions of GRF 10354 are 32 bits
in width. Although shown as divided vertically into
thre~ parts, GRF 10354 is addressed and operates as a
unitary structure. That is, a particular address
provided to GRF 10354 will address corresponding
horizontal segments of each of GRF 10354's three sections
residing in AONP 20216, OFFP 20218, and LENP 20220.
. ' 10 a.
Referrins first to OFF~ 20218~ in addition to being a
32 bit CPU and generating and manipulating ~able and
cache entries 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 O:Efset Input Select
Multiplexer (OFFSEL) 20238, OFFGRF 20234, Offset
Multiplexer Logic (OFFMUX) 20240, Offset ALU (OFFALU)
20242, and Offset ALU A Input~ Multiplexe~ (OFFALUSA)
202~
OFFSEL 20238 has first and second 32 ~it data i~puts
connected from, respec~ively, MOD Bus L0144 and JPD Bus
10142. OFFSEL 20238 has a third 32 bit data input
connected from a first ou.tput of O~F~LU 20242, a fourth
28 bit data input connected from a first output of AONGRF
20232, and a fifth 32 bit data input connected from
OFFSET Bus 20228. OFFSEL 20238 has a f irst 32 bit output
connected to input of O~FGR~ 20234 and a second 32 bit
:. :
,: ;.
. ~
,
. ~. . .. ' , , :
, ~
^~
7~6
: -~34-
output connected ~o a ~irst input of OFFMUX 20240.
OFFMUX 20240 has secor.d and third 32 bit data inputs
connected from, respectively, MOD Bus 10144 and JPD Bus
; 10142~ OFFMUX 20240 also has a fourth 5 bit data inpu~
connected rom Bias Logic (BIAS) 20246 and LENP 20220,
described ~urther below, and fifth 16 bit data input
. connected from NAME Bus 20224. Thirty-two bit data
~ output of OFFGRF 20234 and first 32 bit data output of
; O~FMUX 20240 are connected to, respectively, first and
` 10 second data inputs of OFFALUSA 20244. A first 32 bit
~ data output of OF~ALUS~ 20244 and a second 32 bit data -
-~ output of ~FFMUX 20240 are connected, respectively, to
.~ first and second data inputs of OFFALU 202420 A second
32 bit data output of OFF~LUSA 20244 is connected to
:. 15 OF~SET Bus 20228~ A firs~ 32 bit data output of OFF~LU
20242 is connected to JPD Bus 10142, to a first input of
.. ~ON Input Select Multiplexer (AONSEL~ 20248 and AONP
2~216, and, as described above, to a third input of
OFFSEL 20238. A second 32 bit: data output of OFFALU
~ ~ 20242 is connected to OFFSET Bus 20~28 and third 16 bit
.~ output is connected to MAME Bus 20224.
~ b. ~
.~ Referring to AONP ~0216, a primary function of AO~P
~` 20216 is that of containing AON fields of AQN pointers
. 25 and logical descriptors. In addition, those por~ions of
AONGRF 20232 not otherwise occupied by AO~ poin~ers and
,:
logical descriptors may be used as a 28 bit wide general
regi~ter area by JP 10114. These portions of AONGRF
:
: , ':
~:
'. . ,
7~7
~ 2 3 5~
20232 may be so used either alone or in conjunc~ion wih
-: corresponding port~ons of OFFGRF 20234 and ~ENGRF 292360
AONP 20216 includes AONSEL 20248 and AONGR~ 20232. As
~ previously described, a first 32 bit data input AONSEL
.~ 5 20248 is connected from a fir.qt data output of OFFALU
; 20242. A second 28 bit data input of AO~S~L 20248 is
connected from 28 bit output of AONGRF 20232 and from AON
Bus 20230. A third 28 bit data input of AONSEL 20248 is
~ connected from logic zero, that is a 28 bit input wherein
;: 10 each input bit is set to logic zero. Twenty-eight bit
.: data output of AONSEL 20248 is connected to da~a input of
AONGRF 20232. As just described, 28 bit data output of
AONGRF 2a232 iS ronnected to ~econd data input of AONSEL
20248r and is connected ~o AON Bus 20230.
c. ~s~ 9g~o!~ 2SC- :
: Referring finally to LENP 20220, a primary function
of LENP 20220 is the generation manipulation of length
fields of AO~ pointers and physical descriptorsO In
addition, LE~GRE 20236 may be used, in part, either alone
: 20 or in conjunc~ion with corresponding address spaces of
AONGR~ 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
Length ALU (LENALU) 20252~, LENSEL 20250 has first and
25 second data inputs connected f~om, respectively, LENGTEI
~ ~us 20226 and OFFSET Bus 20228~ LENGTH Bus 2022~ is
:~ eight data bits, zero filled while OFFSET Bus 20?28 is 32
data bits. LENSEL 20250 has a third 32 bit data input
.:
.,''- ~
, : ,
. .
, ~
., . ~ ~ ,
, , :............... ~ , , .
, ~ .
., ~ , .
. . . . .
' ' ' ' ' ~ ,
,
, . .
~O q~
.
~7'4 7
-23 6-
connected from data output of LE~ALU 20252. Thirty-two
bit data output of LENSEL 20250 is connected to data
input of LE~GRF 20236 and ~o A first data input of BIAS
20246. Second and third 32 bit data inputs of BIAS 20246
are con~ected from, respectively, Co~stant (C) and
~ Literal ~L) ou~puts of FnSITT 11012 as will be described
.~ further below. Thirty-two bits data output of LENGRF
:~ 20236 is connected to JPD Bus 10142, to Write Leng~h
~ Input (WL) input of NC 10226, and to a first input of
- 10 LENALU 20252. Five bit output of BIAS 20246 is connected
~-- to a second input of LE~ALU 20252, to LENGTH Bus 20226,
and, as previously described, to a fourth input of OFFMUX
20240. Thi~ty-two bit output of LENALU 20252 is
;~ co~nected, as ctated above, to third input of LENSEL
:~ 15 20250.
aving described ~he overall operation and the
.~ ~tructure of DESP 20210, operation of DESP 20210 will be
described next below in further detail.
: d. ~ 3æ~r~ss~ ~t=D~::5b=~
. 20 a.~. Qf~ s~h~ L~3~
' Re~erring to OFFP 20218, GRF 10354 includes GR's
: ` 10360 and SR's 10362. GR's lU360 in turn contain ABR's
:~- 10364, mCR's 10366, and a se~ o~ general registers. SR's
: 10362 include ~IS 10368 ~nd MOS 10370. GRF 10354 is
.~ 25 vertically divided into three parts. AONGRF 20232 is 28
;:~ bits wide and resides in AONP 20216, LENGRF 10354 is 32
- bit~ wide and resides in LENP 20220, and OFFGRF 20234 is
. 32 bits wide and resides in OFFP 20218. AONGRF 20232,
:'-
.: ~
..
',~":~ :, '
~;
. . . . ~, ,,
,
,,
~.. , ''. : , ' ~
,
- ~ ' .
,~ , :
~ 7
-237-
,, :,
OFFGRF 20234l and LENGRF 20236 may be comprised of
Fairchild 93422s,
~ In addition to storing offset ~ields of AON pointers
- and logical descriptorst those portions of OFFGRF 20234
; 5 not reserved for A~R's 10365, mCR's 10366, and SR's 10362
may be used as general registers, alone or in conjunction
~ wit~ corresponding portions A~NGRF 20232 and LE~GRF
: ~ 20236, when OFFP 20218 is being utilized as a general
:~ purposP, 32 bit CPV~ OFFGRF 20234 as will be describe~
- 10 further belowt is addressed in parallel with AONGR~ 20232
;- and LENGRF 202 6 ~y address inputs provided from FUCTL
20214.
OFFSEL 20238 is a multiplexer, comprised for example
: . ~
of S~74S244s and SN74S257s, for selecting data inputs to
be written into selected address locations of OFF~RF
20234. OFFSEL 20238's irst data input is from ~OD Bus
.. ` 10144 and i5 the primary path for data transfer between ME~ 10112 and DESP 20210. As previously described, each
- ~
: data read ~rom ME~ 10112 to JP 10114 is a single 32 bit
word where between one and 32 bits may contain actual
data. ~f a data item to be read from ~E~ 10112 co~tains
~ more than 32 bits of da a, successive read operations are
; performed until the entire data item has been
`.: trans~erred~
~ 25 OFFSEL 20238'.s second data input is from JPD Bus
.
:. 10142~ As will be described further below, JPD Bus 10142
' i9 a data transfer path by which data outputs of FU 10120
~ and EU 10122 are written into ~E~ 10112. OF~SEL 20238's
,, ,;,
, ~
. .... .
~ . , .
~ . .
i.
,
.
,. . .
' ' ' ' : . ~
i
-238-
input of JP~ Bus 1014~ thereby provides a wrap around
- ~ path by which data pre~ent at outputs of F[J 10120 or EU
10122 may be transferred back into DESP 20210 for further
use . For example, as previously stated a f irst output of
- 5 OFFALU 20242 is connected to JPD Bus 10142, thereby
allowing data output of OFFP 20218 to be returned to OFFP
2Q218 for further proces~ing, or to be transferred to
AONP 20216 or LENP 20220 as will be described urther
: below. In addition, QUtpUt o LENG~F 2023~ is also
connected to JPD Bus 10142 so that length fields of AON
pointers or phy~ical descrlptors, or data, may be read
: from LENGRF 20236 to OFFP 20218. This path may be used,
-~ for example, when LENGRF 20236 is being used as a general
purpose r~gister for ~toring data or intermediate results
; 15 of 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 OF~GRF
20234, either in the same address location as originally
; read from or to a di~ferent address location. OFFP 20218
. ~
wrap around path from OFFALU 20242's output to OFF~EL
20238ls third input, and thus to OFFGRF 20234, may be
utilized, for exampl~, in reading from ~EM 10112 a data
~;.......... 25 item containing more than 32 bits of data. As previously
:~ de~cribed, each read operation from MEM 10112 to JP 10114
i~ of a 32 bit word wherein between one and 32 bits m~y
con~ain actual data. Transfer of a data word containing
, :
.
:,. ~ , .
.
~,. - ,.. .,. , , . :.
~: :
.
?
; . .... . .; . .
',,, ': :. ~ !
3L~'7'~7~i6
-239-
more than 32 bi~s is accomplished by performing a
succPssion of read operations from MEM 10112 to JP
` 10114. For example, lf a requested data item contains 70
5 ~ bits of data, that data item will be transferred in three
-. 5 ~on~ecutive read operations. First and ~econd read
~ operations will each transfer 32 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
ME~ 10112 therefore, DESP 20210 must generate a sequence
:~ 10 of logical descriptors, each defining a successive 32 bi~
segment of that data item. Final logical descriptor of
the sequence may define a sesment of less than 32 bits,
for example, six bits as in the axample just stated. In
each successive physical descriptor, offset field must be
incremented by value o~ length field of the preceding
; physical descriptor to define ~tarting addresses of
successive data items segments to be transferred~ Length
: field o~ succeeding physical clescriptors will, in
general, remain constant at 32 bits except ~or final
transfer which may be less than 32 bits. Offset field
:~ will thereby usually be incremented by 32 bits at each
. transfer until final transfer. OFFP 20218's wrap around
data path ~rom OFFALU 202~2's output to third input of
OF~SEL 20238 may, a~ stated above, be utilized in such
sequential data transfer operations to write incremented
: or decremented offset field o~ a current physical
:
descriptor back into OFFGRF 20234 to be offset field of a
` ~ next succeeding physical descriptor.
.
., ~
.' . . .
,
. , , . . .. .~ . , ~.... .
~:a/ .. ~ rY~
7t~;
:
~ 40-
,~ ~
In a further example, OFFP 20218's wrap around path
from O~FALU 202~2's ou~put to third input o OFFSEL 20238
may be used in rPsolving Entries in Name Table~ 10350,
that ls Name resolutions~ In Name resolutions, as
previously described, offset fields of AON point~rs, for
example Linkage Polnters 10416, are successively added
and subtracted to provide a final AON pointer to a
~ desired data item.
:~ OFFSEL 20238's fourth input, from AONGRF 20232's
sutput, may be used to trans~er data or AON ields from
AONGRF 20232 to O~E'GRF 20234 or OFFMUX 20240. This data
. path may be used, for example~ when OFFP 20218 is used to
generate AO~ fields of AON poin~ers or physical
: descriptors or when performing Name evaluations.
Finally, OFFSEL 20238's fifth data input from OFFSET
, Bus 20228 allows offset fields on OFFSET Bus 20228 to be
: ~ written into OFFGRF 20234 or transferred into O~FMUX
.- 20~40. This data path may be used, for example, to copy
~ , offset fields to OFFGRF 20234 when JP 1oll4 is performing
i 20 a Name evaluation.
. Re~erring now to OFFMUX 20240, OFFMUX 20240 includes
logic circuitry for manipulating individual bits of 32
~:~ bi~ words. OFF~UX 20240 may be used, for example, to
,~` increm2nt and decrement offset fields by length fields
:~:` 25 whe~ per~ormlng string transfers, and to generate entries
~:-;; for, for example, MHT 10716 and MFT 107180 OFFMUX 20240
may also be used to aid in generating and manipulating
. AON, OFFSET, and LENGT~ ~ields of physical descriptors
and AON pointers~
:
',~
:. :
,. .
~,
;, .
; .
, . , , . ::: , ,
:...................... , ., , . , ,. . i
',S',, ,', "'' ''' '~ ~'
.
- . . , ~ ,.
. .
:~ -241
' : ~
, .
. b.b.
Referring to Fig. 238, a more detailed, partial block
diagram of OFF~UX 20240 is ~hown. OFFMUX 20240 includes
. - 5 Offset Mul~iplexer Input 9elector (OFF~UXIS) 23810, which
~or exa~ple may be comprised of SN74S373s and SN74S244s
~; and Offset Multiplexer Register (OFF~UX~) 23812, which
.~ for example may be comprised of SN74S374s. OFFMUX 20240
also includes Field Extraction Circuit (FEXT) 23814,
. 10 which may for example be comprised of S~74S257s, and
~` Offset Multiplexer Field Selector (OFFMUXFS) 23816, which
for example may be comprised of SN74S257s and SN74S374s.
Finally, O~FMUX 20240 ~ncludes Offset Scaler (OFFSCALE)
23818, which may for example be comprised of AMD 2~S10s,
Offset Inter-element Spacing En.coder (OFFIESENC) 23820,
.;
:~" which may for example be comprised of Fairchild ~3427s
and Offset ~ultiplexer Output Selector (OFFMUXOS) 23822,
which m~y for example be comprised of AM~ 25Ss, Fairchild
93427s, and SN74S244s~
::` 20 Referring first to OFF~UX 20240's connections ~o
;, other portion~ of OFFP 20218, OFFMUX 20240's first data ~:
.~ input, from OFFSEL 20238, is connected to a first input
'`~ of OFFNUXIS 23810c OFFM~X 20240's second input, from MOD
.~:; Bus 10144, is connected to a second input of OFFMUXIS
;~ Z5 23810. OF~MUX 20240'~ third inpu~, from JPD Bus 10142,
is connected to a first input of OFFMUXFS 23816 while
OFFMUX 20240's fourth input, from BIAS 20246, is
connected to a fir~t input of OFP~UXOS 23822. OFFMUX
. 20240's fifth input, from NAME Bus 20224, is connected to
.
- .,
i ' .
(; ;
,,,, : :: ' -
~" .
~'. ' ` : ` .
--~4 2-- .
a second input of OF~MUXFS 23 816 ., OFFMUX 20240 ' s f irst
ou~put, ~o OFFAI.USA 20244, is connected from output of
OFFMUXR 23812 while OFFMUX 202401s ~econd output, to
OFFAL~ 20~42, is connected from ou~put of OFFM~XOS 23822
Referring to OFFMUX 20240's internal connections, 32
bit output of OFF~UXIS 23810 is connected to input
OFFMUXR ~-3812 and 32 bit ou~put of OFFMUXR 23812 is
connected, as described above, as first output of QFFM~X
20240, and as a third input of OFFMUXFS 23816. Thirty-
two bit output o~ OFFMUXR 23812 is also connected to
input of FEXT 23814 . OFFMUXFS 23816 ' s f irst, second and
third inputs are connected as described above. A fourth :~
inpu~ of OFFMUXFS 23816 is a 32 bit input wherein 31 bits
are set to logic zero and 1 bit to logic 1. A f ifth
input is a 32 bit input wherein 31 bits are set to logic
1 and 1 to logic 0. A sixth input of OFFMUX~S 23816 is a ~:
32 ~it literal (L) input provided from FUSITT 11012 and
is a 32 bit binary number comprising a part of a
icroins~ruction FUCTL 20214~ described below. O~FMUXFS
23816's seventh and eighth input are connected from F~XT
23814. Input 7 comprises FIU and TYPE fields of ~ame
Table Entri~s which have been read into OFFMUXR 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, OFFMUXFS 23816's first, third,
four~h, 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
" .
.,
,::
, ,
: , ,;
,''','~
,,
.`. ' . '~
;s ~ ",
:
7~7
-243-
firs input comprising bit 0 to 15 of that 32 bit input,
- and a second input comprising blts 16 to 31.
Thirty-two bit output of OFFMUXFS 23816 is connected
to inputs of OFF5CALE 23818 and OFF~ESENC 23820. As
5 indicated in Fig. 238, Field Select Output (FSO) of
ûFFMUXFS 23816 is a 32 bit word divided into a flrs~ word
including 0 to 15 and a second word including bits 16 to
31 . Output FSO of OFFMUXFS 23816, as will be described
further be~ow, thereby reflects the divided ~tructure of
OFFMUXFS 23816's first, third! fourth, fifth, and sixth
inputs.
Logical functions p~rformed by OFFMUXFS 23816 in
generating output FSO, and which will be described in
~; further detail in following descriptions, include:
(1) Passing the contents of OFFMUXR 23812 directly
~; through OFF;~IUXFS 23816;
(2) Passing a 32 bit word on JUD Bus 10142 directly
:~ through OFFMUXFS 23816;
3) Passing a literal value comprising a part of a
microinstruction from FUCTL 20214 directly ~hrough
OFF~IUXFS 23 816;
(4) Forcing FSO to be literal valu~s 0000 0000
(5) Forcing FSO to be li'ceral value 0000 001
:: (6) Extracting Name Table Entry fi~ldst
.~ 25 (7) Accepting a 32 bit word from OFFMUXR 23812 cr
JPD Bus lQ142, or 32 bits of a microinstruction from
;; ~UCTL 20214, and passing the lower 16 bits while forcing
the upper 16 bits to logic 0;
, .
." . ,.
: .,
.,;
/ .~,
,,~ ." ~ , .. . , . . , . . . . .~ . " .
. . . : ~ . .
,, .. , ' ' - ' '- ''. ,' ~ ,
.
s ~.
~1~ 7~ 7
-244-
(8) Acceptin~ a 32 bit word from OFFMUXR 23812 or
~PD Bus 10142, or 32 bits of miroinstruction from FUCTL
20214~ And passing the higher 16 bits while forcing the
lower 16 bits to logic 0 î
(9) Accepting a 32 bit word from OFFMUXR 23812, or
JPD Bus 10142, or Name ~us 20224, or 32 bits of a
microinstruction from FUCTL 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 Name 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 OFFIESFNC 23820 are connected, respectively, to
second and third inputs of OFFMUXOS 23822. OFFMUXOS
23822's first input is, as ciescrib~d above, OFFMUX
20240's fourth input and is connected from output BIAS
20246. Finall~, OFFMUXOS 2~822lS 32 bit output, OFFMUX
(0-31) is OFFMUX 20240lS second output and as previously
;: 20 described as connected to a second input of OFFALU 20242.
- c . c . ~ ~
' :," ~ :
.~ a.a.a~ ~e~ t~=8
-:: Having described the stLucture of O~FMUX 20240 as
shown in Fig. 238, oper~tion of OF~MUX 20240 will be
described below. Internal operation of OFFMUX 20240, as
: show~l in Fig. 238, will be described ~irst, followed by
; description of OFFMUX 20240's operation with regard to
~ DESP 20210.
.:.''..
':
. : :
~'
;.,
.. . . .
;:
.
~'7~7~6
-245--
Referring f irst to OF~MUXR 23812, OFFMUXR 23812 is a
- 32 bit register receiving ei~her a 32 bit word f rom ~qOD
Bus 10144, MOD t0-31), or a 32 bit word received from
OF~SEL 20238, OFFSEL (0-31), and is selected by OFFMUXIS
~ 5 23810. OFFMUXR ~3812 in turn provides ~hose selected 32
:~ bit words from MOD Bus 10144 or OFFSEL 20238 as OFFMUX
20240~s first data output to OFFALUSA 20244, as FEXT
: 23 814 ' s input ~ and as OFF~UXFS 23816's third input.
OFFMUXR 23812's 32 bit output to OFFMUXFS 23816 is
provided as two parallel 16 bit words designated as
- OFF~UXR output (OFFMUXRO3 ~0-15) and (16-31). As
. ~ described above, OFFMUX~S 23816's output to OFFALUSA
~ 20244 from OFFMUXR 23812 may be right shifted 16 places
i ~ and the highest 16 bits zero f illed .
FEXT 23814 r~ceives O~FM~JXRO ~0--15) ~nd (16-31) from
.:
OFFMUXR 23812 and exkracts certain fields from those 16
bit words. In particular, FEXT 23814 extracts FIU and
: ~YPE fields from ~T 10350 Entries which have been
:~: trans~erred into O~F~UXR 23812. FEXT 23814 may then
provide those FIU and TYPE fields as OFFMUXFS 23816's
---seventh input. FEXT 23814 may, selec~ively, extract
certairl other fields from 32 bit words residing in
OFFMIJXR 23812 and providP those fields as OFF~q~XFS
~: 23 816 ' s eighth input .
OFFMUXFS 23816 operates as a multiplexer to seiect
~:~ certain fields from OFFMUXFS 23816's eight inputs and
s: provide corresponding 32 bit output words, Yield Selec~
!,""' Output (FSO)~ comprised of those selected fields from
~'' .
-
~, .
,;. . ,
s, . . ..
. , . ~ :. :: ,
~; . ' ' . . . ': '
;6
2~6-
O~F~UXFS 23816's inputs. As previously described, FSO is
comprised of 2, parallel 16 bit words, FSO (0-15) and FSO
~16~31). Correspondingly, O~FMUX 20240's third inpu~,
from JPD Bus 10142, is a 32 bit input presented as two 16
bit words, JPD (0-15) and JPD (16-31). Similarly~
OFF~UXFS 23816's fourth, ~ifth, and sixth inputs are each
presen~ed as 32 bit words comprised of 2, parallel 16 bit
words, respectively~ "o" (0~15) and (16-31), "1~ (0-15)
and (16-31), and L (0-15) and (16-31)o OFFMUXFS 23816's
second input, from NAME ~us 20224, is presented as a :~.single 16 bit word, NAME (16-31), while OFF~UXFS 23816's
inputs from FEXT 23814 are each less than 16 bits in
width. OFFMUXFS 23816 may, for a ~ingle 32 bit output
word, select FSO (0-15) to contain one of corresponding
16 bit inputs JPD (0-15), It0" (0-15~, "1" (0-15), o~ L
(0-15). Similarly, FSO (16-31) of that 32 bit ou~put
word may be selected to csntai.n one of NAME (16-31), JPD
(16-31), 0 (16-31), 1 (16-31), L (16-31), or inputs 7 and
8 from ~EXT 23814. OFFMUXFS 23816 therefore allows 32
bit words, comprised of two 16 bit fields, to be
generated ~rom selected portions of OFFMUXF5 23816's
inpu~s.
O~F~UX~5 23816 32 bit output i5 provided as inputs to
OFFSCALE 23818 and OFFIESENC 23820, Referring first to
OFFIE5ENC 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
~' .
:
.
' ' , ' ' ' ';,,, ' ' :, ' '' ''' ' ,''. '. ",'''. ~
, , " , . ' ' . ~ . ~' .' ' ~ .
:, . , , ~ . . .. .
-~7-
,
an array. Word D of an NT2 may be read from ~EM 10112 to
MO~ Bus 10144 and through OF~MUX 20240 to input of
OFFIESENC 23820. OFFIESE~C 23820 then examines word D 1 5
IES fiel~ to determlne whether in~er-elemen~ 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
he 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 offset ~ields of physical addresses
of words in the arxay and a slower and more complex
multiplication operation is not required. In such cases,
OFFIESENC generates a first output, IES Encodeable
IESENC) to FUCTL 20214 to inclicate that inter-element
spacing may be determined by simple left shifting.
OFFIESENC 23820 then generates encoded output, Encoded
IES ~E~CIES), to OFFMUXOS 23822. ENCIES is then a coded
value specifying the amount of left shift necessary to
translate index (IES) value into offsets of words in that
array. As indicated in Fig. 238, E~CIES is OFFM~XOS
23822'5 third input.
OF~SCALE 23818 is a left shift shift network with
zero fill o~ least significant bits, as bits are left
shifted. Amount of shi~t by OFFSCALE 23818 is selectable
between zero and 7 bits. Thirty-two bit words
transferred into OFFSCALE 23818 from OFFSCALE 23818 from
- .
,
.
, ~ ;
.` . ,
, . . .
.
.
~ . . , ~ .
, ' ' ' ~ ' ' ,
; . ,
7~7
-~48-
.
OFFMUXFS 23816 may therefore be left shifted, bit by bit,
~; to selectively reposition bits within that 32 bi~ inputword. In conjunction wi~h OF~UXFS 23816, and a wrap
. ~ around c~nneGtion provided b~ OFFALU 20242's output to
OFFSEL 20238, OFFSCAL~ 23818 may be used to generate and
manipulate, for example, entries ~or M~T 10716, MFT
; 10718, AOT 10712, and AST 10914, and other CS 10110 data
.: struc~ures.
' ~ OFFMUXOS 23822 is a multiplexer having first, second,
.~ 10 and third inputs from, respec~ively, BIAS 20246, OFFSCALE
2381~, OFFIESENC 23820. OFFMUXOS 23822 may select any
~ one o~ these inputs a~ OFFMUX 20240's second output~,
r` OFFM~X (0-31), As previously described, OFFM~X 20240's
second output is connected to a ~econd input of OFFALU ?
20242.
: Having described internal of OFFMUX 20240, operationof OFFMUX 20240 with regard to overall operation of D~SP
20210 will be described next below.
. ~ .
:~ b.b~b. 9D~ ~Q~S:b~LL =~
~ .e~ SS AO~
~,'
OFF~UX 20240's first input, ~rom OFFSEL 2~238, allows
~: ~ inputs to OFFSEL to be transferred through OFFMUXIS 23810
i ~ and into OFFMUXR 238120 ThiS input allows OFFMUXR 23812
i ~. 25 to ba loaded, under control of FUCTL 20214
microinstructions, with any input of OF~SEL 20238. In a
' ` particular example, OFFALU 20242's output may be f ed back
r ~ through OFFSBL 20238's third input and OFFM~X 20240's
:
! '
,
~/,"' ', :`
.. . .
, .
,`~ ~ ' '
~ , , . , . . , ~
' '; '` ' . ` '' ` . ` ' ~ . ' ,'~ : ' . :
~'7
-249-
first input to allow OFFMUX 20240 and OFFALU 20242 to
;~ perform reiteratlve operations on a single 32 bit word.
OF~MUX 20240's second input, from MOD Bus 10144,
allows OFFMUXR 23812 to be loaded directly from MOD ~us
10144~ For exa~ple, NTEs from a currently activ~
procedure may be loaded into OFF~UXR 23812 to be operated
upon as described above. In addition, OFFMUX 20240's
second input may be used in conjunc~ion with OFFSEL
20238's first input~ from MO~ Bus 10144, as parallel
input paths ~o OFFP 20218. These parallel input paths
allow pipelining of O~FP 20218 operations by allowing
OFFSEL 20238 and OFFGRF 20234 to operate independently
from OFFMUX 20240. For examp:Le, FU 10120 may initiate a
~ read operation from ~EM 10112 to OFFMUXR 23812 during a
-~ 15 first microinstruction. The da~a so requested will
` appear on MO~ Bus 10144 during a second microinstruction
`~ and may be loaded into OFF~UX]~ 23812 through OFFMU2
20240's second input from MOD ~us 10144~ Concurrently,
FU 10120 may initiate, at start of second
microinstructisn, an independent opera~ion ~o be
- per~ormed by OFFSEL 20238 and OFF~RF 20234, for example
loading output of OFFALU 20242 lnto OFFGRF 20234.
Therefore, by providing an independent path into OFFMUX
20240 from MOD Bus 10144, OFFSEL 20238 is free to perform
other, concurrent data transfer operations while a data
transfer from ~OD Bus 10144 to OFFMUX 20240 is being
~- performed.
. ~
. ,
.
' ''` '
: ~ .
,. . . . ...
~'' , ' ' ' :` ' ~
.
, , . . : .
~ , . ' . ' :
", ~ , .
-250-
; OFFMUX 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
; OFF~X 2~240 through JPD 3u~ 10142 and OFFMUX 20240's
~ 5 third input.
: OFF~UX 20240 ' s fourth input is connected from BIAS
20246 and primarily used during string transfers as
.: described a~ove. That is, length fields of physical
descrip~ors generated for a string trans~er may be
- 10 transferred into OFFMUX 20240 through OEF~UX 20240's
:`~ fourth input to increment or decrement, offse~ fields of
: those physical descriptors in OFFALU 20242.
. .
.~: QFFMUX 202401S fifth input is connected from NAME BUS
i~ ~ 202240 As will be described further below, Names are
. 15 provide~ to NC 10226 by FUCTL 20214 to call, ~rom MC
~` 10226, logical descriptors corresponding to Names
.: appearing on MOD ~us 10144 as part of sequences of SINs.
. .
;~ As each Name is presented to NC 10226, that Name is
: transferred into and captured in Name Trap (NT) 20254.
Upon occurrence o~ an ~C 10226 miss, that is NC 10226
does not contain an entry corresponding to a particular
~ . Name, that Name is subsequently transferred from NT 20254
: ~ to OFFMUX 20240 through NAME 3u~ 20224 and OFFMUX 20240's
i ~ fifth i~put. That Name, which is previously described as
, 2S an 8, 12, or 16 bit binary number, may then be scaled,
: ~ that is multiplied by a NTE size. That scaled Name may
, . . .
5,~. then be added to ~ame Table Pointer (NTP) from mCRs 10366 ~ ~:
. to obtain the address of a correspondins NTE in an NT
',:'.
. ,~
,~.' . :,
. ,
~,. ..
'', ' ':
.. . , . : ~
"' ' :. ' ' ' ' ' , ;', '
~:L74766
-2 5 1--
10350~ In addition, a Name resulting in a NC 10226 mis ,
or a page fault in the corresponding NT 10350, or
requiring a sequence o~ Name resolves, may be tran~ferred
into OFFGRF 20234 from OFFMUX 2024 0, through O~F~LU 2 0242
; 5 and OFFSEL 20238 third input. That Name may subsequently
be read, or restored, from OFFGRF 20234 as required~
Referring now to outputs of OF~MUX 20240, OFF~UX
: 20240's first output, from OFFMUXR 23812, allows con~ents
of OFFMUXR 23812 to be transferred to first input of
OFFALU 20242 through OFFALUSA 20244. OFFMUX 20240's
second output, ~rom OFF~UXOS ~3822, is provided directly
~ to second input of OFFALU 20242. OFFALU 20242 may be
.;.: concurrently provided with a irst input from OFFMUXR
,.~ 23812 and a second inpu~, for example a manipulated
o~fset field, from OFFMUXOS 23822.
Referring to OFF~LUSA 20244, OFFALUSA 20244 is a
multiplexer. OFFALUSA 20244 may select either output of
~` OFFGRF 20234 or first output of OFFMUX 20240 to be either
::~ first input of OFFALU 202~2 02: to be OFFP 20218's output
.. 20 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 current loglcal descriptor, and
~- concurre~tly read into OFFALU 20242 to be incremented or
~ decremented to generate offset field of a subsequent
`~ Z5 logical descriptor in a string ~ransfer.
.
. . .
; . . .. ~
. . . . . . .. .
": ' ~: ,
. , ' ~
1~7~766
5 ~_
OFFALU Z0242 is a general purpose, 32 bit arithmetic
and logic unit capable of performing all usual ALU
operations. For example, OFFALU 20242 may add, subtract,
. ~ increment, or decr~ment offset fields of logical
;~ 5 descriptors~ In addition, OFFALU 20242 may serve as a
-~ transfer path for data, that is 9FFA~U 20242 may transf2r
input data to O~FALU 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 20~38, and to first input of AON5EL
20248. Data transferred or manipulated by OFFALU 20242
~: may therefore be transferred on to JPD 8us 10142, or
wrapped around into OFFP 20218 through OFFSEL 20238 for
subsequent or reiterative operations. OF~ALU 20242's
ou~put to AONSEL 20248 may be used, for example, to load
;` AON fields of AON pointers or physical descriptors
generated by OFFP 20218 into AO~GRF 20232. In addition,
~ thi~ da~a path allows FU 10120 to utilize AONGRF 20232
-:. as, for example, a buffer or temporary memory space for
~:. 20 intermediate or final results of FU 10120 operationsO
OFFALU 20242's ou~put to OFFSET Bus 20228 allows
~`, logical descriptor offset fields to be transferred onto
OFFSET Bus 20228 directly from OFFALU 20242~ For
~ example, a logical descriptor offset field may be
.~, 25 generated by OFFALU 20242 during a first clock cycle, and
; transferred immediately onto OFFSET Bus 20228 during a
second clock cycle.
' ' ~;~,
: ` '
. .
:,,.
.-.'~,' .
. .:,
.. ,, . , . ~ , . ..
. , ~ , .. . . , ~ . .
.
. , . , , . .. . .~
,' '' ~ ' '', ' ' ' ' ' ; ' ' ~, '' ,
: ~.7~ 7
--253-
OFFALU 20242'~ third output is to NAME Bus 20224. As
will be described further below, NAM~ Bus 20224 is
address input (ADR) to NC 1022~ OFFALU 20242's output
. ~o NAME Bus 20224 thereby allows OFFP 20218 to generate
~:: 5 or provide addresses, that is Names, to NC 10226.
aving described operation of OFFP 20218, operation
. of LENP 20220 will be described nex~ below.
e~ ~
~c`;, Re~e~ring to Fig. 202, a primary function of LENP
'~ 10 20220 is generation and manipulation o logical
de~criptor length fields, including length fields of
logical descriptors generated in string transfers. LENP
20220 includes LENGRF 20236, LENSEL 20250, BIAS 20246,
and LENALU 20X52. LENGRF 20236 may be comprised, for
example, of Fairchild 93422s~ LENSEL 20250 may be
comprised of, for example, SN74S257s, SN74S157s, and
SN74S244s, and LENALU 20252 may be comprised of, for
. example, SN74S381s,
~ s previously described, :LENGRF 20236 i~ a 32 bit
:~ i 20 wide vertical sec~ion of GR~ 10354. LENGR~ 20236
operates in parallel with OFFGRF 20234 and AO~GRF 20232
~: and contains, in part, length fields of logical
descriptors. In addition, also as previously described,
~;; LE~GRF 20236 may contain data.
LENSEL 20250 is a multiplexer having three inputs and
: providing outputs o hENGRF 20236 and fir~t input of BIAS
O 20246. LENSEL 20250'5 first input is from Length Bus
; 20226 and may be u~ed to write phy~ical descriptor or
'':'
.
,.,;
,i:
~j .
.. . . .
~ ,'
~ ,' ' , ! ,~ . . : .,. ' , . i .
r . . . . :~
;~
'.: :
...
~ ~L'7'~76~
-254-
.~
length fields from LENGTH Bus 2û226 into LENGRF 20236 or
into BIAS 202460 Such length fields may be written from
LENGT~ Bus 20226 to LE~G~F 20236, for example, during
Name evaluation or re~olve operations. LENSEL 20250's
second input is from OFFSET Bus 20228. LENSEL 202S0'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 LENGRF 20236 for storage ~hrough LE~SEL 20250'~
l second input.
-~ LENSEL 20250's third input is rom output of LENALU
20252 and is a wrap around path to return output of
LENALU 20252 to LENGRF 20256. LE~SEL 20250's third input
may, for example, be used during string transfers when
; 15 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
LBNGRF 20~36 to another location in LENGRF 20236. As
: 20 stated above, LENSEL 20250's output is also provided to
;: first input BIAS and allows data appearing at first,
second, or third inputs of LENSE~ 20250 to be provided to .
; first input of BIAS 20246. ~:
BIAS 2~246, as will be described in further detail
below, generates logical descriptor length fields during
string transfers. As described above, no more than 32
.j bits of data may be read from MEM 10112 during a single
:
~ read operation. A data item of greater than 32 bits in
,
'. ~
:;:i
.. ~ .
'''
, ,,-, -. .: ' ` :
. : , - , . ..
, - - .: :: - :
.. , , . .: . ..
':,' ~, ' ' ' , '`` ' ' ,
.'~ ~ f~
~ 7
-~55-
.
lenyth must therefore be transferred in a series, or
string, of read operations, each read operation
,~ transferring 32 bits or less of data. String transfer
~:~ . logical descriptor length fields genera~ed BIAS 20246 are
provided to LENGTH Bus 20226, to LENALU 20252 second
: input, and to OFF~UX 20240's fourth input, as previously
~ described. These string transfer logical descriptor
- ~ length f ields, referred to as bias fields are provided to
~-~ LENGT~ Bus 20226 by BIAS 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 input OFFMUX 20240 to increment or
:~ decrement ofset fields o~ those logical descriptors, as
: ~ previously described... These bias fields are provided to
second input of LENALU 20252, during string transfers, to
correspondingly decrement the length field of a data item
~ ~ being read to ME~ 10112 in a string transferl BI~S 20246
'; will be described ln greater cletail belowr after LENALU
:~` 20252 is ~irst briefly descri~ed.
- 20 a.a. Ier,l~=-3~
` L~NALU 20252 is a general purpose, 32 bit arithmetic
:~ and logic unit capable of executing all customary
: arithmetic and logic operations. In particular, during a
. string transfer of a particular data item LENALU 20252
receives that data items length ~ield from LENGRF 20236
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
. 30 length field back into LENGRF 20236 through LENSEL
: 20250 ' s ~hird lnput.
; .
,',:'', ~
,; .
.i .,
, , .... :.
'' ~ . , ' :," '' . ' ` ~ - , ,
.
,. .
r
3L~L7~766
-2~6-
b.b. ~I~Y~YYb~t=Y~
Referring to Fig. 239 r a partial block diagram of
::B~AS ~0246 is shown. BIAS 20246 includes Bias ~emory
(BI~S~ 23910, Length Detector ~LDET) 23912, Next Zero
Vetector (NXTZRO) 23914, and Select Bias (SBIAS) 23916.Input of LDET 23912 is ~irst input of ~IAS 20246 and
connected from output of LENSEL 20250. Output of LDET
23912 is connected to data input of BIASM 23910, and data
output o BIASM 23910 is connected to input o~ NXTZRO
23914. Output o~ NXTZRO 23914 is connected to a ~irst
input of SBIAS ~3916. A second input of SBIAS 23916 is
BIAS 20246's second input, L8, and is connected f rom an
; output of ~UC~L 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 SBI~S 23916 is
output o BIAS 20246 andr as described above, is
connected to LENGT~ Bus 20226, to a second input of
,
hENAhU 20252, and to fourth i.nput of OFFMUX 20240.
;:- BIAS~ 23910 is a 7 bit wide random access memory
,~. 20 having a length equal to, and operating and addressed in
~.' paxallel with, SR's 10362 o~ GRF 10354~ BIASM 23910 has
; an addres~ l~cation corresponding to ea~h address
location of SX's 10362 and is addressed concurrently with
those address locations in SR's 10362. 8~ASM 23910 may
~', 25 be comprised, for example, of ~D 27S03As.
~:. BIASM 23910 con~ains a bias value of each logic~l :
descriptor residing in SR's 10362. As described above, a
.~ :. bias value is a number representing number of bits to be
,.j, s
,. . .
, ~
,s'`.: ~ '
,. . ~
, 5 .,
,~,':,
,.' ~: ~,' . : .: . . . :
~, .: , ' . ' ' : : .
. ' . :: . ' ; -
':"; ' ~ ' " ' ' ,:, ~ '
.: . . :
," : . :: :~ '
','',, ' . ' ' '. ' ~, '
': ' : . . . , , ,, ~ , , :
:
-257-
read from MEM 10112 in a particular read operation when a
~: data item having a corresponding logical descriptor, with
a length field stored h~NGRF 20236, is to be read from
MEM 10112. Initially, bias values are written into BIASM
:~ 5 23910, in a manner described below, when their
corresponding length fields are written into LE~GRF
20236. If a particular data item has a length of less
than 32 bits, that data item's initial bais value will
represent that data items actual length. For example, if :~
: lo 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 o 24. If a particular
item has a length of greater than 32 bits for example, 70
lS bits as described in a previous example, that data item
must be read from ~EM 10112 in a string transfer
~ operation. ~s previously desc:ribed, a string transfer is
:. a series o~ read operations transferring 32 bits at a
. time from MEM 10112, with a fi.nal transfer of 32 bits or
less completing ~ransfer o~ that data item. Such a data
item's initial length field entry in LENGRF 20236 will
-j 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
~ 25 will contain a bias value of 3~. That initial bias value ~.
.~ of 32 i~dicates that at least the first read operation
.... re~uired to transfer that data item from MEM 10112 will ~ :
transfer 32 bits of data.
;:
'''-
,
~ ' ' '
'.~,
"
:.' ' . . ~. : ; .
' . ''.~ ' ' . ~ ~
,,
.
.
7~i~
-~5 8
:
: When a data item having a length of less han 32
bits, for example 24 bitis, is to be read rom ME~ 19112,
that data item's b~as ~alue of 24 ls read rom BIASM
23910 and provided to LENGT~ Bus 20226 as length field of
-:: 5 logical descriptor for that read opera~ion.
. Concurrently, that bias value of 24 is subtracted from
that data items length field read from LENGRF 20236.
Subtracting that bias value from that length value will
: yield a result of zero, indicating that no further read
^ l0 operations are required to complete transfer of that data
~: item.
. If a data item having, for examplef a length of 70
bits is to be read from ~E~ 10112, that data item's
`~ " initial bias value of 32 is read from BIASM 23910 to ~: :
.~. l5 LENGT~ Bus 20226 as length field of first logical
, descriptor of a string transfer. Concurrently, that data
.. item's initial length field ~s read from LEMGRF 20236.
That data item's initial bias value, 32, is subtracted
., ~rom that data ltem's initial length value, 70, and
.~i 20 LENAL~ 20252. The result of that subtraction operation
is the remaining length of data item to be transferred in
one or more subse~uent rea~ operationsO In this example,
subtracting initial bias value from initial length value
~ indicates that 38 bits of that data item remain to be
.. 25 transferred. L2NALU 20252)s output representing results
;. of thiis subtraction, for example 38, are transfer~ed to
LENSEL 20250's third input to LE~GRF 20236 and written
.~ into address location from which that data item's initial
... . .
i `'
~s"','
.: .
:~, .~,.
; , . .-,
,, .: ", '' .:,
;,
" .
j" - . . . , . - - .: . .: , . - .
~;' ' ' ' .
.
7~ ~ ~ 6
-259-
length value was read. This new length field entry then
represents remaining length of that data item~
Concurrently, LDET 23912 examines that residual length
value being written into LENGRF 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 i~ greater than 32 bits, LDET 23912
generates a next bias value o 32, which is written into
BIASM 23910 and same address location that held initial
bias value. I~ remainin~ data item leng~h is less than
32 bits, LDET 23912 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
IS con~aining initial bias value. These operations are also
performed by LDET 23912 in examining initial length field
~ and generating a corresponding initial bias value. These
;` read operations are continued clS described above until
LDET 23912 detects that remaining length field i~ 32 bits
- 20 or less, and thus that transfer o~ ~hat 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 BIASM
23910 at start of next read operation of that s~ring
transfer, that seventh bit is examined by NXTZR0 23gl4
which subsequently generates a test condition output,
Last Read (LSTRD) to FUCTL 20214. FUCTL 20214 may then
.. .
.. '" .. .
.
: . ,.
;,
, ' ' ' , ' . .
7~7~6
--2 6 ~--
.~
~erminate executisn of tha~ string transfer after that
- last read operation, if the transfer has been
successfully completed.
As previously described, the basic unit of length of
.. ~
a data item in CS 10110 i5 32 bits. Accordingly, data
; item~ 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 requires 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~ length and bias fields of the logical
descriptors of both the data item and the location the
data item is being transferred to. FUCTL 20214 will
receive an LSTRD test condition if bias field of source
,~
` ( descriptor becomes zero before or concurrently with that
of the destination, that is a completed transfer, or if
-~i 20 bias field of destination becomes zero before that of the
` source, and may provide an appropriate microcode control
,~ respanse. I~ should be noted that if source bias field
b~comes zero before that of the destination, the
remainder of the location that this data item is being
transferred to will be filled and padded with zeros. If
the data i~em is larger than the destination storage
capacity, the destination location will be filled to
capacity and FUCTL 20214 notified to initiate appropriate
action .
``''
.. .
.
. ;
:
. -
.. . . .
, . ,
. . ' ' - . ': ,
, :'' ', . :
. . .
:
3 ~7~76~
. . .
-261-
In addition to allowing data ltem transer~ which are
insen~itive to data item length, BI~S 20246 allows ~tring
~ ; trans~ers to be accomplished by short r tight microcode
.. loops which are insensitive to data item length. A
. 5 string trans~er, ~or example, from location A to location
B is encoded a5:
(1) Fetch from A, subtract length from bias A~ and
~; update offset and length of a; and!
' ~2) Store to B, subtract length from bias B, and
:. .
branch to ~1) if length of B doe not go to zero or fall
~:' through (end transfer) if length of B goes to zero~
Source (~) length need not be texted as ~he microcode
loop continues until length of B goes to zero; as
- described above, B will be filled and padded with zeros
~-:: 15 if length of ~ is less than length of ~, or B will be
~`:`` illed and the string transfer ended if length of A is
' greater than or e~ual to lengt:h of B.
LDET 23912 and NXTZRO 23914 thereby allow FUCTL 20214
to automatically initiate a string ~ransfer upon
occurre~ce of a single microinstruction from FUCTL 20214
initiating a read operation by DESP 20210. That
~i. microinstruc~ion initiating a read operation will then be
automatically repeated until LSTRD to FUCTL 20214 from
,~ NXTZRO 23914 indicates that the string transfer is
~ 25 completed. LDET 23912 and NXTZRO 23914 may,
:, respectivelyy be comprised ~or example of S74S260s,
SN74S133s, SN74S51s, SN74SOOs, SN74S00~, S~74S04s,
: SN74S02s, and S~74S32s.
~' ~
:,. . .
, '
,:~, ~ , . ~ . . . .
. : ,
, . ~, . , ~ ~ , , ,
if ~ ff .~
,,,
: ~ ~7~'66
:
-262-
Referring finally to S8IAS 23916, SBIA5 23916 is a
multiplexer comprise~, for example, of SN;'4,S288s,
,SN74S374s, and SN74S244so SBIAS 23916, ur,~der
microinstruc~ion control from FUCTL 20214, selects BIA5
5 2,024,6 's output to be one o a bias value from BIASM
~ 23910, L8, or L. SBIAS 23916's first inpu~, from BIASM
- 23910, has been described above. SBIA5 23916's second
. input, L,3,, is provided from FUCI~'L 20214 and is 8 bits of
a microinstruction provided from FUSITT 11012. SBIAS
~ lO 23916's second input allows microcode selection of bias
.~ values to be used in manipulation o~ length and offset
fields o logical descrip~ors by LENALU 20252 and OFFALU
20242, and for generating entries to MC 10226. SBIAS
23916's third input, L, is similarly provided from FUCTL
: l5 20214 and is a decoded length ~alue derived from portions
of microinstructions in FUSITT 11012. These microcode
il length values represent certain commonly occurring data
.: item lengths, for example lengt:h of 1, 2, 4, 8, 16, 32,
and ~4 bits. An L input representing a length of 8 bits,
20 may be used for example in reading data from MEM 10112 on
a byte by byte basisO
~ aving described operation of LENP 20220, operation
o AONP 20216 will be described next below.
a~a~ ~S~ ZQ~
~ As described above, AONP 20216 includes AONSEL 20248
- and AONG~F 20232. AONGRF 20232 is a 28 bit wide vertical
section of GRF 10354 and stores AO~ fields of AON
3I pointers and logical descriptors. AONSEL 20248 is a
. 30 multiplexer for selectin~ inputs to be written into
'.
'
. ~ ,
~'' ,
.
.
-, : , - ,
.
.. . ..
..
. .
~ 1.7~766
-263-
AONGRF 20232~ AONSEL 20248 may be comprlsed, for example
of SN74S257s. AONGRF 20232 may be comprised of, for
example, Fairchild 93422s.
As previously described, AûNGRF 202321C output is
5 connested onto AON Bus 20230 to allow AON fields of AON
poin~ers and logical descrip~ors to be transferred onto
:; AON Bus 20230 from AONGRF 20232. AON&RF 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
I fourth input of AONSEL 20238. This data path allows AON
,. . .
~: fieldsr either from AONGR~ 20232 or from AON Bus 20230,
to be written into AONG~F 20232 or AONGRF 20234, or
: provided as an input to OFF~lUX 20240.
AO~SEL 20248's first input: is, as previously
~ describedl connected ~rom output of OFFALU 20242 and is
:;: used, for example, to allow AC)N fields generated or
... ; ~
manipulated by OFFP 2021~ to be written into AONGRF
20232v AONSEL 20248's third i.nput is a 28 bit word
~, 20 wherein each bit is a logical zero ~. AONSEL 20248 ' s third
.~ input allows AON ~ields of all zeros to be writl:en into
~ONGRF 20232. An AON field of all zeros is re~erved to
indicate that corresponding entries in OFFGR~ 20234 and
LENGRF 20236 are neither AOM pointers nor logical
25 descriptors. AON fields of all zeros are thereby
.. reserved to indicate that corresponding entries in OFFGRF
20234 and LENGRF 20236 contairl dataO
In summary, as described above, DESP 20210 includes
~: AONP 20216, OFFP 20218, and LENP 20220. OFFP 20218 : .
contains a vertical section of G~ 10354, OF~GRF 20234,
.:. -:
. -
. . . ,, ~
, ~ :
~: :
-:
. ~
~,............ . .
~ ~ '7~7~i
: -264-
~''
~or storing offset fields of AON psinters and logical
descrlptors, and for containing data to be operated upon
. by DESP 20210. OFFP 20218 is principal path for transer
of data from MEM 10112 to ~P 10114 and is a general
purpose 32 bit arithmetic and logic unit for performing
all usual arithmetic and logic operations. In addition,
OFFP 20218 includes circuitry, for example OFFMUX 20240,
for generation and manipulation of AON, OFFSET, and
LENr~T~ fields o~ logical descriptors and AON pointers.
l OFFP 20218 may also generate and manipulate entries for,
for example, NC 10226~ ~TU 10228, PC 10234, AOT 10712,
`: M~T 10716, MFT 10718, and other data and address
structures residing in MEM 10112~ LENP 20220 includes a
vertical section of GRF 10354, LENGR~ 20236, for storing
:.......... l5 length fields of logical descriptors~ and for storing
` ~. data. LENP 20220 ~urther incl.udes BIAS 20246, used in
.:: conjunction with LENGRF 20236 and LE~ALU 20252, for
providing length fields of logical descriptors for ~EM
::i 10112 read operations and in particular automatically
20 performing stxing transfers. AONP 20216 similarly
`~ includes a vertical ~ection of G~F 10354, AOWGRF 20232.
A prim~ry ~unction AONGRF 20232 is storing and providing
~:~ AON fields of AON pointers and logical descriptors.
~aving described structure and operation o~ DESP
25 20210, struc ure and operation of Memory Inter~ace
(M~MINT) 20212 will be described next belowO
. 2.
,':'.
ME~INT 20212 comrises FU 10120ls interface to ME~
:~ 30 10112. As described above, ME~IINT 20212 includes Name
, ,
, .
,
.,
, ~ ` , ~, ` ' '`
,`, .
': '~
' " '' ' ~` ~,'' " ` '` ' ` - , . "
,` ` .~ ~ `
~ 7~7~6
.
~65
Cache (NC) 10226, Address Translation Uni~ tATU) 10228,
and Protection Cach~ (PC) 102349 all of whlch have been
previously briefly described. ME~INT 20212 ~urther
includes Descriptor Trap (DEST) 20256 and Data Trap (DAT)
20258. Functions performed by MEMI~T 20212 includ~s (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 acc~ss
writes to objec~s, by PC 10234.
As shown in Fig. 202, NC 10226 ~dress input (ADR) is
connected from NA~E Bus 20224~ NC 10226 Write Length
Field Input ~WL) is connected from LENGRF 20236's
output. NC 10226's Write Offset Field ~nput tWO) and
Write AON Field Input (WA) are connected, respec~lvely,
from OFF5ET Bus 20228 and AON Bus 20230. ~C 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 (OFF),
and Length (LEN) ports are connected by bi-directional
buses to and from, respectively, AON Bus 20230, OFFSET
Bus 20228, and LENGTH Bus 20226.
PC 10234 has AON (AON) and Offset (OFF) inputs
connected from, respectively, AOM Bus 20230 and OFFSET
Bus ~0228. PC 10234 has a Write Entry (WEN) input
connected rom JPD Bus 10142. ATU 10228 has AON (AON), ~:
Offset (OPF), and Length (LEN) inputs connected from,
respectively, AON Bus 20230, OFFSET Bus 20228, and LENGTH
,...
. . .
-
,.; , .
.~ :
- ,
.
, . ,
,. . . .
- . ~ ... .. .
., - - . .. .. .
"
' ' ' , ' .
17~
.
-~66-
,~,
Bu~ 20226. ~TU 10228's output is connected ~o Physical
Descriptor (PD) Bus 10146/
-~ Finally, DAT 20258 ha~ a bi-directional port
connected to and from JP~ Bus 101420
:
a.a.
~", ~2~
Referring first to DST 20256 and DAT 20258~ ~ST 20256
is a register for receiving and capturing logical
: descriptors appearing on AON Bus 20230, OFFSET Bus 20228,
.: lO and Length ~us 20226. Similarly, DAT 20258 is a register
: for receiving and capturing data words appearing on JPD
Bus 10142. DST 20256 and DAT 20258 may subsequently
. - return captured logical descriptors or data words to,
respectively, AON Bus 20230, O~FSE~ Bus 20228, and LENGI~
Bus 20226, and to JPD Bus 10142.
As previously described, many CS 10110 operations, in
particular ~EM 10112 and JP 10114 operations, are
. pipelined. That is, operations are overlapped with
::: certain sets within two or mo.re operations being executed
concurrent~y. For example, ~J 10120 may submit read
request to ME~ 10112 and, while ME~ 10112 is accepting
a~d servicing that request~ submit 2 second read
request~ DEST 20256 and DAT 20258 assist in execution of
overplapping operations by providing a temporary record .
~: 25 of these opera~ions. ~or example, a part of a read or
write request ~co ~E~ 10112 by F~ 10120 is a logical
~ descriptor provided to ATU 10228. If, for example the
s first red request just referred to results in a ATU 10228
' cache miss or a protection violat:ion, the logical
30 descriptor of that first request must be recovered for
..... .
i. .
?,-.
;s.';
;
., .
.,,, , ~ .
~" .
,. ,
~7~7~6
-267-
subsequent action by CS 10110 as previously described.
: That logic21 descriptor will have been captured and
stored in DEST 20256 and thus is immediately available,
so that DESP 20210 is not required to regenerate that
descriptorO DAT 20258 serves a similar purpose with
regard to data being written into ~E~ 10112 from JP
10114. That is, DAT 20258 receives and captures a copy
of each 32 bi~ word transferred onto JPD Bus 10142 by JP
10114. In even of ME~ 10112 being unable ~o accept a
lo write reques , that data may be subsequently reprovided
from ~AT 20258.
b o b ~ ~22~
~x~n~t~o~-~t~ }-~nd
Referring to NC 10226, ATU 10228, and PC 10234, these
elements of ME~INT 20212 are primarily cache mechanism~
~o enhance the speed of FU 10120's interface to ~EM
10112, and consequently of CS lOllO's operation. As
described previously, ~C 10226 contains a set of logical
descriptors corresponding to certain operand names
:, curren ly appearing in a process being executed by CS ~:
. 10110. NC 10226 thus 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 NAME Bus 20224. Name read and write
:
. ~
.,
~';'
,
, ~ ` ~ ' . . . . .
' ~ ~ ' " . . , ~,
i~`l`.. ` ~
76
--~6 8--
addresses may be provided from DESP~20210, and in
particular from OFFP 20218 as previously descri.bed, or
-: from FUCTL 20214 as will be described in a ollowing
-.: description of FUCTIJ 20214. Logical descriptors
5 comprising NC 10226 entri~s7.each entry comprising an AON
field, an Offset field, a Length field, are written into
~: ~C 10226 through NC 10226 inputs WA, WO, and ~L from,
re~pectively, AON Bus 2023a, 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,`0FFSET Bus 20228, and LENGTH
Bus 20226 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 1022B 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, ox anticipa~ed to be mader to ~E~
10112 by JP 10114. As previously described, each
. physical descriptor is comprised of a ~rame Number ~FN)
field, and Offset ~ithin Frame ~O ) fields, and a Length
field. As discussed with reference to string transfersr
~: a physical descriptor length field, as in a logical
25 descrip~or length field, specify a data item of less than
: or equal to 32 bits length. Referring 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 Page Number (P) field and a 14 bit
.
"
,, , ~ .
. , , ~.
' ' :
,,:" , ~.
7~
.
-269-
Offset wi~hin Page (O ) field. In translating a logicl
into a physical descriptor, logical descrlptor Length and
-: o field~ are used directly~ as respectively, physlcal
descriptor leng~h and O field~. Logical descrip~or AON
and P fields are translated lnto physical de~crip~or FN
~ ~ield. Because no actual translation is required, ATU
-~ 10228 may provide logical descriptor L field and
correspondin~ O field directly, that is without delay,
~o ME~ 10112 as corresponding phv~ical descriptor O a~d
Length fields. ATU 10228 cache entries are thereby
comprised of physical descrip~or FN fields corresponding
to AON and P field~ of those logical descriptors for
which ATU 10228 has corresponding entries. Because
.~ physical descriptor FN fields are provided rom ATU
. l5 10228's cache, rather than directly as in physical
descriptor O and Length field~, a physical descriptor's
:: FN field will be provided to M.E~ 10112, for example, one
clock cycle later than that phys.ical descriptors O and
Length fields t as has been previously discussed.
Referring to Fig. 202, physical descriptor FN fields
~ to be written into ATU 10228 are, in yeneral, generated
: by DE5P 20210. FN fields to be written into ATU 10228
;~ are-provided to A~U 10228 Data Input (DI) through J~D Bus
10142. A~U 10228 read and write addresses are comprised
of AON and P fields of logical descriptor~ and are
provided to ATU 10228's AON and OFF inputs from,
respectively, AOM Bus 20230 and OFFSET Bus 20228. ATU
10228 read and write addresses may be provided from DESP
. 20210 or, as described further below, from FUCTL 20214.
: 30 ATU 10228 FN outputs, together with O and Length fields
.. . ,
, .
;; .
... ..
,.-, ~ . - , ~... . .... - , ....
4~
. .
- -~70
:
comprising a physical descrip~or, are provided to PD BuS
` 10146.
- PC 10234 is a cache mechanism for confirming active
:~ pro~edure'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 described
acce~s rights to objects are arbitrated on the basis of
~; subjects. A subject has been deined as a par~icular
combination of a principal, process, and domain. A
0 principal, process, and domain are each identified by
corresponding UIDs. Each subject having access rights to
an object is assigned.an Active Subject ~umber ~ASN) as
described in a previous description of CS 10110lS
. Protection ~echanism. The ASN of a subject currently
~: l5 active in CS 10110 is stored in ASN Register 10916 in ~U
~; 10120. Access rights of a currently active subject to
:.i currently active objects are read from those objects
j Access Control Lists (ACL) 10~18 and stored in PC 10234.
~` If the current ASN hanges, PC' 10234 is flu~hed of
; 20 corresponding access right entries and new entries,
. corresponding to the new ASNr are written into PC 10234.
The acce~s ri~hts of a particular current ASN to a
~ particular object may be d~termined by indexing, or
addressin~, PC 10234 with the AON id~nti~ying that
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 from JPD Bus 10142. PC
-. 10234 is also provided with inputs, not shown in Fig~ 202
~ 30 ~or purposes of clarity, from FUCTL 20214 indicating the
'', ,
, ,
.~ . . . . .. .
~," ~" , , , , .
.
:
.:
.
6~
-~71-
current operation to be perfomed by JP 10114 with respect
to an object being presently addressed by FV 10120.
~: Whenever ~U 10120 submits a read oc wri~e reques~
:~ concening a particular ob~ect to M~M 10112, AON fleld of
that request is provided as an addess to PC 10234.
Access rights of the current active subject to that
object are read ~rom corresponding PC 10234 entry and
.~ compared to FUCTL 20214 inputs indicating the particular
operation to be performed by JP 10114 with respect to
~ 10 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 10~34 provides an output indicating
whether that active sub~ect possesses the rights required
- to perform the intended operat:ion~ Indexing of PC 10234
;:: 15 and comparison of access right:s to intended operation is
performed concurrently with tr.anslation of the memory
` request logical descrip~or to a corresponding physical
: descriptor by ATU 10228. If ~?C 10234 indicates that that
.~ active subj ct has the required access rights, the
~. 20 intended operation is executed by JP 10114. I~ PC 10234
t:~ lndicates that that active subjec~ does no~ have the
. required access rights, PC 10234 indicates that a
. protection mechanism violation has occurred and
interrupts execution of the intended operation.
. ~ 25 c~
:
Having described ovexall structure and operation of
~ ~C 10226, ATU 10228, and PC 10234, structure and
,:: 30 operation of these caches will be described in further
' :~
:
i .:
i .
:..
. . .. .
, .. , . .. . ;.: ,
... . ... . .
.. : . . - .
~. , ~ . . .... .
: .
: .
.
,,
.
7~ 6
-272-
detail below~ Structure and operation of NC 10226, ATU
10228, and PC 10234 are similar, except that NC 10226 is
a four-way set associative cache, ATU 102~8 is a three-
way set associative cache and PC 10234 is a two-way set
associative cache.
As such, the structure and operation of NC 10226, ATU
10228, and PC 10234 will be described by reference to and
: description of a generalized cache similar but not
necessarily identical to each of NC 10226, ATU 102~8, and
PC 10234. Reference will be made to NC 10226 in the
. description of a generalized cache next below, both to
further ill~strate structure and operation of the
generalized cache, and to d~scribe differences between
the generalized cache and ~C 10226. ATU 10228 and PC
:. 15 10234 will then be described by description of
differences between ATU 10228 and PC 10234 and the
~; generalized cache.
Referring to FigO 240, a partial block diagram of a
genexalized four-way, set associ.ative cache is shown.
Tag Store (TS) 2A010 is comprised o~ Tag Store A (TSA)
24012, Tag Stor~ B (T5B) 24~14~ Tag Store C ~TSC) 24016,
and Tag Store D (TS~) 24018. Each of the cach2's set~,
represented by TSA 24012 to TSD 24018, may contain, for
example as in ~C 10226 r up to 16 entries, so that TSA
25 24012 to TSD ~4018 are each 16 words long.
: Address input~ to a cache are divided into a tag
field and an index field. Tag f ields 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 field of
; 30 the address. A tag read from tag store in response to
:;'
~ .
,
- - . . . ,, ,, , .. . ~ , -
., ,, , ~ .
.: . . , . . ~ .
-
, :: .
... . . , ~ .... ~ .
: ~ :
., . ~ .
-
~7~766;
273-
index field of an address is ~hen compared ~o tag field
of that address to indicate whether the cache con~ains an
entry corresponding to that address, that i5, whether a
:~ cache hi~ occurs~ In, for example, NC 10~26, a Name-~ 5 syllable may be comprised of an 8, 12, or 16 bit binary
word, as previously described. The fo~lr least
~ignificant bits of these words, or Names, comprise NC
: 10226's index field while the remaining 4, 8, or 12 most
.: ~ significant bi'cs comprise NC 10226's tag field. TSA
240~2 to ~DS 24018 may each, therefore, be 12 entry wide
memories to store the 12 bit tag fields of 16 bit names,
Index (IND) or address inputs of T~A 24012 to TSD 24018,
: - would in NC 10226, be connected from four least :~
significant bits of NAME Bus ~0224 while Tag Inputs
: l5 (TAGI) of TSA 24012 to TSD 24018 would be connected from
::~ the 12 most significant bits of NAME Bus 20224.
As described abover tag outputs of TS 24010 are
. compared ~o tag fields of addresse~ presented to the
cache to determine whPther the cache contains an entry
corre~ponding to that address~ Using NC 10226 as an
- example 12 bit Tag Outpu~ (TAGOs) o~ TSA 24012 to TSD
.. .
24018 are connected to first inputs of Tag Store
;~ Comparators (TSC) 24019, respectively to inputs o~ Tag
.; Store Comparitor A (TSCA) 24020, Tag Store Comparitor B
(TS~B) 24022, Tag Store Comparitor D (TSCD) 24024, and
-~ Tag Store Comparitor E (TSCE) 24026. Second 12 bit~:~` input5 of TSCA 24020 to TSCE 24026 may be connected from
,~ ~he 12 most æignificant bits of NAME Bus 20224 to receive
s ~,
,, ,
,~ .
, , ~
, .. .
., " .
- , . , ~
... ~. ~ . . ~ ..
, . , , ~ ,
. ~ . . ..
; .
,. - , .,:
7~
-274-
tag fields of NC 10226 addresses. TAS 24020 to TSCE
24026 compare tag field of an address to tag outputs read
from TSA 24012 to TSE 24018 in rasponse ~o index field of
that address, and provide four bi~ outputs indicating
5 which, if any, of the possible 16 entries and their
; associated tag store correspond to that address tag
: ~ f ield . TSCA 24020 to TSCE 24026 may be comprised, for
example, of Fairchild 93S46s.
Four bit outputs of TSCA 24012 to TSC~ 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 (TSPRA) 24028, Tag Store
Pipeline Register B (TSPRB~ 24030, Tag Store Pipeline
~gis~er C (TSPRC~ 24032, and Tag Store Pipeline Regis~er
15 ~ (TSPRD) 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
i ~ addressed and tags store there~in compared to tag field of
s ~ address to provide indication of whether a cache hit has
' ~ 20 occurred, that is whether cache contains an entry
~ correspondin~ to a particular addres~. During second
c clock cycle, as will be described below, a detected cache
hi~ is encoded to obtain access to a corresponding en~ry
in cache data store. Pipeline operation over two clock
25 cycles is provided by cache pipeline registers which
include, in part, TSPRA 24028 to TSPRD 24034. NC 10226
~ is not pipelined and does not include TSPRA 24028 to
$~ TSPRD 24034. In NC 10226, outputs of TSCA 24012 to TSCD
~ .
., . -
,
~, .
~s,' ., ~,~
~; . . ..
. , ,
, ' " ' " '~. , ' ' ,
, .
. . .
:~ .
-275-
:
: 24024 are connected directly to inputs of TSHEA 24036 to
TS~ED 24042, descrlbed below.
Outputs of TSPRA 24028 to TSPR~ 24034 are connected
to inputs of Tag Store Hit Encoders (TS~E) 24035,
;: 5 respectively to Tag Store Hit Encoder A (TSaEA) 24036,
:: Tag Store ~it Encoder B (TS~EB) 24038, Ta~ Store Hit
~: Encoder C (TSHEC) 24040, and Tag Store ~it Encoder D
(TSHED) 24042. TS~EA 24036 to TS~ED 24042 encode,
respectively, bit inputs from TSPRA 24028 to TSPRD 24034
~ 10 to provide single bit outputs indicating which, i~ any,
-~ set of the cache's four sets includes ~n entry
:~; corresponding to the addres~ input.
Single bit outputs of TS~EA 24036 to TS~ED 240~2 are
connected to inpu~s of ~it Encoder (HE) Z4044. HE 24044
. 15 encodes single bit inputs rom TSHEA 24036 to TSHED 24042
to prcvide two se~s of ouputs. First outputs o HE 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
:~ 20 described previously with reference to MC 20116, and will
~:. be described ~urther belowt C~S 24046 is a memory
containing information ~or tracking usage of cache
~ entries. That is, CUS 24046 contains e~tries indicating
.. whether, for a particular index, Set A, Set 3, Set C or
.: 2~ Set D of the cache's four sets has been most recently
used and which has been least recently usedO C~S 24046
entries regarding Sets A, B, C, and D are stored in,
respectively, memories CUSA 24088, C~SB 24090, CUSC
.
. ' '
:
: ,~ , , ' , . .
'. , ' ' ' " '' '
~7f~
-27 6--
24092, and CUSD 24094. Second output of ~E 24044, as
described further below~ is connected ~o selection input
o~ ~ata Store 5election ~ultiplexer (~SSMUX) 24048 to
select an ou~put from Data Store (DS) 24050 to be
provided as output o~ the cache when a cache hit occurs.
Referring to DS 24050, as previously described a
cache's data store contains the information, or entries,
stored 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
tas store and entries therein are identified and located
through that cachels tag store and associated tag store
comparison and decoding loyic. 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
that T~ 24010 and DS 24050 will each contain four sets of
data. Each set was previously described as containing up
to 16 entries.. DS 24050 i5 therefore comprised of four
" .
~:~ 16 word memoriesO Each memory is 65 bits wide,
accommodating 28 bits of AO~, 32 bits of offset, and 5
25 bits of length. These four componen~ da~a store memories
: of DS 24050 are indicated in ~ig, 240 as Data Store A
~; (DSA) 24û52, Data Store B (DSB) 24054, Data Store C (DSC)
24056, and Data Store D (DSD) 24058. DSP. 24052, DSB
'''~
.~';", . ',
. .
.. .
,,
-
' , ' ' , ~
~1'7~7f~,
-277- -
24054, ~SC 24056 and DSD 24058 correspond, respectively,
in structure, contents, and operation to TSA 24012, TSB
24014, TSC 24016 and TSD 24018.
Data Inputs (DIs) of DSA 24052 to DSD 24058 are, in
NC 10226 for example, connected rom AON Bus 20230,
:: O~FSET Bus 20228, LENGTH Bus 20226 and comprise inputs
. WA, WO, WL respectively of NC 10226. DSA 24052 to DSD
:~ 24058 DIs are, in NC 10~26 as previously described,
utilized in writing NC 10226 entries into DSA 24052 to
.:~ 10 DSD 24058. Address inputs of DSA 2405~ to DSD 24058 are
` connected from address outputs of Address Pipeline
Register (ADRPR) 24060. As will be described
momentarily, except during cache flu~h operations, DSA
~4052 to DSD 24~58 address inputs are comprised of the
. 15 same index fields of cache addresses as are provided as
address inputs to TS 24010 t but are delayed by one clock
;~ cycle and ADRPR 24060 for pipelining purposes. As
'"'J~ de~cribed 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,: s~lected by index field of that address, being read from
TSA 24012 to TSD 24018 and DSA 24052 to DSD 24058, The
four outputs o~ DSA 24052 to DSD 24058 selected by a
i particular index field of a particular address are
25 provided as inputs to DSS~UX 24048. DSSMUX 24048 is
concurrently provided with selection control input from
: HE 24044. As previously described, this selection input
to DSS~UX 24048 is derived from TS 24010 tag entries and
. ~ .
.', .
'."' '
.. . .
, . . .
,
~,,
, , .
.. . . . . . . . .
. , . : . , .
. . .
.. ,.~ '. ...... . .. . .
-
:
-278-
indicates which o DSA 24052 to DSD 24058 entries
cGrresponds to an address provided to the cache. In ~
response ~o that selection control input, DSSMUX 24048
selects one of DS 24050's four logical descrip~or sutputs
5 as the cache's output corresponding to that address.
DSSMUX 24048's output is then provided, through Buffer
Driver (BD) 24062 as the cache'~ output, for example in
NC 10226 to AON Bus 20230, OFFSET Bus 20228, and LENGT~
Bus 20226.
Referring to ADRMUX ~4062, ADRMUX 24062 selects one
: of two sources to p~ov~de address inputs to DS 24050,
that is to index to DS 24050. As described above, a
first ADRMU~ 24062 input is comprised of the cache's
address index fields and, for example in NC 10226, is
:........... 15 connected from the ~our least significant bits o~ NAME
~, Bus 20224. During cache flush operations, DS 24050
address inputs are provided from Flush Counter ~FLUSHCTR)
2~066, which in the example i~ a four bit counter.
During cache flush operations, FLUS~CTR 24066 generates
20 sequential bit addresses which are used to sequen~ially
-- address DSA 24052 to DSD 24058. Selection between ADRMUX24062 first and second inputs, respectively the address
index fields and from FLUS~CTR 24066, is controlled by
~- Address Multiplexer Select (ADRMUXS) from FUCTL 20214.
Validity Store (VALS) 24068 and Dirty Store (DI~TYS)
24070 are memories operating in parallel with, and
addressed in parallel wih TS 24010. VALS 24068 contains
entries indicating validity of corresponding TS 24010 and
DS 24050 entries. That is, VALS 24068 entries indicate
30 whether correspo~ding entries have been written into
, j :
~ . :
r'
.
': "`' ' ' ' .
': .
:
.. . . .
'
5 ~ .
~ `~
74 7 ~ 6
-279-
corresponding locations in TS 24010 and DS 24050. In the
: example, VALS 24068 may thereby be a 16 word by 4 bit
wide memory. Each bit of a VALS 24068 word indicates
~ validity of a corresponding location in TSA 24012 and DSA
:.~ 5 24052, TS~ 24014 and DSB 24054, TSC 24016 and D$C 24056,
~nd T5D 24018 and DSD 24058. DIRTYS 24070 similarly
~ indicates whether corresponding entries in corresponding
:~ locations of TS 24010 and DS ~4050 have been written
.:~ over, or modified. Again, DIRTYS 24070 will be a sixteen
word by ~our bit wide memory.
: Address inputs of VALS 24068 and DIRTYS 24070 are,
~;: for example in NC 10226, connacted from least significant
bits of NAME Bus 20224 and are thus addressed by index
fields 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 T',CA 24020 through TSCE 24026
upon occurrence of an invalid concurrence between a TS
:: 24010 entry and a NC 10226 address inputO Similar
outputs o DIRTYS 24070 are provided to FUCTT 20214 ~or
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 purposes as will be described
momentarily. Outputs o~ VALPR 24072 and DIRTYPR 24074
~: 30 are connected to inputs of, respectiv~ly, Validity Write
, ' ; :
;'
.,
... ,, . ', . . .` , , :
.
, ~ . , . , :
": ~ . ., ;
, ` : . .' ~ :
.~ ' . , ~ ,.
.
t ~ 476~i;
~280--
Logic (VWL~ 24076 and Dirty WrLte Logic ~WL~ 24078~ As
described above, NC 10226 is not a pipeïined cache and
does not include VALP~ 24072 and DIR~P}~ 24074; output~
of V~LS 2406B and DI~TYS 24070 are connec~ed directly to
5 inputs of VWL 24076 and ~WL 24078. Outputs of VWL 24076
and DNL 24078 are connected":~spectively, to data inputs
of VALS 24068 and DI~TYS 24070. Upon occurrence o~ a
write operation to TS 24010 and DS 2405û, ~hat is writing
: in or modifying a cache entry, corresp~nding validity and
~- 10 dirty word entries are read from VA$S 24068 and DIRTYS
~, 24070 by index field of the caches input address.
Outputs to VALS 24068 DIRTYS 24070 are received and
stored ln, respectively, VALPR 24070 and DIR~P~ 24074.
At start of next clock cycle, validity and dirty words in
15 VALPR 24072 and DIRTYPR 24074 are read into,
respectively, tlWL 2407~ and DWL 24078. VWL 24076 and DWL
~: 24078 respectively modify those validity or dirty word
-1 entries from VALS 24068 and DIRTYS 24070 in accordznce to
whether the corresporlding entries in TS 24010 and DS
20 24U~0 are writ~en into or modified. These modified
~'! V lidity and dirty words are then written, during second
- clock cycle, from VWL 24076 and ~WL 24078 into~
respectively, ~AI.S 24068 and DIRTYS 24070~ Control
: inputs of VWL 24076 and DWL 24078 are provided from F~CTL
25 20214.
Referring finally to Least Recent ~sed Logic (LRUL)
~4080, LRUL 24080 track~ usage of cache entries. As
' previou-~21y described, the generalized cache of Fig. 240
,. .
,
~.
,: :
... .
,
, . , , ~
.. . ~ ,
, :, . . .
, . . .. ..
,
.
,,.
~'; , :
, , . ~ . . .
~7~7
-281-
is a four way, set associative ca he with, for example,
up to 16 entries in each o~ NC 10226 I s ge~sr Entries
::~ wi~hin a particular set are identified, as described
above~ by indexing the cache's TS 24010 and DS 24050 may
s contain, concurrently, up ~o four individual entries
- identified by-the same index but distiguished by having ~.
~ different 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 240S4, and so on. Since the
:~ 10 possible number of individual entries having a common ta~
i5 greater than the number of cache sets, it may be
~ necessary to delete a particular cache entry when another
:~ entry having the same tag is to be writte~ into the
cache. In general, the cache's least recently used entry
. lS would be deleted to provide a location ln TS 24010 and DS -` 24050 for writing in the new ~ntry. LRUL 24080 assists
` in determining which cache ent:ries are to be deleted when
:: necessary in writing in a new entry by tracking and ::
indicatinq relative usage of t:he cache's entries . LRUL
20 24080 is primarily comprised of a memory, LRU Nemory
(MLRU) 24081, containin~ a word for each cache set. As
`~ described above, NC 10226, for example, includes 16 ~:ets
. :` of 4 frames each, so that LRUL 24080's memory may
.: correfipondingly be, for example, 16 words long. Each
25 word indicates relative usage of the 4 frames in a set
: ~ and is a 6 bit word.
-; Words are generated and written into LRUL 24080's
LRU 24081, through Input Register A, B, C, D (RABCD)
.~ 24083, according ~o a wri~e only algorithm e~ecuted by HE
,. ,. ,~
r .r.
'., ~"~
;'"",''' '
. .
i ~ '' ' ~ ' ' ' ' ' ' . . ' ' , , ' ' ': ' . . ' ' ' '
'' . ' ", ' ' ' ' ~ ' ~ .' " ' " ''
" ~ , ' ' " ' ' . ' ' ~
~ . . . ' ' .' .
~ " ' ' ' ' " '
'' '' ' ' '
' S
.
- ~ ~
'4~
-2 B2-
24044, as described momentarily. Each bit of each six
word pertains to a pair of frames within a particular
cache set and indicates which of those two ~rames was
more recently used than the other. For example~ Bit 0
will contain logic 1 if Frame ~ was used more recently
than Frame B and a logic zero if Frame B wa~ used more
recently than Frame A~ Similarly, Bit 1 pertains to
Frames A and C, Bit 2 to Frames A and D, Bit 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 particular LRUh 24080
word are set to zeroO Assuming, for example, that the
frames of a particular set are used in the sequence Frame
A~ Frame D, Frame B; Bita 0 to S of that LRUL 24080 word
will initially co~tain all zeros. Upon a re~erence to
Frame A, Bits 0, 1 J and 2, referring respectively to
.,
~`~ Frames A and B, Frames A and C', and Frames A and D, will
be written as logic 1'5. Bits 3, 4, and 5, referring
respectively to Frames B and C, Frames B and Dl and
.~ Frames C and D, will remain logic 0. Upon reference to
, 20 ~rame D, Bits 0 and 1, referring respectively to Frames A
:~ and B and Frames A and C, will remain logic l's. Bit 2r
re~errin~ to Frames A and D, will be changed from logic 1
. ~ to logis 0 to indicate that Frame D has been referred to
more recently than Frame A. Bit 3, referring to Frames B
25 and C, wilI remain logic 0. Bits 4 and 5, refer~ing ::
re~pectiYely to Frames B and D and Frames C and ~, will
be written as logic 0, although they are already logic
: zeros r to indicate re pectively tha~ Frame D has been
used more recently than Frame B or Frame C. Upon
~ 30 refere~ce to F~ame B, Bit 0, referring to Frames A and B,
,~
, . .
,
. . . . ,, . , ~. ~ , ., :
.. :. .
76~
-283-
; will be written to logic 0 to indicate that Frame B has
: ~ been used more recently than Frame A. Bits 1 and 2,
i~ referring resec~ively to Frames A and C and Frames A and
D~ will remain respectively as logic 1 and lagic 0. Bits
three and four, referring respectively to Frames B and C
and Frames B and D, will be writ~en as logics l's to
- indicate respectively that Frame B has been used more
recently than Frame C or Frame D. Bit f iYe will remain
~ logic 0~
:~ 10 When it is necessary to replace a cache entry in a
~:~ particular frame, the LRUL 24080 word referring to ~he
cache set containing that frame.will be read from LRUL ~ :
24080's M~RL 24081 through hRU Register (RhRU) 2408S and
decoded by LRU Decode Logic (L:RUD) 24087 to indicate
` 15 whi~h is least recently used framP. This decoding is
.. executed by means of a Read Only Memory operating as a
set of de~oding gating. ~.
Having described ~he structure and operation o~ a ~ -
. generalized cache as shown in Fig. 240, with references
to NC 10226 for illustration and to point out differences
. between the generali~ed cache and ~C 10226, structure and
operation of ATU 10228 and PC 10234 will be described
nex~ below. ATU 10228 and PC 10234 will be described by
:1 describing the diferences between ATU 10228 and PC 10234
..~, 25 and the generalized cache and NC 10226~ ATU 10223 will
:~ be describ~d first, followed by PC 10234.
, ,:' ~, '
;'.', ~:
, ;
; . .i .
...
... ..
,
,. ~,
; .
,, ,
. , . : .. , . . . , ~ .. ~ . i . .
,, .. . . ~.
, . .
... .: - . ~ ,
, . . . . .. . . ... .
,. :~ . . .,: ' ,
,- . . . , ~ . .
: .
.
~l7~76~
2 8 4
: ~d.d.
~:ATU 10228 is a three-way, set associative cache of 16
sets, that is contain~ 3 frames for each set.Structur
and operation of ATU 10228 is similar to the generalized
cache described above. Having 3 rather than 4 frames per
set, ATU 1022~ does not include a STD 24018, ATSCE 24026,
`~ ATSPRD 24034, ATSHED 24042t or ~DSD 24058. A~ previously
described ATU 10228 address inputs comprise AON and O
fields o:E logical descriptorsO AON fields are each 28
.~ bits and O fields comprise ~he 18 most significan~ bits
of logical descriptor offset ields, so that ATU 10228
address inputs aLe 48 bits wide. Your least significant
bits of O field~ are used as indexO AON fields and the
14 most significant bits of O field comprise ATU 10228's
, tags. ATU 102~8 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
. 20 ~ach 16 bi~s long~ ATU 10228 outputs are, as previously
: described, physical descriptor ~rame Number ~FN) field~
of 13 bit5 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 ATU 10228 set,
:~ are each 3 bits in width as 3 bits are sufficient to
~ indicate relative usage of frames within a 3 frame set.
. :
``''
..
..,
, . .
::
- .
. .
... .
,: . . .
: . .. . .
, ......
. :: - -
: . .~ . ,
7~766
-285-
In ATU 10228, Bit 1 of an LRUL 24080 word indicateswhether Frame A was used more recently than Frame Bl 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 sta~ed
above, ATU 10228 is 3imilar in structure 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
set. ~aving 2 rather than 4 frames, PC 10234 will not
include a TSC 24016, a ~SD 24018, a TSC~ 24024, a TSCD
240~6, a TSP~C 24032, a TSPRD 24034, a TS~EC 24040, a :
TS~ED 24042, a DSC 24056, or a DSD 24058.
- ~
:: Address inputs of PC 10234 are the 28 bit AON fields :
lS of lo~ical descriptors, The 3 least signi~icant bits of
: those ~O~ fields are utilized as indexes for addressing
~; PC 10234's TS 24010 and DS 24050. The ~5 most
' significant bits o those AOW field address inputs ar~
`: utilized as PC 10234's tags, so that PC 10234's TSA 24012
Z0 and TSB 24014 are each 8 word by 25 bit memories.
Re~erring to PC 10234'^~ LRUL 24080, a ~ingle bit is
suff1cien~ to indicate which of the t~o frames in each of
::: PC 10234's sets was m~st recently accessed. PC 10234's
LRUL 24080's memory is thereby 8 words, or sets long, one
bi~ wide.
.:;. As previously described, PC 10234 entries comprise
;. information re~arding access rishts 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
~:
,. .
, . -
~. .;
,. , :
.''',,~ .
, -, . ... . .
.. . , . . - . ~ ., -
. . , : . ,
:
.
.. ~ . , , ,:
.:
, . . . .
,, . ~ . . - ~, .,
1~'7~766
~ -286-
:~read, write, or execu~e rights relative to a particular
object~ The remaining 3~ bits effectively comprise a
~ength field indicating the volume or portion, that is
the number of data bits, of that ob~ect to which those
~: 5 access rights pertain.
Referring a~ain to Fig. 240, PC 10234 differs from
the generalized cache and ~rom NC 10226 and ATU 10228 in
further i~cluding Extent Check Logic (EXTCH~) 24082 and
::~.Operation Check Logic (OPRCHK) 24084. PC 10234 entries
include, as described above, 3 bits identi~ying type of
access rights a particular subject has to a particular
object. ~hese 3 bits, representing a Read (Rl, Write
(W), or Execute (E) right, are provided to a first input
~ o~ OPRCHR 24084. A second input of OPRCHR 24084 is
.~ 15 provided from FUCTL 20214 and specifies whether JP 10114
.: intends to perform a Read (RI), a Wri~e (WI), or Execute
(EI), operation with respect t:o that object. OPRC~
-:.; 24084 compares OPRC~R 24084 ac:cess right inputs.from DS
24~50 to OPRC~R 24084's intencted opera~ion input from
`~. 20 FUCT~ 20214. I~ that subject does not possess the rights
to th~t object which are re~uired to perform the
opera~ion intended by JP 10114, OP~C~g 24084 generates an
Operation Violation (OPRV) indicating that a protection
iolation 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, EXTE~T field of PC 10234 entry
. ~ indicates the length or number of data bits, within an
obect, to which those access rights pertain. EXTENT
30 ~ield from PC 10234 entry is compared, by EXTCEIK 240B2,
'''~;
,, ,
, ~ ,
,.
. :
-
7 ~ 6
-2~7-
to offset field of the logical descriptor of the current
JP 10114 request to MEM 10112 ~or which a current
;.`~ protection mechanism check is bein~ made. If comparison
of extent rights and offse~ field indicate tha~ the
s current memory request ~oes beyond the object length to
~ which the corresponding rights read from DS 24050 apply,
.;~ EXTCH~ 24082 genera~es an Extent Violation (EXTV~
output. EXTV indicates that a curren~ memory request by . .
JP 10114 refers to a portion of an object to which the PC
~- 10 10234 entry read from BS 24050 does not apply. As
described previou~ly, each read from or write to MEM
, 10112, e~en as part of a string transfer, is a 32 bit
:~. wordO As such, EXTC~ 24082 will generate an EXT~ output
. when OFFSET field of a curren~ logical descriptor
:.~ 15 describes a segment of an object less than 32 bits fro~ ~:
the limit defined by EXTENT field of the PC 10234 entry
provided in response to that logical descriptor. EXTV
. and OPRV are gated together, by Pro~ection Violation Gate
. ~PYG) 24086 to gener.ate Protection Violation ~PROTV)
; 20 output indicating that either an extent or an operation
: , violation has occurred.
: ~aving described the structure and operation o
- ~EMINT 20212, and previously the structure and operation
of DESP 20210, structure and operation of ~UCTL 20214
will be described next below.
.':~',
,
.
,:.
.. ~ ,...
". .
: i
.. . . .
. .,
. .
.
.. ..
. ' .
' . ' .
. .
~288-
; 3.
The following descriptions will provide a de~ailed
description of FU 10120' structure and operation.-
~:~ 5 Overall operation of FU 10120 will be described ~irst,
followed by description of ~U 10120's tructure, and
finally by a detailed description of ~U 101~0 opera~ion.
As previously described, ~UCTL 20214 directs
~- operation of JP 10114 in executing procedures of user's
:~ 10 processes. Among the functions performed by FUCTL 20214
are, first, maintenance and operation o~ CS 10110's Name
Space, UID, and AON based addressing system, previously
described; second, interpretation of SOPs of user's
: proce~ses to provide corresponding sequences of
microinstructions to FU 10120 and EU 10122 to control
operation of JP 10114 in execution of user's processes,
previously described; and, th.ird, control of operation of
. CS 10110's internal mechanism~3, for example CS 10110's
.~ stack mechanisms.
As will be described in further detail below, FUCTL
20214 includes Prefetcher ~PREF) 20260 which generates a
se~uence of logical addresses, each logical address
comprising an AQN and an offset field, for reading S-
Instructions (SINs) of a user's pro~ram from MEM 10112~
. 25 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~ SINs are read from ~E~
10112 as a sequence of single 32 bit words, so that PREF
:.
. ; -- j ~.
ç
,.. - . .- : , . . : .
- . :
766
-289-
: 20~60 need not specify a length ield in a ~EM 10112 read
: request fcr an SIN. SI~s are read from M~ 10112 through
: MOD Bus 10144 and are captured and stored in Instruction
~: Buffer (INSTB) 20262. P~RSER 20264 extracts, or parses,
50Ps and operand Mames from INSTB 20262. PARSER 20264
provides operand Names to NC 10226 and saPs to YUS
Intrepreter Dispatch Table (FUSDT) 11010 and to EU
Dispatch Table (EUSDT) 20266 through Op-Code Register
~` tOPCODERE~) 20268. Operation of INSTB 20262 and PARSER
~ 10 20264 is controlled by Current Program Counter (CPC)
'- 20270, Initial Program Counter (IPC) 20272, and Executed
. Program Counter (EPC~ 20274. .
. As previously described, FUS~T 11010 provides, for
'~ each SOP received from OPCODEREG 20268, a corresponding
S-Interpreter Dispatch (SD) Pointer, or address, to
FUSITT 11012 to select a corresponding sequence of
.` microinstructions to direc~ operation of JP 10114, in
. .
: particular FU 10120O As pre~iously described, FUSITT
`: 11012 also ~ontains sequences of microinstructions for
controlling and directing operation of CS 10110's
internal mechanisms, for example those mechanisms such as
.:` RCWS 10358 which are involved in swapping of proces~es.
E~SDT 20266 performs an analogous function with respect
-~ to EU 10122 and provides SD Pointers to EU S-Interpreter
:~ 25 Tables (EUSITTs) residing in EU I0122~
. Micro-Program Counter (mPG) 20276 proYides ~equential
;~ addresses to ~USI~T 11012 to select individual
: microinstructions of sequences of microinstructions.
. ~ .
.~. '
.
,
. , ' ' , ' . '
.
9o-
Branch and Case Logic (BRCASE) 20278 provides addresses
to FUSITT 11012 to select microinstructions sequences ~or
microinstructions branches and and case~. ~epeat Counter
:lREPCTR1 20280 and Page Number Register ~PNREG) 20282
.~g provide addresses to FUSITT 11012 during FU5ITT 11012
`load operations~
-As previously described, FUSITT 11012 is a writable
microinstruction control store which is loaded with
~:selPcted S-Intèrpreters (SINTs) from MEM 10112.
FUSITT 11012 addresses are also provided by Event
Logic (E~ENT) 20284 and by JAM input from NC 10226. As
will be described further below, EVE~T 20284 i part of
.~ FUC~ 20~14's circuitry primarily concerned with
.... operation of CS 10110's internal mechanisms. Input JAM
from NC 10226 initiates certai.n FUCTL 20214 control
functions for CS 10110's Name Space addressing
.. mechanisms, and in particular NC 10226. Selection
between the above discussed address inputs to FUSITT
~ : 11012 is controlled by S-Interpreter Table Next Address
.::` 20 Generator Logic (SITTNAG) 20286.
Other portions of FUCTL 20214's circuitry are
: concerne~ with operation of CS 1011013 internal
:~ mechanisms. For example, FUCTL 20214 includes Return
:~` Control Word S~ack (RCWS) 10358, previously described
. ~ 25 with reference to CS 10110's Stack Mechanisms. Register
Address Generator (RAG) 20288 provides pointers for
: addressing of GRF 1035~ and RCWS 10358 and includes
;
~ Micro-Stack Pointer Registers (MISP~) 10356.
,'
... .. . .
.
, .:
, . . . ~ . :'
~,. ' . ,''' . ',, '- ''~ ' ' ; ' ; ..
. . ~ , . ,: ;
~,: ' , , .
.~7~ 6
-291-
As p~eviously described, ~I5PR 10356 mechanismprovides pointers for addressing Micro-Stack ~IS)
.. 10368. As will be described ~urther below, actual MIS
~` 10368 Pointers pointing to current, previous, and bottom
frames of MIS 10368 reside in Micro-Control Word Register
. ~.
CWl) 20290~ MCW1 20~90 and ~icro-Control Word Zero
egister (MCWO) 20292 together contain certain
information indicating the current execution environment
of a microins~ruc~ion se~uence currently ~eing executed
lO by ~U 10120. This execution information is used in aide
i of execution of these microinstruction sPquences~ ~tate
.`: Registers (STATE) ~0294 capture and store certain
information regarding sta e of operation of ~U 10120. As
: described further below, this information, referred to as
state vectors, is used to enable and direct operation of
F~ 10120.
.` Timers (TIMERS) 20296 monitor elapsed time since
": 1
`' occurrence of the events re~uiring servicing by FU 10120.
If waiting time for thesP events exceeds certain li~its,
:j 20 ~IMERS 20296 indicate that these limits have been
exceeded so that service of those events may be
.` : initiated.
.;
Pinally, Fetch Unit to E Unit Inter~ace ~ogic
(FUE~INT~ 20298 comprises the ~U 10120 portion of the
. 25 inter~ace be~we~n ~U 10120 an EU 10122~ FUEUINT 20298 is
primary path through which operation of FU l0120 and EU
10122 is coordinated.
Having de~cribed overall operation of FU 10120,
structure of FU 10120 will be described next below with
, ~
, .
, . ,
, ~, .
, .
,:, . , . . . -
"
s ~ ' ,
~ ~7~L7~
--2g2-
aide of Fig. 202~ description of FU 10120's structure
will be followed by a detailed de~cription of FU 10120
: wherein further, more detailed, diagrams of certain
portions of FU 10120 will be in~roduced as required to
5 enhance clarity of presentationO
:` a O a . ~ = ~
~ Referring again to Fig. 202, as previously describ~d
`~ Fig. 202 includes a partial block diagram of FUCTL
10 20214~ Following the same sequence of description as
. abo~e, PREF 20260 has a 28 bit bi-directional port
connected to AON Bus 20230 and ~2 bit bi-directional port
directed from O~FSET Bus 20228. A control input of PREF
~ 20260 is connected from control output o I~STB 20262.
; 15 INSTB 20262 32 bit data input (DI) is connected from
~- MOD 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~ OPCODEREG 20268's
i.nput comprises 8 bits of SINT and 3 bits of dialect
~ 20 selection. As previously describedr NAM~ BU9 20224 is
; connected to 1~ bit bi-direc ional 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 PA~SER 20264 are connec . ed from a control output oE
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
: ~o 32 bit input of IPC 20272. Thirty-two bit output of
~ IPC 20272 is connected to 32 bit input of EPC 20274 and : ~ ~:
., .
. . .
~ , :
,:
.. ~ . . . . .
. : . . ~ ..
:
' " ' ' '
': '' ;
,
'
7~7 6
-~93-
~ . to JPD Bus 10142. EPC 20274's 32 bit output is similarly
:~ ` connected to JPD Bus 10142.
Eleven bit outputs of OPCOD~REG 20268 are connected
to 11 bit address inputs of FUSDT 11010 and EUSDT 20266.
: 5 These 11 bit address inputs to FUSDT 11010 and EUSDT
20266 each comprise 3 bits of dialect selection code and
i 8 bits of SINT code. Twelve bit SDT outputs of EUSDT
20266 is connected to inputs of ~icroins~ruction Control
~ S~ore in EU 10122, as will be described in a following
- 10 description of EU 10122. ~USDT 11010 has, as described
further below, two outputs connected to address (ADR) 8us
202980 First output of FUSDT 11010 are six bit SDT
., .
. pointers, or addresses, corresponding to generic SINTs a~
: will be descr ibed f urther below a Second output of ~USDT
. ,
:~` 15 11010 are 15 bit SDT pointers, or addresses, for
algorithm microinstruction se~uences, again as will be
described further below.
~:; Referring to RCWS 10358, ~CWS 10358 has a first bi-
directional port connected from JPD Bus 10142. Second,
0 third, and fourth bi-directional ports of RCWS 10358 are
::~ connected f~om, respectively, a bi-directional port of
;' M Wl 20290, a ~irst bi directional port EVENT 20284, and
::~ a bi-directional port of mPC 20276. An output of RCWS
10358 is connected to ADR Bus 20298.
~: 25 An input of mPC 20276 is connected from ADR 8us 20298
and first and second outputs of mPC 20276 are connected
to, respectively, an input of BRCASE 20278 and to ADR ~us
202980 An output of ~RCASE 20278 is connected to ADR ~us
20298.
' '
, .
1' ~
~' "' .
,: .
.; . ., . , ~ , , ~
$ - ~ ~ .
.
,
~1.7~ i6
~ -294-
, ~
As described above, a first bi-directional port of
-~ EVE~T 20284 is connected to RCWS 10358. A second bi-
~ directional port of EVENT 2028~ is connected from MCWO
-~ 20292O An output of ~VENT ~D284 is connected to ADR Bus
2~29~.
Inputs of RPCTR 20280 and PNREG 20282 are connected
:~: from JPD Bus 1014~. Ou~puts of RPCTR 20280 and PWREG
~ 20282 are connected to A~R Bus 20298.
.
ADR Bus 20298, and an input ~rom a first output of
~- 10 FUSITT 11012, are connected to inputs of SITTNAG 20286
Output of SITTNAG ~0286 is connected, through Control
~ Store Addr~ss (CSADR) Bus 20299, to address input of
.~ FUSITT 11012. Data inpuk of FUSITT 11012 is connected
from JPD Bus 10142. Control outputs of FUSITT 11012 are
connected to almost all elements o JP 10114 and ~hus,
:-: for clarity of presentation, are not shown in detail by ::
drawn physical connections but are described in following
. descriptions.
.:` As described above~ MCWO 20292 and MCWl 20290 have
ZO bi-directional ports connected to, respectively, bi
- directional ports of EVENT 2~284 and to a second bi-
;~ directional port o~ RCWS 10358. outputs of MCWO 20292 :~ .
~ and ~CWl 20290 are connected to JPD Bus 10142. Other : -
.~` inpu s of MC~O 20292 and MCWl 20290, as will be described ::
.. 25 further below, are connected from several other elements
of J~ 10114 and, for clarity of presentation, are not
shown herein in detail but are described in the following
text~ STATE 20294 similarly has a large number of inputs
.~
.
~'`;. ~
.
.''
.~ .. .
~ :. . , . , -
,.. ..
. .
: . .. ; . :
. ?
~L17~7~i
ss--
:
- and outputs connected from and to other elements of JP
10114, and in particular ~U 10120. Inputs and outputs of
~ STATE 20294 are not indicated here ~or clarity o~
:~ pre~entation and will be described in detail below.
-~ 5 ~G 20288 has an input connected from JPD Bus 10142
and other inputs connected, for example, from MCWl
20290. RAG 20288, including MISPR 10356, provides
outputs, for example, as address inputs to RCWS 10358 and
:: GRF 10354. Again, for clarity of presentation, inpu~s
: 10 and outputs of RAG 202~8 are not shown in detail in Fig.
- : 202 but will be described in detail further below.
~:~ TI~ERS 20296 receive inputs from EVENT 20284 and
:;:; FUSITT 11012 and provide outputs to EVENT 20284. For
clarity of presentation, these indications are not shown
in de~ail in Fig. 202 but will be described further
below.
FUINT 20298 re eives control inputs from FUSITT 11012
and EU 10122. FUINT 20298 provides outputs to EU 10122
~ and to other elements of FUCTI, ~0214. For clarity of
: 20 presentation, connections to and from FUI~T 20298 are not
- shown in dPtail i~ Fig. 202 but will be described in
further detail below.
Having described the overall operation, and
~: structure, of FUCTL 20214, operation o~ FUCTL 20214 will
25 be described next below. Durin~ the following
~ descriptions ~urther diagrams o certain portions of
; FUCTL 20214 will be introduced as required to disclose
~ struc~ure and operation of FUCTL 20214 to one of ordinary
,:
,, .; '~
,...
., ~
'
.~ . - -: - . -
.
, . . .
~"
7 ~;
-296-
skill in the art. FUCTL 20214's operation with regard tofetching and interpretation of SINs, that is SOPs and
operand Names, will be described first, followed by
de~cription of FUCTL 20214's operation with regard to CS
10110'q internal mechanisms.
b.b. _
~8~
: ~ Referring first to those elements of FUCTL 20214
directly concerned with control of JP 10114 in response
10 to SOPs and Name syllables, those elements include: (1)
PRE~ 20260; (2) INSTB 20262t t3) PARSER 20264; (4) CPC
.~ 20270, IPC 20272, and EPC 20274; (5) OPCODEREG 20268; (6)
: FUSDT 11010 and EU5DT 20266; (7) mPC 20276; (8) BRCASE
20278; (9) REPCTR 20280 and PNREG 20282; (10)- a part of
15 RCWS 10358; (11) SIT~NAG 20286; (12) FUSITT 11012; and,
(13) NT 20254. These FUCTL 20214 elements will be
:~ described below in the order named.
:~ a.aOa. r~f~ e~
.'
.~ 20 ~ L~bL.~02~::e~c=e~
: ~ ~,5~
, '' ~;c ~ -
.: As desrribed above, PREF 20260 generates a series of
25 addre~ses to MEM 10112 to read SINs of user's programs
~ from MEM 10112 to F~CTL 20214, and in particular to INSTB
.~ 20262. Each PREF 20260 read request transfers one 32 bit
word from MEM 10112. Each SIN may be compri ed of an SOP
and one or more Name syllables. Each SOP may comprise,
~;~ 30 for example, 8 bits of information while each Name
.
.. :, :
,................ .
,~ , . . .
,:, . . .
: , . . .. ..
. . . , : .... .. .. ..
- . . ... :, . : , i: .
c. ' ' :.
., . 1 ,.
,, . . . . ; . . . . .
, . .
7~ 6
~297-
.~ syllable may comprise, for example, 8, 12, or 16 bits of
:~ data. In general, and as will be described in further
~ detail in a following description of STATE 20294, PREF
: 20260 obtains access to MEM 10112 on alternate 110 nano-
- 5 second system clock cycles. P~EF 20260l~ access to MEM
: 10112 is conditional upon INSTB 20262 indicating that
~ INSTB 20262 is ready to receive an SIN read from ~EM
:: 10112. In particular~ INST8 20262 generates control
output Quiry Pre~etch (QP~ to PREF 20260 to enable P~EF
10 20260 to submit a request to ME~ 10112 when, as described
further below, I~STB 20262 is ready to receive an SIN
read from MEM 10112.
: PREF 20260 is a counter register comprised, for
~: example of S~74S163s.
:~ 15 Bi-directional inputs and outputs of PRE~ 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 spe ify a LENGT~ field as part of an SIN read
request, that is an AON and an OFFSET field are
~ 20 suf~icient to def ne a slngle 32 bit word. At start of
-: read of a sequence of SI~s from ~.EM 10112, address (AON
~ and OFFSET fields) of first 32 bit word of that SIN
; sequence are provided to ME~ 10112 by DESP 20210 and
concurrently loaded, from AON Bus 20230 and O~FSET 8us
25 20228, into PREF 2Q260. Thereafter, as each successive
:. thirty-two bit word of the SIN' 5 sequence is read from
MEM 10112~ the address residing in PREF 20260 is
incremented to specify successive 32 bit words of that
~ .
.
"; ' ,' ': '
. . .
,, ` ' ~ ,
7~7~
-298-
SIN's sequence. The successive single word addresses
: are, for all words after first word of a sequencef
p~ovided to MEM 10112 f~o~ PREF 202Ç0~
As de~cribed abo~el INSTB 20262 receives SXNs from
MEM 10112 th~ough MOD Bus 10144 and, with PARSER 20264
,- and operating under control of CPC 20270, provides Name
r ~yllables to N~E Bus 202~4 and SINs to OPCODEREG 20268.
:~ INSTB 20262 is provided~ to~ether with PREF 20260 to
.~ increa~e execution speed of SIMS r
Re~erring to Fig. 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. INSTB 20262 also receiv~s two Write Clock
~`" 15 (WC) inputs, one ~or each 32 bit register o INST~ 20262,
:. from Instruction Buffer Write Control (INSTBWC) 24110.
INSTB 20262'~ outputs are structured as eight, eight bit .
Basic Sylla~les (BSs), indicated as ~S0 to BS7. BS0,
~: BS2, BS4, and BS6 are 0Red to comprise eight bit Basic
. 20 Syllable, Even ~BSE) of INSTB 20262 while BS0, BS3, BS5,
and 8S7 are similarly ORed to comprise Basic Syllable,
; Odd (~SO) of INST~ 20262O BSO and BSE are provided as
inputs of PARSER 20264.
PARSER 20264 receives a first control input from
25 Current Syllable Size Register (CSSR) 24112, associated
with CPC 2U270. A second control input of PARSER 202~4
is provided from Instruction Buffer Syllable Decode
Register (IBSDECR) 24114, also associated wi~h CPC
20270. PARSER 20264 provides a~ eight ~it output to NAME
30 Bus 20224 and to input o~ OPCODEREG 20268.
,..
...
.,
.:.
~ '. '
,,.. , . ~ ~ .. . . :
~7~
.
-29~-
Referring to INSTBWC 24110~ INSTBWC 24110 provid~s~
as described further below, control signals pertaining to
writing of SIN~ into INSTB 20262 from MOD Bus 10144.
INSTB~iTC 24110 also provides control signals pertaining to
operation of PRE~ 20260. In addition to WC outputs to
INS'rB 20262, ~NSTBWC 24110 provides control output QPF to
: PREF 20260, control output Instruction Buffer ~lung
.~ (IB~UNG) to EVENT 20284, and control signal Instruction
Buffer Wait (IBWAIT) to STATE 20294~ INSTBWC 24110 also
10 receives a control input BR~NC~ from BRCASE 20278 and an.
error input f rom TIMERS 20296. .~-
Referring to CPC 20270, IPC 20272, and EPC: 20274, IPC
2û272 and EPC 20274 are represented in Fig. 241 as ir~
Fig. 202. Further FUCTL 20214 circuitry is shown as
15 associated with CPC 20270. CPC 20270 is a twenty-nine
bit register receiving bit~ one to twety-five (CPC(1-2S))
;, from bits one to twenty-:Eive of JPD Bus 10142. CPC 20270
~:: Bit 0 (CPCû) is provided from CPC0 CPCO Select (CPCOS)
~; . 24116~ Inputs of CPCOS 24116 are Bit 1 output from CYC
20 20270 (CPCl) and Bit 0 from JPD Bus 10142. Bits twenty-
:~; six, twenty-seven7 and twenty-eight of CPC 20270 (CPC(26-
28) ) are provided from CPC Multiplexer ICPCMUX) 24118.
CPCM~X 24118 also provide5 a~ input-to IBSDE~ 24114.
~-~ Inputs of CPCMUX 24118 are bits twenty-five, twenty-six,
25 and ~wenty-eight from JPD Bus 10142 and a three bit
output of CPC Arithmetic and Logic Unit (CPCALU) 24120.
A first input of CPCALU 24120 is connected from output
bits 26~ 27, and 28 of CPC 20270. Second input of CPCAI.U
, . .
~. ~
r', ~ \ J
1 ',
"
~".' ' ' ,
:
~,, :`. , . ,, . . . ': . ' . ' ' .
'' '' , ' ' ' . ~ ~ ~: . ' :
:: , ' ' ' : .- ' , : . :
.
' '
', :' : : ' "
DE~lMA~DE~Si OlJ BR~VETS VQLUMIIIYEIJIX
LA PRI~SENTE PARTIE DE G:ETTE 13EMANDE QILI CE E~RE\/ET
COMPREND PLUg; D'UI\I TOIVIE.
t::EC:I EST LIE TOME / DE -3
NOTE: Pour le~ tom~s additloneb, veuillez cont~cter le Bureau canadien de
br~vet~
,.,
. . ~ . . . ... .
,
''`'''
Jll.lNlBO APPII ICaTlClNlS/PATENlTS
~' . '
THIS 5ECT16:~N OF THE APPLIGATIONIPATE3UT CONTAII~IIS IlllORE
THAN ONE VOLUIVIE
THIS IS VOLUME /_ OF 3
NOT~: For ~dditional voJume~ ple~e contact the Canadian Patent OMic~
. ~ ~ '.............................. '
:- . .
