Computer Architecture Simulation & Visualisation

MU5

The files for version 4 can be downloaded from MU5_V4.1.zip.

Instructions on how to use HASE models can be found at Downloading, Installing and Using HASE.

Overview

Figure 1. The MU5 simulation model loaded into HASE

Figure 2. The MU5 simulation model during animation

MU5 Design Considerations

1. Generation of efficient code by compilers must be easy.
2. Programs must be compact.
3. The instruction set must allow a pipeline organisation of the processor leading to a fast execution rate.
4. Information on the nature of operands should be available to allow optimal buffering of operands.

1. Each routine has local working space consisting of named variables of integer (fixed-point) and real (floating-point) types, and structured data sets (arrays, for example) which are also named.
2. A routine may refer to non-local names either of an enclosing routine or in a workspace common to all routines.
3. Statements involve an arbitrary number of operands which may be real names, array elements, function calls or constants.

The MU5 instruction set

The instruction format chosen for MU5 represents a merger of single address and stacking machine concepts. All the arithmetic and logical operations involve the use of an accumulator and an operand specified in the instruction, but there is a variant of the load order (*=) which causes the accumulator to be stacked before being re-loaded. In addition, there is an address form (STACK) which unstacks the last stacked quantity. Thus the expression

The function ∅ is reverse divide (i.e. ACC = STACK/ACC); if the operand to the left of an operator is stacked, it subsequently appears as the right hand side of a machine function (as the dividend in this case). Thus, for the non-commutative operations - and /, the corresponding reverse operations have to be provided. In pure stacking machines, all subtractions and divisions are implicitly reverse operations.

The instruction set is summarised in Figure 3. There are two basic formats, one for computational functions and one for organisational functions (control transfers, base register manipulations, etc.). They are distinguished by the type of function bits and use four and six bits respectively to specify the function. The remaining nine or seven bits specify the primary operand. The k field indicates the kind of operand, and determines how the n field is interpreted. Where the k field indicates the Extended Operand Specification, the instruction is extended by an additional 16 bits in the case of a name, or by 16, 32, or 64 bits in the case of a literal.

Figure 3. The MU5 instruction set

Scalar variables can be of size 32 bits and 64 bits. They are accessed from a 32-line Name Store using an address formed by adding the name to the base register specified in the instruction (implicitly the Name Base in 16-bit instructions). The Name Store has two parts, 32 associatively accessed address registers and 32 64-bit value registers, so although a name + base address can point to a 32-bit variable, the base registers themselves can only point to 64-bit quantities. Thus the least significant bit of each of the base registers is set to zero and the name of a 64-bit variable is shifted left one place before being used to form an address.

Access to array elements is achieved through a descriptor mechanism. When a data structure element is specified by the k field, the corresponding primary operand is a 64-bit descriptor. This descriptor is sent to a D-unit within the processor, together with the contents of the B register if the k field specifies modification. The D-unit interprets the descriptor and makes a secondary store access for the element. This detachment of secondary addresses from instructions, and the use of names within instructions, allows the full 30-bit virtual address space available to a process to be referenced by 16-bit instructions.

There are two main types of descriptor:

String descriptors describe strings of bytes. The length field specifies the number of bytes, and the origin specifies the byte address of the first byte. Strings are normally used in conjunction with string processing orders (which may be two-address operations involving the use of two descriptors). These orders provide facilities for the manipulations of data records in languages such as COBOL, PL/1 and Algol 68 (move, compare, logically combine, etc.).

The size of the elements in a vector is specified within the type bits (Tv) and may be between 1 and 64 bits. If the operand access is modified, the modifier must be greater than or equal to zero and less than the bound. This check is carried out automatically by hardware with virtually no time penalty, and removes the need for the costly software bound check which is often required, particularly during program development.

The Simulation Model

The Instruction Set

