THE STORE ACCESS CONTROL UNIT

of the Local Store or via the Exchange in the case of the Mass or Disc Stores. For a read request, data returned from the store is routed back to the requesting unit via SAC. In addition, SAC controls most of the V-store within the MU5 Processor and also detects the occurrence of CPR non-equivalenceR, access permission violations and parity failures.

The various actions required to implement these facilities are carried out by an asynchronous pipeline mechanism which attempts to minimise the service time for a single request while at the same time providing the maximum possible repetition rate [23]. The main registers and interconnecting highways wi thin this pipeline are shown in figure 6.9. When SAC receives a request from PROP, OBS or IBU, it waits, if necessary, un til it is in a position to accept the request, copies the address and relevant tag and control information into the Stage A address register SA, and sends an 'accept signal to the requesting unit. In the event of more than one request being present at the input, it makes a priority decision as to which to accept. Thus IBU Priority requests have high priority for acceptance, above PROP or OBS requests, whereas IBU Ordinary requests, although they are the most frequent, have low priority since otherwise they could, if a tight predicted loop were entered, saturate SAC with requests and hold up OBS requests from earlier instructions.

The block address in SA is presented to the associative Virtual Address Field of the CPRs (figure 6.11) which operates in the same way as the PROP and OBS Stores, and the signal from the line giving equivalence is copied into the SAC Line Register (SLR). SLR selects the corresponding line in the Real Address Field and the content of this line is copied into register RA. Meanwhile the line address bits, together with tag and control information, are copied from SA through SB to the Stage C address register SC, and a check is made for the occurrence of equivalence or multiple equivalence, as in the case of the Name Stores (section 6.1.1). If equivalence occurs, the concatenation logic takes the appropriate page and line digits (according to the page size) from RA and SC respectively and forms the real address. In the case of a Real Address descriptor access (section 5.1.3), the output from RA is ignored, and the whole of the address taken from SC, thus bypassing the CPR mechanism. In all cases the real address is routed to the Local Store or the Exchange via DA (in the case of an IBU request) or via DB or DC (in the case of an OBS or PROP request). If non-equivalence or multiple equivalence occur, an interrupt is generated, the failing address is preserved in NA, and the access is abandoned (section 6.4.2).

IBU OBS PROP

Data Out

to CPRs from CPRs Exchange to Local Store Address

Exchange Address

Local Store Address

Local

~ __ !""IL .... _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ... Store

D Dab

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ .... 1-Exchange Data

OBS Data to

L ^I;]

~-D-a-ta-I-n---~· ~ ~~cal

PROP Store

Figure 6.9 The SAC Pipeline

For requests to the Local Store, the address is copied into AL and the tag and control information into register Q1. The four Q registers form a queue for the tag and control information as it waits to be connected with the corresponding data being returned from the Local Store. Since SAC controls the Local Store (section 6.3) and only sends requests out to free stacks, the replies are always guaranteed to come back in the same order as the outgoing requests. Thus information copied into Q1 is automatically moved into the furthest available empty register in the que.ue and data returning from the Local Store is copied into the Local Store data register LD, together with the information in Q4, thereby emptying that register. Requests to Exchange are sent through AE, with their tag information in QE. Once set, QE remains busy until a response is received from Exchange, since Exchange requests occur infrequently compared with Local Store requests and .are not overlapped. Data returning from the Exchange is accepted when there is a sui table gap in the flow of data from the Local Store, and all replies to read requests are sent back to the appropriate unit together with a 'data available' pulse.

When a write request is accepted by SAC, the accompanying data is copied into register WA. For reasons of hardware economy, and because, under normal operating conditions, write requests only occur very infrequently (when an 'altered' line in the Name or Vector Stores is selected for replacement), data buffers are only provided at the input and output stages.

Thus registers WA and WB act as a small independent pipeline, with the data in WA being copied into WE when the latter is free.

6.4.1 The Current Page Registers

