|
DataMuseum.dkPresents historical artifacts from the history of: RC4000/8000/9000 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about RC4000/8000/9000 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 57600 (0xe100)
Types: TextFile
Names: »hcmonrefinp«
└─⟦00964e8f7⟧ Bits:30007478 RC8000 Dump tape fra HCØ.
└─⟦b2ec5d50f⟧
└─⟦09c9e8a25⟧ »hc8mon«
└─⟦this⟧
<se *<
*pl 290,18,250,4,3**pn 0,0*
*lw 170**ps 0**sj*
H.C. Ørsted Institute
Computer Department
Universitetsparken 5
DK-2100 København Ø
*nl4*
*ct*
Monitor reference manual
for
the H.C. Ørsted Institute multicomputersystem
"hcmonref"
*nl8*
Anders Lindgård
*sj* *nl19**lm 120*
79-03 *lm120**nl*
Juni 1979
version 79-11-28
*rh 1,Communication and control 79-11-19*
*rj**pn 5,0**ps 18*
*lm0*
*rj*
*ld8**ns 1,2,0. Introduction*
---------------*ld16**nl**np*
This paper describes and discusses the design of
the monitor programs for the H.C. Ørsted
Institute multicomputersystem. It contains descriptions of
the new features and changed features relative to the RC4000/
RC8000 monitor initially developed by Per Brinch Hansen
(Brinch Hansen, 1973).*nl**np*
The scope for this project is to make a powerful modular
multicomputer system well suited to handle tasks with
very varying demand to the system.*nl**np*
The system should be well suited for as well long term
computations, control of large number of peripherals and
laboratory automation.*nl**np*
In the system the workload will be divided in a functional way,
rather than the usual way where emphasis is put on keeping
central processors busy.
Here one computer takes care of a single long term com-
putation, one is a controller for plotters, one for a
starnetwork of remote computers etc.*nl**np*
In the development there has been much emphasis on making this
system a clean extension of the RC4000/RC8000 multiprogramming
monitor. Interprocess communication, process creation and
removal are very similar. Communication between two internal
processes in two different computers is programmed in the same
way as if they were internal processes in the same computer,
but protected against each other.*nl**np*
This paper describes the basic version
as planned in the summer 1979. Extensions of the system are
planned.
*nl**np*
The multicomputer system shall take over laboratory automation
tasks now performed either directly using the multiprogrammed
RC4000 computer (Graae Sørensen and Lindgård, 1973; Lindgård, 1979a)
or using the attached hierarchical microcomputer star network (Lindgård, 1979b).
Long term computations using a slave minicomputer (Lindgård et al. 1977a) our
microcomputer based plotting system (Lindgård et al., 1977b; Moss and
Lindgård, 1979b) are to be handled by the multimicrocomputer system.
*nl**np*
This paper is to a large extent based on the authors experience
with a Motorola M6800 starnetwork controlled by the RC4000 com-
puter (Lindgård, 1979b).
*ld8**ns 1,3,0.1.Multicomputer systems*
-------------------------*ld16**nl**np*
We will define a multicomputer system as a set of
geographically close complete computer
systems having a fast communication system for
exchanging data.
The main differences between a multicomputer system and a
multiprocessorsystem is that in a multiprocessor system
there is a common store where any central processor
may fetch instructions from and in a multicomputer system there
must be a local fast store for each central processor.
From a software viewpoint user programs
in a multiprocessor system may have statements executed
in a truly paralel fashion while multicomputers runs
sequential programs only.
Multiprocessor systems tend to be very large and complex
(Enslow, 1974, 1976) as e.g. ILLIAC IV
(Barnes et. al., 1968). It is usually very hard to utilize
the large degree of parallellism in a high level language
compiler (Lawrie et. al., 1975).
Computer networks, as they usually are defined as geographically
remote interconnected stand alone computers, are the
other extreme (Kimbleton and Schneider, 19756). Here the communication
bandwith is usually rather small. Most wellknown is the ARPA
network (Roberts and Wessler, 1970).
*np*
Multicomputer systems have until now mostly been asymmetrical
as in the ASP system (Lorin 1972) and even contain widely different
computers (Lavington et. al., 1977). Some computers are front ends
for handling peripherals.
*ld8**ns 1,3,0.2. Design philosophy*
----------------------*ld16**nl**np*
The present hardware prices and their trend has made it possible to
start designing computer systems, where one does not try to optimize
the utilization of central processors or primary store. However
high quality high speed peripherals are still expensive and must
be shared by several users.
*np*
One of the greatest disadvantages of having a large number of
smaller stand-alone computer systems at a large institution is that
this type of organisation does not encurage sharing of software
resources and common development of software tools.
This is especially the case when the computers are of different
kinds. It is a very important issue in this design that it
should make sharing and exchange of software easy.
This is best done letting all computers have access to a
common large file store through the multicomputersystem.
*np*
Individual computers in this multicomputer system are cheap devices.
This implies that users, who have a high demand for computing time, can
have one or several computers running full time for a single project over
a long period of time. In many statstical mechanics problems the
computing time needed for one project is of the order of 1000 000 000 000
machine instructions executed, but often the computations can be so
structured so that they can be performed on a number of computers running
in paralel with very litle intercomputer communication.
*ld8**ns 1,3,1. New concepts and overview of hardware and software*
-----------------------------------------------------*ld16**nl**np*
The multicomputersystem described is a system of individual computers
connected to each other with a bussystem. The bussystem is
only used to transfer information between computers. A sketch
of the HCØ multicomputersystem is shown in figure 1.
The RC8000 computer bought from the manufacturer Regnecentralen acts as a front end for the multicomputer system.
The HC8000 computers are RC8000 like, but built at this institute.
*ld8**ns 1,2,1.1. Hardware*
-------------*ld16**nl**np*
This chapter describes briefly the features in the hardware
necessecary for implementation of a communication system.
*nl**np*
A HC8000 computer consist logically of 3 elements 1. central
processor (abbreviated CPU) which executes RC8000 like
instructions, 2. store and communication controller
(abbreviated SCC) which transfer information between the
CPU and the store, handles messages and block transfer on
the inter computer bus (abbreviated ICB) and DMA transfers
to/from local peripherals, 3. the primary store containing an
autoload program in a read only store and the monitor
and user program in a random access store.
*nl**np*
The modularity of the hardware with only a few basic modules,
makes it simple to interchange hardware elements in case
of a breakdown of a module. Further such a breakdown will in
general not affect any other computer in the system, but only
degrade the performance of the system.
*nl**np*
Both the CPU and the SCC are microprogrammed bit slice computers.
The store and communication
comtroller SCC has a number of busses. One towards the central
processor and the local store and one which is 'inter computer bus'
and is shared by all microcomputers in the system.
Any further busses are for local peripherals requiring direct
store access.*nl**np*
The inter computer bus is used for 1) block transfers between
computers 2) sending of interrupts signals with associated
data 3) for allowing any central processor to read in any local
store using ordinary instructions.*nl**np*
To facilitate that the RC8000 should be able to perform the same
tasks as other computers in the system, this computer has a
HC8000 central processor and store and communication controller (SCC)
attached to the RC8000 bus see fig. 1.*nl**np*
Any type of transfer between two microcomputers goes one word
at a time in the sequence 1) request to be master of the bus 2)
send address 3) execute transfer (read data) 4) release
bus. *nl**np*
For a block transfer a microcomputer has 4 registers 1) own
current address 2) computer number 3) external current address
4) word counter.
*nl**np*
The SCC has 16 internal registers of which most are used in connection
with the CPU for address calculation, interrupts etc. As the few registers
left is not really enough for handling the intercomputer communication
one register, the information register points, to a fixed store
area where some registers used in connection wih the message
handling are found.
*nl**np*
Messages on the hardware level executed by the SCC are called
'hmess'. The receiving computer will as a response to a 'hmess'
generate a 'hresponse'. If this does not happen within
a specified time the hardware generates a timeout signal.
*nl**np*
The information register is loaded during the autoload sequence.
It points to a dataarea in store holding information about
SCC activities. In this data area there is described a FIFO for incoming
"hmess" messages, a record for outgoing "hmess"
message which are executed one at a time and a record for
"hresponse".
*nl2*
*ld8**ns 1,2,1.2. Software*
-------------*ld16**nl**np*
*rj*
The software developed for the multicomputersystem consist
of a number of modules for basic communication between computers
and for control of processes. The process concept used here
is the same as used in then RC4000/RC8000 computers as described
by Brinch Hansen (Brinch Hansen, 1973). The interface
between processes in different computers has been kept as
close as possible to the interface between processes in the
RC4000/RC8000 computers. This enables us with hardly any
reprogramming effort to use all the basic software for
the RC8000 in the HC8000 computers.
*nl**np*
In each computer a number of processes may be active. An
internal process is defined as a computational process and is
intended for userprograms. In the HCØ multicomputersystem we
allow internal processes in different computers to communicate
with each other. In the basic version we have the restriction
that internal processes in the HC8000 type computers may only
communicate with RC8000 internal processes.
*ld8**ns 1,4,1.2.1. PROM monitor*
-------------------*ld16**nl**np*
The basic interrupt handling in a HC8000 computer is handled
by a small program in a PROM. This PROM monitor interpretes
incoming 'hmess' messages and in case of commands like
autoload it initializes the system and makes it ready for
loading the monitor program. The PROM monitor will further
initialize the system in case of a power interrupt or
a monitor breakdown.
When an autoload command has been received by the PROM
monitor this computer will only accept messages from
the computer which issued the autoload until
a start monitor command has been given.
*ld8**ns 1,3,1.3. New process types*
----------------------*ld16**nl**np*
We adapt the process types of Brinch Hansen internally in the
computers. To make processes in other computers known and
to handle resources in other computers we need to intruduce
some new process types which describes processes in other
computers.
*ld8**ns 1,2,1.3.1. Mirror process*
---------------------*ld16**nl**np*
A mirror proces is an internal process description which simulates an internal
process in another computer.
The resources described in a mirror process
are 1) the resources in this computer 2) the initial resources
for the internal process it is a mirrorprocess of (provided
theese resources have not been changed by allocation to a
childprocess).
*ld8**ns 1,2,1.3.2 Master mirror process*
---------------------------*ld16**nl**np*
A mastermirrorprocess describes the resources
available in the other computer for further
creation of internal processes.
*ld8**ns 1,2,1.3.3. master process*
---------------------*ld16**nl**np*
This is the initial process in a HC8000 computer after loading and
initialization of the monitor. It has all the resources of the
computer. On request from other computers it will create internal
processes and mirror processes. It is described in the RC8000
by a master mirror process.
In the RC8000 the master process has only a small part of the resources
as processes in other computers cannot create internal processes in the
RC8000.
*ld8**ns 1,4,1.3.4. Process creation*
-----------------------*ld16**nl**np*
Internal processes in other computer are created and
controlled by the same monitor procedures used in
the RC8000 for internal processes therein.*nl**np*
After systemstart in the RC8000 there exist a master-
mirrorprocess for each HC8000 computer connected and
loaded with a monitorprogram.*nl**np*
After systemstart and loading of a monitor in an HC8000 computer a master process
owning all resources is created. This is
signalled to the RC8000, which then creates a master
mirror process.*nl**np*
When an RC8000 process call the monitorprocedure create
internal process (other computer), where the
other computer is just loaded with a monitor, the
following takes place in the other computer:*nl**np*
*lm20*
A mirror process describing the calling process is
created and started. An internal process which is a
child of this mirror process is created.
In the RC8000 a mirrorprocess of this childprocess
is created.*lm0**nl**np*
Further children may be created by the calling process,
however only one mirrorprocess of the
calling process is created.
*ld8**ns 1,3,1.3.3. process control and removal*
----------------------------------*ld16**nl**np*
Control of processes in other computers, as well as
creation and removal of processes is performed using
the standard RC8000 monitor procedures:
*ld8*
*sj*
create internal process
modify internal process
stop internal process
start internal process
remove process
*lm0*
*rj**nl**np*
The monitorprocedures "modify internal process" will
when called perform the necessecary actions on the
child process in the other computer and its mirror-
process in the other computer in the same way as
for an internal process in the RC8000. "remove process"
will also remove the mirrorprocess of the calling
process provided the calling process do not have further
children in the other computer.
*ld8**ns 1,3,1.4. Communication and block transfer*
-------------------------------------*ld16**nl**np*
*ld8**ns 1,2,1.4.1. Message*
--------------*ld16**nl**np*
In this system we distinguish between the following types of
messages and answers.
*ld8**nl**lm40*
*mt 1, 1.* Hardware messages and responces
abreviated: 'hmess' and 'hresponse'
*nl*
*mt 1, 2.* primitive messages and answers
abreviated: 'pmess' and 'panswer'
*nl**mt 1, 3.* commands
*nl**mt 1, 4.* Messages and answers in the usual
RC4000/RC8000 sense using messagebuffers.
Those are here called ordinary messages and ordinary answers
*ld16**lm0*
*rj**nl*
*lm 22*
*mt 1,1)* a hardware message or response is executed by the
SCC of one computer, the 'sender', and received by the SCC of
another computer the 'receiver'. A hardware message has a
time out which is cleared by a 'response' from the other
computer, see above*nl2*
*mt 1,2)and 3)* primitive messages, primitive answers and
commands are used by the monitorprograms in two computers for
interchange of information at the monitor level. A monitor has
a process 'systrm' for sending primitive messages and a process
'sysrec' for receiving primitive messages. Commands are handled
by a coroutine in the PROM monitor.
*nl2*
*mt 1,4)* Unchanged from the RC4000/RC8000 system except that
messagebuffers have been extended by the address of the mirror
messagebuffer.
*lm0**nl*
*ld8**ns 1,2,1.4.2. Mirror messagebuffer*
---------------------------*ld16**nl**np*
A mirror messagebuffer is a messagebuffer in the receiving computer which has the same
information content as the messagebuffer in the sending com-
puter.
Theese are necessary as messagebuffers are queued and there is a
single address space for each computer.
*rj*
*ld8**ns 1,3,1.5. System processes*
---------------------*ld16**nl**np*
After initialization all computers
in the system will have a set of system processes for basic
handling of the message traffic and for handling blocktransfers.
*ld8**ns 1,3,1.5.1. Transmitter process*
--------------------------*ld16**nl**np*
The transmitter process 'systrm' handles a single queue of messagebuffers
containing ordinary messages, ordinary answers,primitive messages, primitive answers and commands to
be send to other computers. For each messagebuffer a 'hmess' is generated
and a 'hresponse' is waited for indivisibly.
*ld8**ns 1,3,1.5.2. Receiver process*
-----------------------*ld16**nl**np*
The receiver process 'sysrec' handles 'hmess' messages from other computers
Theese are initially stored in the FIFO (see chapter 1.1.1.). 'sysrec'
acknowledges theese messages by sending a 'hresponse'. *np*
If the 'hmess' describes a command the necessecary actions are performed
by 'sysrec' or by the PROM monitor. *np*
If the 'hmess' describes a message, a messagebuffer is selected and
the message sent to the internal process.
*np*
In case of an answer the messagebuffer queue of 'sysrec' is scanned.
If a message buffer waiting for that answer is found the answer is
delivered.
*ld8**ns 1,3,1.5.3. Blocktransfer process*
----------------------------*ld16**nl**np*
The block transfer process handles a single queue of messagebuffers
with input messages from processes in this computer. The
input takes place from a specified absolute address.
*ld8**ns 1,3,1.5.4 Master processes*
-----------------------*ld16**nl**np*
The master process of a computer receives monitor calls of the
control type where the destination process is found in another
computer. In a HC8000 computer it receives calls from the
PROM monitor containing monitor calls from other computers.
Master mirror processes just sends ordinary messsages to the
master process it is a mirror process of.
*ld8**ns 1,3,1.6. primitive messages*
-----------------------*ld16**nl**np*
Primitive messages are used for communication between master processes
in different computers for transfer of monitor calls. In a "hmess" a
primitive message is specified by the 'primitive bit' being set. The
last part then gives the address of the primitive message.
*ld8**ns 1,3,1.7.Handling of blocktransfers on the user level*
------------------------------------------------*ld16**nl**np*
It is only possible for a process to input datablocks from
other computers. In each computer the monitor simulates a
process 'netdma' which an internal process may call to read
a block from any computer at any time.
*ld8**ns 1,3,1.7.1. Output a block. (user A to user B)*
-----------------------------------------*ld16**nl**np*
The sending process issues a standard output message to the
process in the same computer simulating the foreign internal
process B i.e. mirror process.
This message will be read by the receiving process,
which then performs the input and returns an answer.
*ld8**ns 1,3,1.7.2. Input of a block (user A to user B)*
------------------------------------------*ld16**nl**np*
User A issues an input message which is transferred to user B as
for the output message. User B cannot perform output but calls the
local master process using the monitor call 'copy core'.
The master process for user B sends a primitive message to the
master process of user A, which then
reads the addresses in user B and
makes transfer by sending a message to 'sysdma'.
*ld8**ns 1,3,2. Discussion*
-------------*ld16**nl**np*
The design presented here extends a multi process computer to
a multi process multicomputer system with a very moderate
software development effort. All software for the original
computer can be used in any of the computers in the
multicomputer system, as the computers have the same
instruction set and the interface between processes is
virtually unchanged.
*lm0**rj*
*ld8**ns 1,3,3. Acknowledgement*
------------------*ld16**np*
The enlightning and valuable discussions with Dr. P. Graae Sørensen
and Dr. R. Moss
during the years has had a great impact on the project.
Carsten Gyrn made the assembler for the micro code and implemented
the microprograms.
J. Oxenbøll implemented the hardware.*nl2*
*rj*
*ps0*
*ld8**ns 1,2,4. References*
-------------*nl2*
*sj*
Barnes G. H., Brown R. M., Kato M., Kuck D. J.,
Slotnick D. L. and Stokes R. A. 1968
IEEE Trans. Comput. _«bs»1_«bs»7 746-757
Brinch Hansen P. 1970
Comm. ACM _«bs»1_«bs»3 238-250
Brinch Hansen P. 1973
Operating System Principles
Prentice Hall, Englewood Cliffs, New Jersey
Enslow P. H. 1974
Multiprocessors and parallel Processing
Wiley, New York
Enslow P. H. 1976
Comp. Surv. _«bs»9 103-129
Graae Sørensen P. and Lindgård A 1973
Computers in Chemical Research and Education
Ed. D. Hadzi, Elsevier, Amsterdam
Kimbleton S. R. and Schneider G. M. 1975
Comput. Surv. _«bs»7 129-173
Lavington S. H., Thomas G. and Edwards D. B. G. 1977
IEEE Trans. Comp. _«bs»2_«bs»6 19-28
Lawrie D. H., Layman T., Baer D. and Randal J. M. 1975
Comm. ACM _«bs»1_«bs»8 157-164
Lindgård A., Graae Sørensen P. and Oxenbøll J. 1977a
Comp. & Chem _«bs»1 277-285
Lindgård A., Graae Sørensen P. and Oxenbøll J. 1977b
J. Phys. E Scientific Instrumentation _«bs»1_«bs»0 264-270
Lindgård A. 1979a
Software Pract. & Exper. _«bs»9 xx-xx
Lindgård A. 1979b
submitted to Comp. & Chem.
Lorin H. 1972
Parallelism in Hardware and software
Prentice Hall, Englewood Cliffs, New Jersey
Moss R. and Lindgård A. 1979
Comput. & Graphics _«bs»4 51-61
Roberts L. G. and Wessler B. D. 1970
Proc. AFIPS _«bs»3_«bs»6 543-549
*rj*
*lm0*
*rh 1,Exact formats 79-11-29*
*ps0*
*ld8**ns 1,2,5. Exact Formats*
----------------*ld16**nl*
*ld8**ns 1,2,5.1.1.Use of information register*
---------------------------------*ld16**nl**np*
*ld8**sj*
inf - 8 ; FIFO first
- 6 ; FIFO last
- 4 ; FIFO low
- 2 ; FIFO high
0 ; status SCC
2 ; hmess receiver<12 +sender (set by monitor)
4 ; hmess address (set by monitor)
6 ; hmess data (received)
8 ; hmess status (set by SCC)
10 ; hresponse receiver<12+sender (set by monitor)
12 ; hresponse address (set by monitor)
14 ; hresponse data (received)
16 ; hresponse status (set by SCC)
18 ; command_in receiver<12+sender (received)
20 ; command_in address (received)
22 ; command_in data (not used)
24 ; command_in status (set by SCC)
*rj*
*sj*
Status bits SCC (inf+0):
1<22 command
1<21 after autoload
1<20 locked (only messages from the RC8000 are accepted)
Status bits (inf+8, inf+16, inf+24):
1<23 data overrun
1<22 bus parity error
1<21 bus timeout
Data bits (inf+6, inf+14, inf+22)
1<20 rejected
*rj**ld16**nl2*
The SCC status indicates whether the incoming ICB
request is a command or a message. Commands are stored
on the command_in record while messages are stored on
the FIFO stack. Only one command may be processed at a time
and only one computer in the network may issue commands.
*nl2*
Use of the FIFO (First in, first out stack)*nl**np*
In comming 'hmess' messages are stored in the FIFO by the SCC.
When a 'hmess' arrives it is checked that FIFO low and FIFO high
are different.
If there are still free records on the FIFO
the 'hmess' is stored from the FIFO high and onward and FIFO high
is incremented by 8, else the data returned will contain the
rejected bit. The CPU now receives an interrupt and
control is given to the monitor
which then sends a hresponse.
*nl**np*
The SCC takes care of adjusting FIFO low og FIFO high to be
within FIFO first and FIFO last.*nl2*
*sj*
*ld8*
FIFO record:
+ 0 receiver <12 + sender (generated by sender)
+ 2 address (generated by sender)
+ 4 used by monitor
+ 6 used by monitor
*rj*
*ld16*
*ld8**ns 1,2,5.1.2. Send 'hmess'*
-------------------*ld16**nl**np*
The monitor will set a 'hmess' up in inf + 2 to inf + 8.
The SCC wil when when asked to execute a 'send hmess'
instruction request the bus to become a master. The monitor
will only send one 'hmess' at a time. When the SCC has become
master the 'hmess' is send and data is read back to inf + 6.
An interrupt to the CPU is given.*nl*
*sj*
*ld8*
Use of address in a 'hmess'
bit 0 = 1
bit 1 command = 1, mess or answ = 0
Command mess/answ
bit 2 autoload mess = 1, answ = 0
bit 3 lock response
bit 4 unlock rejected
bit 5 set testmode release
bit 6 stop all int. primitive
bit 7 restart internals bit 7 - 23 are treated as an
address of a message or answer
bit 8 start monitor
*ld16**rj*
*nl**np*
*ld8**ns 1,4,5.1.3. Messages to master process*
---------------------------------*ld16**nl**np*
A) messages from an RC8000 user process*nl2*
*np*
Messages can be initiated from a process which has bit x
set in the function mask.
*nl2*
Messages and answers:*nl2**sj*
*ld8**se !*
operation message answer
start monitor 2<12+mode status
start internals 4<12+mode status
stop internals 6<12+mode status
set testmode 8<12+mode status
unlock computer 10<12+mode status
lock computer 12<12+mode status
output 5<12+mode status
first address bytes
last address characters
first other
computer number
autoload segment 7<12+mode status
first address* bytes
last address* characters
notused
computer number
*first must be less than 1<20-1
last must be >=first+510.
Only 512 bytes is transferred.
!se *! *ld16*
*nl2**np*
B) messages generated by monitor*nl2*
*np*
If a monitor call jd 1<11+<number> where number is 58 or greater
designates a process in another computer (through a mirror process)
a messagebuffer is send to the master
process. For the new message buffer format see x.x.x.x.
*nl2**sj**ld8*
Message buffer format (monitor call type)
buffer address:
-8 0
-6 -1
-4 -1
-2 0
0 <next buffer>
2 <previous buffer>
4 <receiver=master process>
6 <sender =calling process>
8 1<22+<number>
10 save w0 (calling process)
12 save w1 "
14 save w2 "
16 save w3 "
*nl2**rj*
*np*C) Messages from master process to transmitter*nl2*
*np*Changes relative to B (primitive messages).*nl**sj*
buffer address
-6 receiving computer<12+this computer
-4 process description in other computer or 0
D) message buffer format (user process A to user process B
in the queue of mirror B in computer A)
A refers to this computer, B to the other computer.
buffer address
-8 0
-6 0
-4 0
-2 save w2 of user A
+0 <next buffer>
+2 <previous buffer>
+4 <receiver=mirror B in A>
+6 <user A in A>
+8 <operation<12+mode>
Changes when transferred to transmitter in A
buffer address
-6 receiving computer<12+this computer
-4 process address of user B in B
The mirror message buffer in B when created by the receiver in B
buffer address
-8 buffer address of real buffer in A
-6 this computer<12+sending computer(=A)
-4 process address user A in A
-2 save w2 of user A
+4 <receiver=user B in B>
+6 <sender=mirror A in B>
After call of send answer
buffer address
+4 result
+8-+22 answer
Real message buffer in queue of receiver
unchanged from transmitter
When answer received by receiver.
buffer address
+4 result
*rj*
*ld8**ns 1,4,5.2. Communication and control*
------------------------------*ld16**nl**np*
*ld8**ns 1,4,5.2.1. SCC functions*
--------------------*ld16**nl*
*ns 1,3,ICB working cycle**nl**np*
When a sending SCC has become the bus master is sends
receiver<12+sender to the bus. All SCC's connected to the
ICB will read this to determine whether they are addressed.
The sending SCC then sends the address part of the 'hmess'.
The addressed SCC responds with a data word or a bus timeout
will be given back to the sending SCC.
*ns 1,3,SCC microprogram procedures and register use*
*nl**np*
For handling other computers connected to the ICB the
SCC has a number of procedures and some registers. Other
registers in the SCC is used for communication with the
CPU. The computer number is set by some switches on
the SCC board and can be read the SCC.
The registers used are:
*nl**lm10**sj*
no name used as
*ld8*
4. IR information register
5. PC program counter
7. WA working register A
8. WB working register B
9. DA DMA input address
10. DW DMA input word counter
11. DO DMA input address other computer
12. DR DMA input receiver<12+sender
13. RS communication receiver<12+sender
14. R1 register
15. R2 register
Q working register
*rj*
*lm0*
*ld16*
*ns 1,2,Microprogram description*
*nl**np*
In the following a sketch of the microprogram in the SCC
relevant to communication with other computers will be given.
This will be done in an ALGOL like language using the following
nonconventional notations:
*lm10**nl*
"register" is the declaration of a 24 bit internal register
in the SCC the bits are numbered from left to right 0 to 23.
*nl*
"constant" is the declaration of a constant external
to the SCC which can be read by a single microinstruction.
*nl*
"bitfield" is a pointer to a set of bits. The bit(s) are indicated
in the declaration.
*nl*
<register>.<bitfield> indicates a specific bit or a set of bits
in a register. This is a boolean.
*nl*
The operators "lbyte" and "rbyte" gives the left and right halfword
of a register.
*nl*
The operators < and > shift the operand to the left or right
respectively. The shift is a logical shift with 0 shifted in
the empty positions.
*lm0**nl2*
A set of predeclared procedures is used. They are either
input/output procedures or coroutine waiting points.
*nl*
Text to the left of a ; is a comment.
*ps0*
*ns 1,3,Pseudocode*
*nl2**lm10*
*ld8**sj*
DECLARATIONS:
begin
comment declaration of registers;
register IR,WA,WB,DA,DW,DO,DR,RS,R1,R2;
constant this= "computer number",RC8000="RC8000"
comment declaration of bit fields. The bits equal to one
gives the set of bits the bit field points to.;
bitfield hmessmess (1<23), command (1<22),
autoload (1<21), mess (1<21),
lock (1<20), response (1<20),
unlock (1<19), rejected (1<19),
settest (1<18), release (1<18),
stopall (1<17), primitive (1<17),
startall (1<16),
startmon (1<15),
pmaddress (-1>7),
overrun (1<23), busparity (1<22),
bustimeout(1<21), noresources(1<20);
comment declaration of the store of this computer;
integer array store(1:maxword);
record FIFO(1:4),hmess(1:4),hresponse(1:4);
sequence F_S(1:no of records) of FIFO;
PROCEDURE HEADS PREDECLARED PROCEDURES:
procedure put(FIFO);
record FIFO;
comment puts a record on the FIFO sequence F_S;
procedure get(FIFO);
record FIFO;
comment makes the oldest record in the FIFO sequence F_S;
boolean procedure empty;
comment true if all records in the FIFO sequence F_S are free;
boolean procedure full;
comment true if all records in the FIFO sequence F_S are used;
procedure reset_FIFO;
comment the FIFO is reset to its initial state empty;
procedure waitbusactivity;
comment this procedure is a waiting point. A return to
the next instruction will take place when this
SCC is addressed on the ICB bus;
procedure busmaster;
comment this procedure is a waiting point, A return to the
next instruction will take place when this SCC
becomes the master of the ICB bus.
*nl*
procedure writebus(word);
register word;
comment this procedure writes a single word to the
ICB bus;
*ps0*
integer procedure readbus;
comment this procedure read a single word from the
ICB bus.
integer procedure icbstatus;
comment this procedure reads the hardware status of
the latest bustransfer;
*nl*
procedure return;
comment returns control to the HC8000 CPU;
procedure send_interrupt(interrupt_address);
integer interrupt_address;
comment jumps to an interrupt address in the PROM monitor;
*nl*
SCC ADRESSED:
wait_bus_activity;
RS:=read_bus; receiver<12+sender;
if lbyte RS = this then
begin
WA:=read_buss; address part;
if -,WA.hmessmess then
begin
comment DMA transfer inititated by other computer or
instruction controlled read by other computer.;
WB:=store(WA);
write_bus(WB);
end WA>0 else
begin
comment a message, response or command is received;
if WA.command then
begin
comment handle command;
SCCstatus.command:=true;
if WA.autoload and -,empty then reset_FIFO;
command_in(1):=RS;
command_in(2):=WA;
WA:=0;
writebus(WA);
send_interrupt(interrupt_command);
end else
if full or (SCCstatus.lock and rbyte RS<>RC8000) then
begin
WA:=0;
WA.rejected:=true;
writebus(WA); return information;
return;
end else
begin
comment F_S has at least one record available;
SCC_status.command:=false;
WB:=ICB_status;
if WB=0 then
begin
WA:=0;
writebus(WA); return information, message accepted;
FIFO(1):=RS;
FIFO(2):=WA;
put(FIFO);
send_interrupt(interrupt_message);
end;
return;
end;
HMESS:
begin
comment called by an RC8000 instruction which first has stored
receiver<12+sender in hmess(1) (inf+2) and the message
(address) in hmess(2) (inf+4).
busmaster; wait for control of ICB;
WA:=hmess(1);
writebus(WA);
WA:=hmess(2);
writebus(WA);
WA:=readbus;
WB:=ICB_status;
hmess(3):=WB;
return;
end;
*lm0**rj*
*ld8**ns 1,4,5.2.2. Sketches of block transfers*
----------------------------------*ld16**nl**np*
Block transfers between user process A in computer A and user process B
in computer B.
*ld8**sj*
A ) input for A from B
user process master process user process master process
A (A) B (B)
send_m(B,input) wait_m(A)
copy_core(B,A)
send_m((A),output)
wait_m((B))
send_m(dma,input)
wait_a(dma)
send_a((B),answer) wait_a((A),answer)
monitor_result
send_a(A,answer)
wait_a(B,answer)
B) output from A to B
send_m(B,output) wait_m(A,message)
copy_core(A,B)
send_m(dma,input)
wait_a(dma,answer)
monitor_result
send_a(A,answer)
wait_a(B,answer)
*rj*
*ld8**ns 1,4,5.2.3. Sketches of the code*
---------------------------*ld16**nl**np*
In this chapter the code for the different processes will
be sketched using a rather informal language.
*ld8**ns 1,3,5.2.3.1. Interrupt handler (PROM monitor).**ld8*
*nl*
*sj*
interrupt_command: ; normal waiting point for commands;
if monitor.state=not_present then
begin
if sender<>RC8000 then
begin
send_hmess(sender,hresponse,rejected)
return;
end;
address:=command_in(2);
if address.autoload then
begin
monitor.autoload:=true;
autoload_address:=address extract 20;
load_segment(load_address,autoload_address);
load_address:=load_address+512;
send_hmess(sender,hresponse);
end else
begin
comment other commands;
if address.start_monitor then
begin
monitor.started:=true;
monitor.present:=true;
goto MONINIT; initialize monitor. fixed address;
end;
end commands other
return;
end not_present else
begin
comment monitor.state=present;
if address.command then
begin
if address.autoload then
begin
monitor.state:=not_present;
monitor.locked:=true;
monitor.started:=false;
load_address:=0;
monitor.testmode:=false;
monitor.internals_running:=false
goto interrupt_command;
end;
if address.lock then
begin
monitor.locked:=true;
load_address:=0;
end else
if address.unlock then monitor.locked:=false;
if address.start_all_internals then monitor.internals_running:=true;
if address.stop_all_internals then monitor.internals_running:=false;
end command;
return;
end command interrupt;
interrupt_message:
if monitor.state=not_present then goto ERROR_RESPONSE;
if monitor.state=locked and sender<>RC8000 then goto ERROR_RESPONSE;
begin
comment message or answer;
goto RECEIVER;
end;
INITIALIZE: After a power upstart the PROM_monitor starts here;
begin
comment called by power upstart;
monitor.state:=not_present;
monitor.locked:=true;
monitor.started:=false;
load_address:=0;
monitor.testmode:=false;
monitor.internals_running:=false;
goto wait_interrupt;
end;
*ld8**ns 1,4,5.2.3.2 Transmitter process*
*nl**np*
WAIT_MESSAGE:
send_hmess;
wait_hresponse or timeout;
send_answer;
go_to WAIT_MESSAGE;
*ld8**ns 1,4,5.2.3.3 Receiver process*
*nl2*
WAIT_HMESS:
send_hresponse;
if message then
begin
select_message_buffer;
sender:=mirror_process_B;
send_message(receiver_process);
end else
begin
examine_queue;
if -,found then return else send_answer;
end;
goto WAIT_HMESS;
*ld8**ns 1,4,5.2.3.4. DMA_process**ld8*
*nl2*
WAIT_MESSAGE;
transfer_block;
send answer;
goto WAIT_MESSAGE;
*ld8**ns 1,4,5.2.3.5. Master process RC8000**ld8*
*nl2*
WAIT: ; a master process is called by a jd 1<11+<number>
; where the destination process is in another computer.
; Priviledged processes may call a master process for
; loading a monitor or sending commands to
; the other computer.
wait_event_or_process;
if event then goto EVENT;
user_process_RC.state:=wait;
send_primitive(transmitter,Master_B);
wait_answer;
send_message(receiver);
wait_answer;
deliver_monitor_procedure_result;
user_process_RC:=running;
goto WAIT;
EVENT:
if message and priviledged then
begin
send_primitive(transmitter,Master_B);
wait_answer;
send_message(receiver);
wait_answer;
send_answer(result);
end else
begin
send_answer(rejected)
end;
*ld8**ns 1,4,5.2.3.5 Master process B (in another computer)**ld8*
*nl2*
WAIT:
; except for the 'copy core' command jd 1<11+70
; this master process is only called from the RC8000 in
; the first version of the system.
; The primitive message will allways specify a jd 1<11
; command. All checking has been performed in the
; RC8000;
wait_event_or_process;
if process then
begin
copy_core;
end else
wait_primitive_message;
inter_prete_message;
jd 1<11+<number> ; call procfunc;
send_answer;
goto WAIT;
*ld8**ns 1,4,5.2.3.6 Mirror process B (in the RC8000)**ld8*
*nl2*
WAIT:
wait_event; this process handles the communication to the
; transmitter and receiver in block transfers
; and other message;
if message then
begin
if input_unconditionally then
send_message(dma_process,message) else
send_message(transmitter,message);
goto WAIT;
end else
begin
comment answer;
if answer_from_dma_process then
begin
wait_answer;
send_answer(user_process_RC,answer);
end else
if answer_from_transmitter then
begin
wait_answer;
if message originates from user_process_RC then
send_message(receiver) else release buffer;
end else
if answer_from_receiver then
begin
wait_answer;
if input_conditionally then
begin
send_message(dma_process,message);
end;
send_answer(user_process_RC,answer);
end receiver else
if answer_from_user_process_RC then
send_message(transmitter,message);
goto wait;
end;
*rh 1,monitor procedures 1979-11-12*
*lm0**ps0*
*rj*
*ld8**ns 1,4,6. Changes in monitor*
*ld8**ns 1,4,7. Monitor procedures in the RC8000*
-----------------------------------*ld16**nl**np*
This chapter describes how some monitor procedures work when
applied to computers in the RC8000 multicomputer system.
For procedures which affects only processes inside an RC8000 or HC8000 computer the procedures
work as described in ref. 1. ().*nl**np*
For most procedures it has only been necessary to extend their
way of working. Procedures which usually involve process
functions will use process functions itself as the ultimate
master process.*nl2*
The interpretation of the format of an internal process
has been changed in case of a mirrorprocess such that all claims refers to the other computer
and all registers in the process description are undefined.
*sj*
*ld8*
List of new procedures:
master process jd 1<11+58
remove master process jd 1<11+59
List of modified procedures:
create internal process jd 1<11+56
start internal process jd 1<11+58
stop internal process jd 1<11+60
modify internal process jd 1<11+62
remove process jd 1<11+64
copy process jd 1<11+70
set backing storage claims jd 1<11+78
*ld16**rj*
*nl1*
In the basic version "set backing storage claims
has no effect.
*rj**nl*
*ld8*
*ps0*
PROCEDURE MASTER PROCESS*nl2*
*sj*
procedure master process, 58
master process (result);
w0 result (return)
w1
w2
w3
*nl**rj*
Makes the calling process the master process provided no master process
exist. This is a priviledged function and
requires that the calling process is a mode 0 process.
The master process cannot be stopped before it has been
removed as a master process by a call of remove master process.
*nl**sj*
result = 0 master process accepted
1 other master process exist
3 illegal operation; process is not a mode 0 process
PARAMETER ERROR: return address outside calling process.
PROCEDURE REMOVE MASTER PROCESS*nl2*
Procedure remove master process, 59
Remove master process (name address, result)
w0 result (return)
w1
w2
w3 name address (call)
name address: child process name (call and return)
*nl**rj*
The child process is removed as the master process. A message
is send to the master process telling that is has been removed
as the master process. The master process should then remove
all mirror processes.
*nl**sj*
result = 0 child process removed as the master
1 process not a child
6 name format illegal
*nl3*
*ps0*
PROCEDURE CREATE INTERNAL PROCESS IN OTHER COMPUTER*nl2*
Except for the interpretation of the parameters
this is equivalent to the standard RC800 procedure.*nl*
Procedure Create Internal Process, 56
*sj*
Create internal process (name address, parameter address,
result)
w0 result (return)
w1 parameter address (call)
w2
w3 name address (call)
name address: process name (call and return
parameter address: (call)
+ 0 first storage address other
+ 2 top storage address other
+ 4 buffer claim, area claim other
+ 6 internal claim other
+ 8 1<23+ master mirror process description address + mode
+ 10 max base (lower) other
+ 12 max base (upper) other
+ 14 standard base = catalog base (lower) other
+ 16 standard base = catalog base (upper) other
+ 18 buffer claim, area claim mirror
+ 20 internal claim, function mask mirror
*rj*
creates a description of a mirrorprocess to an internal
process in another computer with a given name. IN the other
computer a mirror process to the calling process is created
provided it does not allready exist. A description of
an internal process with the given name and parameters and
the calling process as a parent is created in the other
computer. If the first word of the name is zero,
the monitor generates a unique process name and stores it
in the name area given in the call.*nl2*
Base of the internal process name is set to the catalog
base of the calling process.*nl2*
The storage area must be within the storage area of the
storage area for the master process in the other computer.
The first and top storage addresses point to the first
storage word and the last storage word + 2 of the new
process.*nl2*
The buffer claim other and the area claim other
must be less then or equal to the claims of
the master process, which are decreased accordingly.*nl2*
The buffer claim mirror and area claim mirror must be
less than or equal to the claims of the calling process, which
are decreased accordingly. At present area claim is
without meaning.*nl2*
The internal claim must be less than the claim of
the calling process, which is decreased by the value
specified + 1 to include the new process itself. At
present without meaning.*nl2*
In the function mask a bit equal to one indicates that the
process can call privileged function with the corresponding
key. Consequently the mask bits equal to one must be
a subset to those defined for the calling process.*nl2*
In the RC8000 the mirror process is a child of the
calling process. There it is created in the state
internal in other computer. In the other computer
the new process is a child of the mirror process of
calling process. It is created in the state waiting for
start by parent, with stop count, interrupt address,
time quantum, and the run time equal to zero, while the
instruction counter is equal to the first storage
address. The interrupt mask is initialized to prevent
internal interruption on aritmetic overflow.
*nl2*
The start time of the process is set equal to the
current value of the 48-bit clock.
*sj*
result = 0 internal process created
1 storage area outside calling process;
claims exseeded; illegal protection
max base or standing base not contained
in corresponding base of calling process
2 catalogi-o error
3 name conflict
4 other computer malfunction
6 name format illegal
*rj**nl*
Note that the internal process is not given claims on
the backing store by create internal process.*nl2*
PARAMETER ERROR: name area or parameter area outside
calling process.
*nl*
*ef*
▶EOF◀