Figure 4 shows the instruction set used in the model.. The additional Type of Instruction (T) character is included in instruction registers, and in packets containing instructions, to represent the extra function bits that were used in the hardware of MU5 to control the execution of instructions. Details are given below in the Primary Operand Unit section.

Figure 4. The HASE MU5 instruction set

The B functions correspond exactly to those implemented in MU5. COMP (compare) sets the two test bits T1 (= 0 / ≠ 0) and T2 (≥ 0 / < 0) according to the result of B - operand; B itself remains unaltered. In the real MU5, a third test bit (T0) was set to 1 if the comparison produced an overflow; in the model, an arithmetic overflow would be caught by the underlying runtime system, so T0 is not implemented. CINC (compare & increment) acts similarly but increments B after the comparison. CINC was intended for use with a subsequent conditional branch instruction in the implementation of for loops.

The ACC (Accumulator) functions are implemented in the model in exactly the same way as the corresponding B functions, i.e. as 32-bit integer operations, rather than as floating-point operations. The reason for this is explained below in the Address Space section.

The STS functions (SLGC, SMVB, SCMP, BLGC, BMVB, BMVE, SMVF, BSCN and BCMP) perform string processing operations. They were designed for use in record processing applications written in languages such as COBOL, PL/1 and Algol68. Their operation is explained in the description of the actions that take place during execution of the String Processing Program (Program 3) in the model,

The Address Space

The translation of virtual to real addresses in MU5 used a more complex paging mechanism than that used in Atlas (the first virtual memory computer). In the intervening years, main memory sizes had expanded enormously, requiring the use of many more paging registers. However, the nature of associative technology made this infeasible, so in most large computers with virtual memory, only a subset of the full virtual-to-real mapping table is held in hardware, as Current Page Registers (CPRs). CPRs differ from PARs in that they require a Real Address Field as well as an associative Virtual Address Field. Using CPRs means that on many occasions when a page fault occurs, the operating system just needs to update a Current Page Register without the need for any transfer of memory contents between the main store and the backing store.

MU5 had 32 CPRs, implemented in such a way that the page size could be varied. For user programs the page size was 256 32-bit words, meaning that the page table for any one segment (of 65536 words) could itself be contained in a single page. For system programs, the page size was equal to the segment size. In the HASE model of MU5, the page size is 256 words and there are just four CPRs. At the start of a simulation the CPRs all have their Valid bits set to 0, so the first request for an instruction, integer variable or character causes a page fault. In the real MU5 a page fault would have caused an interupt and the operating system would have organised the updating of a CPR and the transfer, if necessary, of the required page from the Disc or Mass Store to the Local Store via the Exchange (c.f. [15]). The model simply includes the Disc Store, containing the three programs and connected directly to the Local Store. The allocation of CPRs and blocks in the Local Store is built into the Hase++ code of the CPRs and Disc Store. The occurence of a page fault is indicated by the Store Access Control Unit entering its Held state.

The Primary Operand Unit

The PROP entity models the clocking system used to progress instructions through the pipeline. As in the real PROP, instructions are moved through the pipeline in a series of beats, with each beat being generated when an instruction leaves PROP or is completed by PROP itself (including the (non-)execution of instructions marked Invalid (I)). Each beat propagates through the pipeline from the Execute stage back to the Decode stage, and thence to the IBU, with a 1-unit HASE time delay between stages, representing the 10 ns stagger between stages in the real PROP (this stagger was necessary because of the nature of the ECL technology used to implement MU5). Although the timing between PROP stages is fixed, the actual generation of beats is asynchronous in the model, as it was in MU5; there is no central clock.

The function registers in the real MU5 had extra function bits associated with them, one of which indicated whether or not the instruction was valid. Other bits indicated a variety of different conditions. These bits are represented in the HASE model by an additional (character) Type field. This Type field is used to represent the various types of instruction and address packets used throughout the model, as shown in Table 1.