MU5 is nominally defined as a 32-bit computer, with each 32-bit word in the virtual store having an address of the form shown in figure- 6.10(a). The 4-bit Process Number allows up to sixteen currently active processes to co-exist, each with a 14-bit Segment Number allowing up to 16K segments of 64K 32-bit words. The actual size of quantity addressed at different pOints in the Processor varies between 1 bit and 128 bits, however, and the number of bits in the corresponding virtual address varies accordingly. Thus the mlnlmum instruction size is 16 bits and the Control Register addresses 16-bit words, while the Instruction Buffer Unit normally accesses 128-bi t words from store and sends addresses with correspondingly fewer bits to SAC. Similarly, names may be 32-bit or 64·bit quantities, but the Name Store always holds

6!~ bits per line and is addressed using 15 digits wi thin the Name Segment. The line number of the line in the Name Store giving equivalence with the virtual address presented to it forms, in a sense, a real address. This address is never communicated to software, or to other parts of the hardware, however, nor can such an address originate from outside the Name Store. In the case of a non-equivalence, the virtual address is sent to SAC, where the CPRs produce a corresponding Main Store real address to be sent, normally, to the Local Store, to access the required operand. In the event of a non-equivalence in the CPRs, software action is required either to move a block of data into the Local Store ~nd to set up a CPR to address it (using V-store operations) or simply to set up a CPR to point to a block of data already contained in the Local Store. In the former case the block of data must be moved into the Local Store via the Exchange, from the Mass or Fixed-head Disc Store using real addresses appropriate to each store. Thus real addresses referring to the Local, Mass and Fixed-head disc Stores must be communicated both between software and hardware and between Units connected to the Exchange. The real address format used in the CPRs is therefore defined by the Exchange addressing format (figure 6.10(b», which can refer to anyone of sixteen Units.

126

(a) Virtual Address Process Segment Block/Line

(b) Real Address

~ Ivi

(c) CPR Virtual Field P S X

(d) CPR Real Field

~ Ivi

~igure 6.10 Real and Virtual Address Formats

Within each Unit the address is three bytes long, with the most significant bit indicating whether the remaining 32 refer to real store or V-store. Thus 8 million 32-bit words of real store can be directly addressed within anyone Unit. The posi tioning of the real address digits in relation to the virtual address digits 1s arranged so that there is a one-to-one correspondence between the line number in a virtual block and the line number in the corresponding real page, and also so that for real address accesses the four most significant segment address bits form the Unit number. The corresponding address formats used in the CPRs are shown in figure 6. 10 (c) and (d) and figure 6. 11 shows the CPR overall diagram.

Line I

t

Decoder Virtual Address Field Real Address Field

Process S Unit Size ^C1J

(4) X I _{L (4) (4)} :§

(12x2) G R Address Access ^{("oj M} Segment

j

(16) (20) Perm

(4)

CN

V - Write Data Virtual Address In Real Address Out

F!gure 6.11 The Current Page Registers

The associa ti ve, virtual address field is made up of two major parts, the Process Number and Segment Number (PS) field and the X field. The PS field is constructed in the same way as the associative stores in PROP and OBS, while the X field requires two flip-flops per bit in order to implement the dynamically variable page size facility. This requires pages of different sizes to co-exist in the CPRs, and it is therefore necessary to store in the CPR associa ti ve field information about the position of the block/line boundary for each CPR in use. Bits in the X field which are less significant than this position are masked so as to give equivalence regardless of the interrogate information.

The real address field contains 4 bits for the Exchange Uni t number, 20 bits for the page address wi thin a Uni t , 4 size bits and 4 access permission bits. A 20-bit page address corresponds to the minimum page size of 16 words, and for larger pages up to twelve of the least significant bits of the field may be unused. In addition each CPR has a bit in each of four Status Registers. These are the Altered Register (AL), the CPR Used Register (CU), the CPR Found Register (CF), and the Ignore Register (IG), all of which form part of the V-store.

The Altered Register corresponds to the Line Altered Registers in the PROP and OBS Name Stores, and is used in an analogous manner by the Operating System to determine whether or not to copy a block of information out of Local Store before it is overwritten. A digit in the Altered Register is set for a given CPR whenever a write access is made to the corresponding page. Digits in the CPR Used register, on the other hand, are set when any aecess is made to the corresponding page, and this register is used by the Operating System to help determine which CPR to overwrite following a CPRNEQ. Digits in the CPR Found Register are set whenever the corresponding CPR gives equivalence during a 'Search' operation (similar to the PROP and OBS Name Store search operations). This register is used by the Operating System, when releasing a Process or Segment, to determine which digits to set in the CPR Ignore Register. This register corresponds exactly to the Ignore Register in the OBS Virtual Address Store (section 6.2.1). The CPR Number Register (eN) is used to address the CPR for overwriting following the occurrence of a CPRNEQ, so that it is used by software in a manner analogous to the hardware use of the Line Pointer in the PROP Name Store. Overwriting a CPR automatically brings it into use since this action re-sets the corresponding Ignore digit.

It can be seen that there are many points of similarity between the Current Page Registers and the associative stores

in PROP and OBS. This similarity could have been extended further, by the use of hardware CPR loading, but this facility was consciously rejected at the design stage to allow full flexibility for software investigation of different organisations. The major responsibility for the management of the CPRs is therefore placed on software in MU5, with hardware providing sufficient facilities for .this to be possible, through the V-store mechanism, and to ensure a clean transition from User Process to System Process.

6.4.2 SAC Interrupts

SAC interrupts fall into two classes, those concerned with the inaccessibility of data (CPRNEQ, CPR Multiple Equivalence, Access Violation, etc.), and those concerned with erroneous data (parity faults). SAC is also indirectly involved with the occurrence of any interrupt, since there may be several instructions in the Secondary Pipeline at the point when PROP detects an interrupt, and anyone of them could cause a SAC interrupt to be generated. If PROP were to act on a non-SAC interrupt immediately, and obey the two fixed instructions causing entry to the appropriate interrupt procedure, a CPRNEQ for an outstanding request in the Secondary Pipeline could be erroneously treated as a System Error (section 6.5.1). PROP guards against this possibility by sending the dummy 'interrupt order' through the Processor (section 4.1.2) before obeying the fixed instructions.

The occurrence of a CPRNEQ causes an interrupt signal to be sent to PROP for all virtual address requests except IBU ordinary requests, for which CPRNEQ is dealt with separately by the IBU (section 4.2.8). A request generating a CPRNEQ also causes SAC to enter a 'Run-down' mode of operation and inhibi ts strobe pulses to register NA (figure 6.9). During normal operation of SAC, NA is strobed at the same time as

se,

so that following a CPRNEQ it contains the failing address, and may be examrned as a V-line by the CPRNEQ interrupt procedure. After entering its Run-down mode, SAC discards all normal requests until the request from· PROP corresponding to the first of the two fixed instructions causing entry to the CPRNEQ interrupt procedure, which restores SAC to normal operation. During Run-down, all requests ahead of the failing address are processed normally, and the Run-down condition is then signalled to OBS, so that the Queue can also be set into a Run-down state (section 5.2.5).

CPR Mul tiple Equivalence is basically similar to multiple equivalence in any of the other associative stores in the Processor. It occurs when two or more associative lines give equivalence at once, but whereas this condition can only arise

in the IBU, PROP and OBS stores as a result of a hardware failure, it can also arise in the CPRs as a result of a software failure. An Access Violation occurs whenever the access type bits associated with a request do not correspond wi th the Access Permission bits read out from the CPRs with the real address. SAC records the occurrence of any Access Violation in an Access Violation V-line, the outputs from which cause an appropriate interrupt.

Parity checks are carried out by SAC on all data returning from the Local Store and the Exchange to ensure that it has correct parity (odd parity in each byte) and in the event of a parity failure being detected, returns zeros to the requesting unit and sets the appropriate digit in a SAC Parity V-line in order to cause an interrupt. Additional checks are made on the address and control information associated with requests coming from Exchange, and in the event of a parity failure in either of these fields, the appropriate digit is set in the SAC System Error V-line and the Exchange Request Parity V-line.