Please note, this is archived content and is no longer being updated. Please update your bookmarks and links to point to this permanent URL: http://curation.cs.manchester.ac.uk/digital60/www.digital60.org/birth/manchestercomputers/museandatlas/interrupt.html.

Atlas Interrupts

The Atlas Interrupt Mechanism, illustrated with Paper Tape Input

The Atlas Computer

Atlas had a "one-level", or "virtual", store. It was organised in "pages" of 1024 24-bit words, where a 24-bit word could be an integer or 4 6-bit characters, and two successive words starting on an even address could be a 48-bit instruction or floating-point number. From the user's point of view, there was a virtual address space of 220 48-bit words. Any particular page of this space that had been referenced so far in a program run could exist anywhere in immediate access ("core") store, i.e. RAM, or drum store (and later disc), i.e. fast random-access magnetic store, or on magnetic tape, i.e. slow serial magnetic store. It could migrate around the different media as the program was obeyed, under the control of the Supervisor (i.e. the operating system), so long as each time it was actually being referenced it was physically somewhere in core store. (The unit of transfer to and from the magnetic stores was a page.)

Atlas had one 96-bit double-length floating-point accumulator, and 128 "B-lines" -- 24-bit integer accumulators used for integer arithmetic as well as the classical address modification. The order code was one-address with double-modification for accumulator orders, and two-address with single-modification for B-line orders. The address field was 24 bits, so it covered the full virtual address space.

Program Control Layers

There were three layers of program control, each with its own control register: Main Control (B127), Extracode Control (B126) and Interrupt Control (B125). Main Control was used by user programs and the higher level routines/subprograms of the Supervisor. Extracode Control was used for the key routines of the Supervisor plus the nearly 300 "Extracodes" on Atlas, i.e. function codes of the instruction set that were implemented by subroutines -- in contrast to the 100 or so codes implemented directly by hardware. Extracodes were available for example to provide trigonometric functions and character-handling operations directly in the order code, and to program the wide range of peripheral operations. Interrupt Control was used by a small set of fast routines that handled situations requiring immediate real-time attention, like peripheral operations and error situations.

The Stores

The Extracode and Interrupt routines were stored in a special ROM, the "Fixed" store, separate from the main core store RAM. In addition they had a special area of RAM store as working space, the "Auxiliary Store", and a set of the B-lines reserved. There was also a "V-store" consisting of a collection of bits and longer strings associated with e.g. peripheral equipment. The Fixed, Auxiliary and V-store stores had fixed addresses outside the virtual address space generally available to the user (i.e. negative addresses, read-only for the user). There was of course a comprehensive system of store lockout that ensured that no process (in particular no user process) could access store that it was not entitled to.

Configuration of the Manchester Atlas

Internal Store Peripheral Equipment (say)
RAM core store 32 pages 8 magnetic tape decks
ROM Fixed store 16 pages 4 paper tape readers
RAM Auxiliary Store 2 pages 4 paper tape punches
Magnetic drum store 192 pages 1 card reader
Virtual Store (approx.) 2,048 pages 1 card punch
Disc (1967) 32,000 pages 2 teleprinters
1 line printer

Pseudo-parallel Process Control

At any one time there could be any number of processes active in the system. There was only ever one interrupt active, and if so it would also be in control, i.e. actually running, using B125. There could be any number of Extracode processes (or routines) active, one actually in control (using B126) and the rest in a priority queue, suspended but ready to run when given the chance, or suspended but awaiting an event before they could continue. A process "in control" here means that the address in B126 refers to its current instruction, but it may not be actually being obeyed because Interrupt Control is running. Similarly there could be any number of prioritised Main processes, one in control of Main Control (B127), and any number suspended-and-ready or suspended-and-waiting. The one in control might be actually running, or waiting for Interrupt Control and/or Extracode control to finish before resuming.

Nothing (not even another interrupt) could interrupt Interrupt Control. Extracode Control could be interrupted by Interrupt Control, but not another Extracode Control. All Extracode processes active and able to run would be cleared before control was returned to Main Control. Main Control could of course be interrupted by either Interrupt or Extracode Control. A Main process could not be interrupted by another Main process directly, but it could happen indirectly, where an Interrupt routine had just fielded a flag signalling an event that a higher priority suspended Main process was waiting for.

Obviously the switching of control between processes was organised by the Supervisor (usually running in Interrupt or Extracode control). The key point is that, with the Control layering, and with special stores and dedicated control registers, switching between processes was kept to a time related to the urgency. It cost nothing to switch between layers, and therefore in particular it cost nothing to switch in and out of the Interrupt layer. The average instruction time at the level of Supervisor operations (mostly B-line instructions and using fast stores), was say between 1.5 and 2 microseconds. The switching time between Extracode routines was say around 60 µsecs. Switching between Main processes (certainly between user processes) required copying out accumulator and relevant B-lines, plus status information, into core store, and then restoring the corresponding information for the incoming process. This would cost of the order of say 1,200 µsecs.

Processing Interrupts

Each part of the machine that would require instantaneous attention would have an interrupt bit that it could set in the V-store. This included error situations and peripheral handling. In principle, at the beginning of each instruction, except under Interrupt Control, the hardware would poll the interrupt bits in a standard order (reflecting priority), and for the first one it found set (if any) it would pass control to the corresponding Interrupt routine. Once the routine was finished, it would recheck the interrupt bits. When there were no interrupt bits set it would check if there was an Extracode process in Control. If not, but there was a queue, it would invoke a (Interrupt or Extracode?) routine to give control to the highest priority Extracode process. If no Extracode process was in control or queued (a hardware check), but a Main process was in control, it would pass control to Main control. If no Main process was in control but there were processes suspended-and-ready, it would pass control to an extracode to bring in a new Main process.