The influence of these Types on the various actions that occur in the processor as different instructions are executed is explained below with reference to the execution of the demonstration programs pre-loaded into the model.

The Instruction Buffer Unit

The first action that occurs at the start of a simulation is that PROP sends the address in CO (the program counter, always called the Control Register in Manchester computers) to the Store Request System. This address is loaded into the Advance Control register (AC) and forwarded to the Store Access Control Unit (SAC), marked as a Priority (P) request. The SRS then increments AC twice (instructions are fetched in pairs), each time testing the new address against the Jump-From field of the Jump Trace, and sends a second request to SAC marked as an Ordinary (O) request. The IBU maintains an Outstanding request counter and continues to send Ordinary requests to SAC whilst the number of outstanding requests is less than or equal to the number of empty buffers in the instruction return path in the Data Flow section (there are 8 32-bit buffers in the model). The Outstanding counter is decremented whenever the second instruction of a pair is sent to PROP, allowing further instructions to be pre-fetched.

If a new value in AC matches an entry in the jump-from field of the Jump Trace, the address read out from the jump-to field is substituted for the matching address and pre-fetching of instructions is restarted from the jump-to address. Whenever the SRS sends a request to SAC, information about the request is loaded into an Unpack Record in the Data Flow section. This information is used by the Data Flow section to unpack the two 32-bit instructions returned from SAC - depending on the jump-from and jump-two addresses, either or both of these instructions may be required. One of the fields in this entry is a sequence bit. If the sequence bit is set for a branch instruction being sent to PROP, its Type field is set to S. This indicates to PROP that the instruction is being followed by instructions at the jump-to address, rather than those in normal sequence. Simulation experiments undertaken during the design of MU5 showed that this system, using 8 lines in the Jump Trace, would correctly predict around 75% of branches.

The Data Flow section receives instructions in pairs from SAC, unpacks them according to the entry in the appropriate entry in the Unpack Record and enters them into the instruction buffers. These are implemented in the model as a drop-down stack, i.e. an instruction is taken off the bottom of the stack whenever PROP requests one and each new instruction is entered into the lowest free position in the stack.

The Secondary Operand Unit

Dr actually contains two descriptor registers, DR and XDR; XDR is used by string processing orders, as described below in the String Processing Program section. In the model, each 64-bit descriptor is held as two successive 32-bit integers in memory, the most significant word containing the Type, Size and Bound/Length fields and the least significant word the Origin. In the Dr registers, the more significant half is displayed in a more readable, disaggregated form. Thus DR_TSB contains three fields, the descriptor Type, the operand Size and the Bound (or length in the case of a Type 1 descriptor). The demonstration Program 1 in the model involves two descriptors, both of Type 1, Size 3 (i.e. 2³ bits, = 1 byte, mandatory with Type 1 descriptors) and a Length of 10. In memory these values appear as 1476395018.

In the Scalar Product program (Program 2) in the model, the descriptors are Type 0, Vector descriptors. The Dr Unit adds the modifier to the Origin to form the address of the required element and performs a bound check by subtracting the modifier from the Bound. In the real MU5, hardware space constraints meant that the adder used to form the address was also used as the subtractor. This was less than ideal, so the model assumes that there is a separate subtractor. If the Modifier exceeded the Bound in MU5, an interrupt was generated; in the model, the simulation is stopped and a report displayed in the Output pane.

The address created by Dr is sent to OBS, which, like the Name Store in PROP, is invisible to the programmer and exists only to improve the instruction execution rate. OBS makes the necessary store request and sends the 64-bit word it receives from SAC to Dop, which contains masking and shifting circuitry to select the array element from the appropriate position in the word. It does this using the Dop Bits, generated by Dr at the same time as the address, and carried through OBS with the instruction. The Dop Bits identify the Most Significant Byte Address (MSBA), the Most Significant bit Address (MSbA) and the Least Significant Byte Address (LSBA). These bits allow any 1, 4, 8, 16 or 32-bit element, or the whole word, to be selected from the 64-bit word sent to Dop.

