6 Store Organisation
6.2 THE OBS STORE
The 'Operand Buffer System buffers three kinds of operand, vectors, names and literals. The vector and name parts require both Virtual Address and Value Fields, while the literal part requires only a Value Field to provide temporary storage for the literal operands of functions in transit through the OBS Queue (section 5.2). Thus the Virtual Address Store contains 32 associa ti vely addressed registers (figure 6.4). Of these, 24 are dedicated to name entries, and are 33 bits in length (4 Process Number bits, 14 Segment bits and ~5 bits addressing a 64-bit word), while the remaining eight are dedicated to vec tor en tr ies , and are 32 bi ts in leng th (4 Process Number bits, 14 Segment bits and 14 bits addressing a 128-bit word).
Address to SAC
Virtual
Address I
1----.
A
W I
LI--_ _ _ -IG P
Literal
Queue/Bypass
Tag Decode
Buffer Line Selection
Name Store Vector Store
Literal Store
F L L A
from
~---''---Dopor
SAC
Figure 6.4 The OBS Store
In addition, each line in the Virtual Address Store has a corresponding bit in each of two Status Registers, the 'Write Line Pointer' (WLP) and the 'Ignore Register' (IG). The Write Line Pointer normally has two bits set, one pointing to the next free line to be used in the event of a vector non-equivalence and one pointing to the next line to be used in the event of a name non-equivalence. The Ignore Register corresponds to the Line in Use Register in the PROP Name Store, except that the meaning of the digits is inverted. A bit set in the Ignore Register causes any equivalence occurring in the corresponding line in the Virtual Address Store to be ignored.
The Operand Store contains 24 lines for holding 64-bi t words, eight lines for holding 64-bit literals and nominally eight lines for holding 128-bi t words, although these are actually implemented as 16 lines each holding a 64-bit word.
Corresponding to each line in the vector and name fields is a digit in each of two further Status Registers, the 'Full' Register (FL) and the 'Line Altered' Register (LA). The Full Register indicates whether the contents of a name or vector line in the Operand Store are available. When the Full bit of a line accessed by the Output Process (section 5.2.3) is not set, then either it is waiting to be filled by the return of a store word requested from SAC, as a result of a
non-equivalence in the Virtual Address Store, or to be updated from Dop by an outstanding store order. The Line Altered Register is exactly equivalent to the Line Altered Register in the PROP Name Store. If the Altered bit of a line is set, then its contents have been altered by the action of a store order.
6.2.1 Normal Operation
In the PROP Name Store the address and value fields constitute adjacent stages of the pipeline and the action in the event of non-equivalence is to inhibit the normal operation of the pipeline until the Name Store has been updated. In OBS the address and value fields are separated by the Queue, and the basic aim of the system is to stream requests out to SAC while queuing up functions awaiting the return of the corresponding operands. The normal operation of the OBS Store is therefore different from that of the PROP Name Store. When an address is copied into IA for association in the Virtual Address Store, it l.s also written} at the same time, into a free line in each of the name and vector areas, as selected by bits in the Write Lj.ne Pointer. The outputs of the associative registers are combined with the corresponding bits in the Ignore Register and copied into the OBS Line Register (OLR), so that the latter will only contain a 1 if equivalence occurred between the interrogate address and a line already in use. The position of this bit in OLR is encoded into a Tag (section 5.2.1) and copied into the Queue or Bypass Register according to the type of function. In the output stage of OBS this Tag is used to access the Operand Store.
In the case of non-equivalence, no digit will be set in OLR, but the only action now required to create a new entry in Virtual Address Store is tpe re-setting of the appropriate digit in the Ignore register. In this case the Tag is supplied by the Buffer Line Selection Process (section 6.2.2), which must then create a new free line so that the normal action of association/writing can be carried out on the next address.
6.2.2 The Buffer Line Selection Process
The function of the Buffer Line Selection Process is to ensure the availability of a free line in both the name and vector parts of the Virtual Address and Operand Stores prior to each cycle of the Input Process, and to update the Local Store when necessary. In order to carry out this function, it uses the Tag system to access and manipulate the information contained in the Status Registers associated with the buffer stores. In addition, before freeing a line for re-use, it checks that the line is not currently referenCed by a function in the Queue or Bypass Line. This 'Referenced' Status is obtained by comparing
the Tag for the line to be cleared with the contents of the Tag Queue and Bypass Tag Buffer.
A Buffer Line Selection Process cycle is initiated whenever an Input Process cycle is started, the latter indicating whether a name, vector or literal cycle is required. The line freeing sequence uses three counters, one each for names, vectors and literals, to determine the line to be freed, so that the replacement algorithm is cyclic in each case. In the case of a literal cycle the new line will always be needed, while in the case of a name or" vector cycle the delay incurred in the event of a non-equivalence is minimised by overlapping the two activities. In the case of equivalence, no new line is needed and the Buffer Line Selection Process cycle is abandoned. If non-equivalence occurs, the Input Process re-sets the Ignore bit of the name or vector line corresponding to the bit in WLP, and the corresponding Tag is written into the Queue or Bypass Line and sent to SAC with the store request. The new line to be freed is then selected by incrementing the appropriate counter. Provided that the 'Full' and 'Referenced' signals indicate that the line is not waiting to be filled from SAC or Dop, and that it is not currently in use by a function in OBS, then it can be freed. Otherwise the selected counter is re-incremented until an available line is located. The position of this line is then set in WLP, and the corresponding Ignore bit set. If the selec ted line is not Al tered, then the line may be freed .. immedia tely by clearing the Full bit, whereas if it is Altered, its contents must first be sent back to store via SAC.
6.2.3 The Store Request Process
The Store Request Process organises data transfers between OBS and SAC, making requests to SAC on behalf of the Input Process (section 5.2.1), the Buffer Line Selection Process (section 6.2.2) and the Organisational Facilities (sections 5.2.7 and 6.2.4). The Input Process makes a request for a transfer from Local Store whenever a name or vector operand is required, but no action is taken by the Store Request Process until the resul t of the association of the input address is known. If non-equivalence is obtained, a store request is made to SAC accompanied by the Tag generated by the Buffer Line Selection Process. The Tag is carried through SAC and returned to OBS with the required store word, and is then used by the Output Process to select the appropriate line in the Operand Store when writing in the store word. The data returning from SAC may be a 64- bi t word or 128-bi tWOI'd, but as in the case of the SAC IBU interface (section 4.1.1), the data highway is 64 bi ts wide, and a 128-bi t word is returned as two successive 64-bit words. If equivalence is obtained; a request is still
made to SAC, but a control digit accompanying the request indicates to SAC that the request is a 'CHECK ONLY' request and no store access is required (section 5.2.1).
6.2.4 Buffer Store Organisational Facilities
The Buffer Store organisation facilities in OBS are similar to the organisational facilities in the PROP Name Store (section 6. 1 .4) and are similarly controlled by the use of V-lines.
Thus writing to one of the OBS V-lines causes the Ignore, Full and Altered bits to be cleared, sffectively destroying all the information contained in the stores, while writing to another V-line can initiate Clear or Purge actions. The Clear facility involves scanning through the Vector and Name lines of the store, and updating the Local Store whenever a line is found to have been altered. The Altered bit is then cleared, but the line remains otherwise unaffected. The Purge facility is similar to Clear, but in addition, the Ignore bit of each li~e
is set so that the store is left in an empty state. The Searen facility is used in the same way as the PROP Name Store Search to check that a CPR which is about to be overwri tten is not required by an entry in the Buffer Store. The resul t is combined with the result from the PROP Name Store Search so that the Test Digit indicates whether or not references to the block address exist in either store.
6.2.5 Interactions between the PROP and OBS Stores
The interactions which occur between the PROP and .OBS Stores as a result of name accesses have already been described.
Additional interactions occur, however, if
a
descriptor access is made into the Name Segment (Name Segment Equivalence). The checking of name addresses in the PROP Name Store normally occurs for all functions as part of the PROP pipeline actions.A name address arising from a descriptor access is generated at a later stage in toe pipeline than the PROP Name Store, however, although earlier than the OBS Name Store. Thus in the case of Name Segment Equivalence (NSE) occurring, the aBS Name Store can be checked normally, whereas special action must be taken to check the PROP Name Store. This is one of the most difficult problems arising in MU5 from the use of the naming concept and a pipeline structure in its design. The ad hoc solution adopted is far from ideal and arises partly from pin limitation problems around platter boundaries.
The occurrence of a Name Segment Equivalence is detected by Dr, which does not send its normal accept signal to PROP, but instead signals that an address check with the PROP Name Store may be required. The order is passed on to aBS in the normal way, together with an NSE control digit (figure 6.5). This
digit causes a hold-up in OBS and also causes OBS to treat the access as a name rather than a vector. The association of the address takes place in OBS, and if non-equivalence is found, an access must be made to the Local Store. Before this can occur, however, the PROP Name Store must be checked. OBS therefore makes a special request to SAC, since no direct route exists to PROP, with a control digit set to indicate that the request should be sent to the PROP Name Store. If the PROP Name Store contains the address, the word is returned to SAC, its Use digit is set to zero and a proceed signal is sent to OBS. If the PROP Name Store does not contain the address, the proceed signal is sent immediately.
NSE Request Enters OBS
Yes
Send Virtual Address via SAC to PROP
No Send 'OBS =' to PROP
Yes
Release NSE Hold-up
Figure 6.5 Name Segment Equivalence Actions
When OBS receives the proceed signal it clears the Ignore bit of the free line in the name field of the Virtual Address store, makes the normal request to SAC for the required store word, and clears the NSE hold-up. At the same time, if the
operand was found in the PROP Name Store, PROP abandons the orders in its pipeline and re-executes them all by forcing a control transfer to the order following that which found Name Segment Equivalence. This is essential since the descriptor access could be writing to the operand concerned, and this operand could also be required by the order in Stage 4 of the PROP pipeline at the time when the Name Segment Equivalence occurred. In this case an out-of-date value would have been obtained from the PROP Name Store. If OBS equivalence occurs, then no check in PROP is required. This case is signalled to PROP and the NSE hold-up is cleared immediately.