The interrupt routines were kept very short, and arranged in a priority sequence that ensured that the required interrupt routine would always be obeyed before the next interrupt could occur from the same source, whatever the source.

Note that a drum or tape transfer to or from a page in core store was carried out "autonomously", i.e. there would be a hardware transfer operation of all 512 48-bit words which took place independent of the rest of the machine operation. (The core page would be locked to prevent access from any running process while the transfer was taking place.) Otherwise there would have needed to be an interrupt for each word every (around) 4 µsec (for drum) or 100 µsec (for tape), and the standard interrupt mechansim would certainly not have worked for the drum situation, as there would only have been time to obey two instructions before the next word was due.

Reading an Input File 'Offline'

So now we can see what happens with a paper tape input file. The file would be read in to the system at the convenience of the (human) operators, at some arbitrary time before the program(s) requiring it was actually executed. At the start of the tape (without going into detail) the Supervisor would have combined low level actions to read characters with high level actions to process the header information, e.g. to open a new file in the one-level store to accommodate the information, and to do the administration to remember what user it belongs to. It would then open a page in core store (which it hoped would remain there!) to take the first (in general the current) page of the file. Each particular paper tape reader also had its own (smaller) private buffer area in the Supervisor's working store. The completed input file would in general eventually be stored on a special Supervisor magnetic tape, the "Input Well".

Now when the next set of holes comes under the reader, the peripheral hardware will copy the 5 or 7 bits into its V-store buffer and set its V-store interrupt bit. At 300 chars/sec there is now about 3,300 µsec before the next character is due. Either immediately, or fairly quickly, its interrupt routine will be entered. The minimum action is to apply the tape 5/7-bit code to a look-up table to do any conversions required and check for control characters, e.g. the end of the file; for 7-hole tape there is also a parity check. (Atlas used a specific 64 character code for internal representation of characters, that was independent of the input/output media it might be associated with; in fact double the number of characters were catered for, using special "shift/case" codes to specify which of two sets of characters the following characters belonged to.) The interrupt routine will then copy the resulting 6-bit code to the next character position in the reader's private buffer. This will all take say a dozen instructions, say 20 µsec. However if the checks show that the private buffer is full, or the file is finished, it will call the appropriate Supervisor routine into the Extracode queue (if buffer full) or Main queue (if file finished), with appropriate priority. This will then carry out the longer procedure required to deal with these situations. In principle the private-buffer-full situation will be fairly quick if the file's current page still has room; otherwise it is probably a Main store routine that will be used to append the page to the input file, and set up the next page for the file. In general it would be expected that the system is ready to receive the next character when it is due to arrive (e.g. by making sure there is always space to receive the next character); if it still hasn't dealt with the preceding character, then the reader is stopped, and restarted when there is room to deal with it.

In this way the whole paper tape file is read, without the tape stopping (unless the machine is very busy), and with no effect on the running of the computer except for a small degradation in speed of say around 1%, i.e. 30 µsec per 3,300 µsec (basic 20 µs, plus periodic longer bursts to flush buffers, averaging 10 µs per character). A short hesitation might be discernable every 4096 characters, i.e. after a completed page of characters.

Note that e.g. card equipment and the line printer used longer V-store buffers than the paper tape, e.g. a row/column/line wide; so the time between successive flushes of the V-store buffer might be so long that the appropriate Interrupt routine might do little more than hand straight over to an Extracode routine.

Reading the Input File from a Running Program

When the file was fully read in, in general onto the Input Well magnetic tape, it would stay in the machine until such time as a program using it was started. When the program was started, the file would be logically attached to the program, i.e. given a stream number as directed by the JOB control file, and (the first page at least) moved to a more immediate level of store. The program handled the file as if it had a virtual input stream on-line. There was an appropriate extracode instruction to set (or reset) the current stream number and another to read the next character from the current stream. From the programmer's point of view, these were just the same as basic instructions, and had instantaneous effect. In practice, if there was no current extracode or interrupt routine in operation, it would take very few instructions to enter the Extracode routine and extract the next character from the current page of the stream, say 30 µsec. But of course it could take an indefinite time in real time, for example if there was other interrupt and extracode activity current, or if the next character started a new page in the file store and the new page was not yet in core store, or indeed if the current page had been thrown out of core store since the last read operation on it. And of course at any time the user's program could be suspended (and maybe all its program, data and I/O pages in use thrown out of core store) to give way to another Main process with higher priority that had been awaiting an event (e.g. a magnetic tape positioning request completed); this would have been given Main control as a result of the Interrupt/Extracode routines handling the event.

Note that this description has not been exhaustively researched. It is consistent with the paper "The Atlas Supervisor" by T. Kilburn, R.B. Payne and D.J. Howarth, written in 1961 (i.e. a year before the Atlas was operational), and my Atlas Programming Manual of 1965. Material where I am less sure of the accuracy is indicated by the italicised phrases "In principle" (applying to the end of the paragraph) or "say" (applying to the following quantity or phrase). -- Brian Napper


\