In the model, OBS is made up of three entities that correspond closely to the sub-units of OBS in MU5 itself. These are the Input Process, the Queue and the Output Process. The Input Process contains the associatively accessed Virtual Address field of the operand buffers, 8 lines for named 64-bit variable words and 8 lines for 64-bit array element words. (In MU5 itself there were 24 lines for 64-bit named variable words and 8 addressable lines for 128-bit array element words, though these were implemented in hardware as 16 lines x 64-bits.) If the address field of an incoming instruction finds a match in one of these lines, the line number is encoded as a Tag and carried through the OBS Queue with the instruction. If there is no match, a new line is allocated and its Tag is carried through SAC, the CPRs and the Local Store, so that when the store word arrives at the OBS Output Process, the Output Process can write the value into the appropriate line in the Value Field and can set the Full bit in that line. When an instruction is at the Head of the Queue, its Tag is used to access the appropriate line in the Value Field.

The Queue has space for up to 8 instructions and is controlled by two counters, the Head and Tail counters. Initially both are set to zero. When the first instruction arrives it is written into location 0 and the Tail counter is incremented. Subsequent instructions are written into successive locations, modulo 8, unless the Tail counter becomes equal to the Head counter, in which case the Queue is full and the Input Process is held up. The Output Process continually checks for a Queue Ready signal, which is set when there is a valid instruction at the Head of the Queue and for which the corresponding Full bit is set. When the Queue Ready signal is true, the Output Process copies the instruction from the Head of the Queue, reads its operand store word from the OBS Value Field and sends both to Dop. It then sets the Type field of that instruction in the Queue to Invalid.

The Local and Disc Stores

Demonstration Program 1

Variables used by B, Dr and PROP instructions are normally held in the PROP Name Store, while variables used by ACC instructions are normally held in the OBS Name Store. However, because Name Store lines hold 64-bit store words, a 32-bit variable used by a B instruction can sometimes be part of the same 64-bit store word as an adjacent 32-bit variable used by an ACC instruction, and because the Name Store protocol is copy-back rather than write-through, variables can sometimes be in the "wrong" Name store. To avoid "sloshing", i.e. variables being transferred back and forth between Name Stores, a variable is only moved between Name Stores when it is the target of a write instruction. The program shows what happens in the Name Stores:

• as the PROP and OBS Name Stores fill up
• when a line currently in use but unaltered is re-allocated
• when a line currently in use and altered is re-allocated
• when a read access has to wait for a write order to complete
• when two write orders occur in close succession
• when an ACC instruction reads a variable in the PROP Name Store
• when an ACC instruction writes to a variable in the PROP Name Store
• when a B instruction reads a variable in the OBS Name Store
• when a B instruction writes to a variable in the OBS Name Store

Org NBld lit Z 16

Org SFNBpl lit Z 22

B LD V32 NB 0

A hold-up is set (in the PROP entity) such that the Decode, Add, Associate and Read stages of the pipeline enter the Held state until the NSNE actions have been completed. The failing address is carried through the PROP pipeline with the instruction marked as an N Type in the model. When this instruction reaches the Execute stage it is sent to the Descriptor Addressing Unit and thence to OBS. The OBS Name Store is meant to store values being used as variables in Accumulator instructions. However, names can sometimes be in the "wrong" Name Store, e.g. because a 32-bit name being used in a B instruction and a 32-bit name being used by an Accumulator instruction can be in the same 64-bit store word, so a check must always be made in the OBS Name Store. OBS sets a variable in PROP (not displayed in the model) to indicate the source of the required store word (OBS or the Store Access Control Unit (SAC)). Since this is a B instruction, and since the OBS Name Store is empty at this point, the required store word will come from SAC, so OBS sends the address to SAC, which accesses the CPRs to translate the virtual address to a real address, and this is sent to the Local Store.

