.
Nice explanation here of this one-off machine.
Quote:
The factor of 20 was to be achieved as follows:
Integrated circuits and interconnection techniques would give a basic computing speed of seven times Atlas.
A 250 ns cycle time store would be used (the Atlas core store had a 2μ cycle time).
The design would include fast operand registers and register to register arithmetic (though these would not be addressable registers of the kind used in the CDC 6600, for example), and multiple arithmetic units (though, again, these would be different from those used in the 6600, being dedicated units rather than general purpose ones).
An instruction set would be provided which would permit the generation of more efficient object code by the compilers. Particular attention was to be given to the techniques for computing the addresses of array elements and array bound checking would be provided as a hardware feature.
The efficiency of the Atlas supervisor was approximately 60%. The provision of special hardware and the information obtained from a detailed study of the Atlas system over the previous two years would permit this efficiency to be significantly increased.
Items (1) to (3) were expected to give a factor of about ten, indeed the time for the inner loop of a scalar product was expected to be 1 μs as compared with 12 μs on Atlas. Items (4) and (5) were expected give at least a further factor or two.
![Image](http://www.cs.manchester.ac.uk/media/eps/schoolofcomputerscience/about/mu5-proc.gif)
![Image](http://www.cs.manchester.ac.uk/media/eps/schoolofcomputerscience/about/mu5-room.jpg)
Quote:
There was never any real question of using a clock. Atlas had been asynchronous, for good reasons, so the new machine would be. In any case, it was going to be physically so big that it would not have been any use having a clock. Even in units of the system that ran semi-synchronously, using a series of asynchronously generated 'beats' that ran sequentially through several stages of the pipeline, parts of the logic ran sufficiently far behind the beat generation logic to create major problems in getting logical control signals back in time. Trying to stall the entire pipeline because of a data dependency, for example, would have been impossible. Furthermore, the time required to execute a floating-point addition was going to be data dependent, and limiting the speed of the machine to that of the slowest floating-point addition would have been unacceptable.
There's
an emulator project here.
"The University started thinking about a successor to Atlas in 1966, design started in earnest in 1968, commissioning began in the summer of 1971 and the machine became operational in 1973. The machine ran until 1982."
There's some kind of architectural simulator too, in Java, one of a collection:
http://www.icsa.inf.ed.ac.uk/research/g ... se/models/