Once PROP know that the required store word will come from SAC, it selects a Name Store line to contain the required virtual address and 64-bit store word using the Line Pointer (LP) register. LP contains one bit per line, with the first initially set to 1 and the rest to 0, i.e. it points to the first of the 8 lines (line 0). After each NSNE the single bit in LP is shifted one place, modulo 8, to select the line to be used at the next NSNE.

The value read from the Local Store is returned to SAC and thence to PROP, which updates its Name Store Address Field and Value Field (with values 528 and 529 in this case), releases the hold-up and allows the instruction to proceed along the pipeline, marked as a V Type. The Assemble stage selects the m.s. half of the 64-bit word from the Value Field and when the instruction reaches the Execute stage, it is sent to the Central Highway and thence to the B-arithmetic Unit which loads the value (528) into the B register.

B ADD V32 NB 1

B MUL V32 NB 2

B ST V32 NB 3

B SUB V32 NB 4

B DIV V32 NB 6

B XOR V32 NB 8

B OR V32 NB 10

B SHL lit Z 3

B AND V32 NB 12

B RDIV V32 NB 18

B RSUB V32 NB 17

B ST V32 NB 11

B LD V32 NB 10

B ADD V32 NB 20

B ST V32 NB 13

B SLD V32 NB 9

Once the NSNE actions are complete, BW is set to point to this line and the instruction proceeds to the B-Arithmetic unit, without incrementing CO. It returns the value of B to PROP and Name Store line 2 is overwritten with 0,1086 (stacked operands are all 64-bit). The values returned from the Local Store as a result of the NSNE are thus not used, but the NSNE actions have to be completed in order to ensure that when the operand at this virtual address is eventually written back the Local Store, it will not cause a page fault (as it could in the real MU5, though not in this model). The second phase proceeds through the pipeline as if it were a normal LD order. It finds 64-bit virtual address 12 in line 4 of the Name Store and loads B with 537.

The second phase of the instruction increments CO and also copies the new value of SF, carried through the pipeline in registers S3, S4 and S5, into S6 and sets S6 valid (S6 has two components, its value and a valid bit). If a branch occurs whilst a stacking instruction is in the pipeline, the value in SF will be incorrect and must be replaced by the value in S6. An organisational order that alters SF sets S6 invalid.

STS STACK V32 NB 11

The second phase increments RSF by 2 to create a new top-of-stack address (64-bit address 21). The resulting NSNE generates an access to the Local Store and the values (554/555) are loaded into line 3 of the Name Store. The 64-bit value field is then overwritten, with zero in the m.s. half and the 32-bit value being stacked in the l.s. half, the result being that the line contains 0,511.

Org NBSFpl lit Z -2

Org SFNBpl lit Z 20

ACC LD V32 NB 1

ACC ADD V32 NB 3

ACC MUL V32 NB 4

ACC ST V32 NB 0

ACC SUB V32 NB 6
ACC DIV V32 NB 8
ACC XOR V32 NB 11
ACC OR V32 NB 12
ACC SHL lit Z 0
ACC AND V32 NB 15
ACC RDIV V32 NB 16

ACC RSUB V32 NB 18

ACC ST V32 NB 15

ACC LD V32 NB 14

ACC ADD V32 NB 20

ACC ST V32 NB 13

ACC SLD V32 NB 9

The second phase proceeds through the pipeline as if it were a normal LD order. It finds 64-bit virtual address 24 in line O3 and loads ACC with 561.

B LD stack Z 0

Instructions destined for the B-Arith Unit (or PROP or Dr) pass through the Queue Bypass Line, rather than the Queue, allowing them to overtake ACC instructions. This was done in MU5 for two reasons, one concerned with the after-effects of a CPR NEQ (not implemented in this model) and the other with performance. The B-Arith Unit, PROP and Dr, situated earlier in the pipeline than the Accumulator Unit, are concerned with suppling operand addresses to OBS in order to keep the Accumulator Unit (which is executing the "useful" part of the program) busy, so it would be counter-productive to queue instructions destined for these units behind ACC instructions.

B ST V32 NB 10

Org NB_LD V32 Z 0

Org SFNB_PL lit Z 6

STS D_LD V64 NB 0

STS XD_LD V64 NB 1

STS MOD lit Z 5
STS XMOD lit Z 3

STS D_ST V64 NB 2
STS XD_ST V64 NB 3

STS D_SLD V64 NB 1

ACC STOP lit Z 0

Scalar Product Program (Program 2)

Figure 5. Scalar Product example

The first instruction of the scalar product loop (ACC SLD SB NB 0) increments SF and writes the current content of the Accumulator to the top-of-stack location. It then loads DR with the descriptor of the X vector (0-5-10, 524288), instructs the B-Arith unit to send the value in B to DR, forms the address of the i^th element of X and loads ACC with the corresponding value. The first time this instruction is executed, it causes a Vector Store non-equivalence in OBS, which writes the failing address into the Address Field and sends a request to SAC. When the store word arrives back from SAC it is written into the OBS Value Field and the Full bit is set for that line. During the second iteration of the loop, the address of the second element does not cause a non-equivalence because the store word received as a result of the first non-equivalence contains the first and second elements of the vector. Likewise, a non-equivalence occurs during the third iteration but not in the fourth, and so on. During the ninth iteration, the Vector Store is full, so the first entry is overwritten. At the same time as writing in the new address in this cycle, the Full bit is reset for this line in the Value Field, so that if the instruction emerges from the Queue before the store word is returned (as it does in this case), the instruction does not pick up the previous value.

The multiply instruction (ACC MUL SB NB 1) multiplies the element of vector X, loaded into ACC by the preceding instruction, by the corresponding element of the second vector (Y). Similar to the execution of the second phase of the SLD instruction, this instruction loads DR with the descriptor of Vector Y (0-5-10, 524328, and forms the required address by adding the modifier from B to the Origin address. Likewise a non-equivalence occurs in the OBS Vector Store in odd numbered iterations of the loop but not in even numbered iterations.

The Compare & INCrement instruction (B CINC lit Z 9) is executed as a two-part instruction in the B-Arith Unit. The first part subtracts the incoming operand (9 in this case) from B, and sets the test bits T1 and T2 accordingly, but without altering the value in B. The second part increments B by 1. The B CINC comes before the ACC ADD stack Z 0 instruction that adds the running total of products back into the Accumulator because the branch instruction that closes the loop (Org BRne lit Z -4) has to wait for the comparison result to be returned to PROP before it can be executed, i.e. the code has been re-ordered to optimize performance.

The first 10 times that the Branch-if-not-equal instruction (Org BRne lit Z -4) is executed, T1 is set to /= 0 so the Branch is taken. The first time this happens, the pipeline is cleared and the jump-from Control address (65544) and the jump-to Control address (65540) are both sent to the IBU to set up an entry in the Jump Trace. Prefetching is restarted from 65539 but when the AC register next gets to 65544, there is a match in the Jump Trace, so instead of fetching the next instruction from address 65545, the ACC SLD instruction and its successors are prefetched instead. When this happens, the BRne instruction is passed to PROP marked as Type S. When it reaches the Execution stage, and the Branch is taken again, the pipeline is not cleared, since this time the predicted (out-of-sequence) instructions are already in the pipeline. On the 10th execution of the BRne instruction, however, the Branch is not taken, so once again the pipeline is cleared and prefetching is restarted at Control address 65545.

On leaving the loop, the result of the scalar product operation is written to name 4 by the ACC ST V32 NB 4 instruction.

String Processing Program (Program 3)

The strings are held in Block 3 of the Local Store. Each word in this block contains 8 characters. Because the simulation code is written in Hase++ (a superset of C++), it is strongly type-checked. Thus in order to process these characters using the same simulated hardware as that used for integer values, characters are converted to their ASCII integer values and packed into a pair of 32-bit integer words whenever they are read out of memory and, correspondingly, returning integer words are unpacked during a write-to-store operation. Similarly in the Descriptor Operand Processing Unit (Dop), each character is manipulated as an integer value, so for visualisation purposes, an extra register FRc is used to show the integer values in register FR, converted to character format. The SSA_SSB register shown in the Project Inspector frame is also a character display register, corresponding to the actual register ssa_ssb used internally within the code.

There are two types of string processing instruction: byte-string and string-string. Executing each of them involves the execution of a number of cycles of different types: first cycle, load cycle, store cycle and compare cycle. Each instruction starts with a first cycle which transfers the operand specified by the instruction to the MASK_BYTE register in Dop. The MASK is used in the BLGC and SLGC (logic) instructions (not yet implemented in this model). BYTE is used as the source byte in a byte-string instruction and as a filler byte in some string-string instructions. A load cycle fetches a byte from the source string in a string-string order, while a store cycle writes a byte to the destination string. A compare cycle compares the source byte and destination byte (but does not write to the destination byte) and returns the result of the comparison (=, > or <) to Dr.

Table 4 lists the program instructions and their actions.

Bibliography

1. T. Kilburn, D. Morris, J.S. Rohl & F.H. Sumner, "A System Design Proposal"
   Information Processing 1968, Vol 2, pp 806-811, North Holland, 1969.

2. D. Aspinall, D.J. Kinniment and D.B.G. Edwards, "Associative Memories in Large Computer Systems"
   Information Processing 68, Vol 2, pp 796-800, North Holland, Amsterdam, 1969.

3. J.B. Gosling, "Review of High-speed Addition Techniques"
   IEE Proceedings, Vol 118, pp 29-35, 1971.

4. R.N. Ibbett, "The MU5 Instruction Pipeline"
   Computer Journal, Vol 15, pp 43-50, 1972.

5. J. Standeven, S. Lanyado, & D. B.G. Edwards, "The MU5 Secondary Operand Unit"
   IERE Conference Proceedings, Vol. 25, pp 429-440, 1972.

6. H.J. Kahn & J.W.R. May, "The Use of Logic Simulation in the Design of a Large Computer System"
   IERE Conference Proceedings. Vol. 25, pp. 19-30, 1972.

7. P.C. Capon, R.N. Ibbett & C.R.C.B Parker, "The Implementation of Record Processing in MU5"
   IEE Conference Proceedings, Vol.121, pp 226-235, 1974.

8. J.V. Woods & F.H. Sumner, "Operand Accessing in a Pipelined Computer System"
   IEE Conference Proceedings, Vol.121, pp 326-43, 1974.

9. F.H. Sumner, "MU5 - An Assessment of the Design"
   Information Processing 74 North-Holland, Amsterdam, pp 133-136, 1974.

10. N.A. Yannacopoulos, R.N. Ibbett & R.W. Holgate, "Performance Measurements of the MU5 Primary Instruction Pipeline"
    Information Processing 77, North Holland, Amsterdam, pp 471-476, 1977.

11. R.N. Ibbett & P.C. Capon, "The Development of the MU5 Computer System"
    Communications of the ACM, pp 13-24, 1978.

12. John K. Buckle, "The ICL 2900 Series"
    The Macmillan Press, London, 1978.

13. Derrick Morris & Roland N. Ibbett, "The MU5 Computer System"
    The Macmillan Press, London, 1979.

14. R.N. Ibbett, "The University of Manchester MU5 Project"
    IEEE Annals of the History of Computing, Vol. 21, No1, pp 24-33, 1999.

15. R.N. Ibbett "The University of Manchester MU5 Computer System"
    IEEE Engineering and Technology History Wiki

Return to Computer Architecture Simulation Models