Burroughs MCP Architecture

The B5500 was a 48 bit machines with 6 bit characters and could have up to 32 kwords of core memory. It could contain one or two CPUs, with the second CPU only doing compute rather than I/O. The B5000 only supported drum storage but the B5500 brought a fast head-per-track disk. Each stored 48 or 96 Mbytes and in theory up to 20 could be attached.

A dedicated teletype console, called the SPO (supervisory printer/keyboard), allowed an operator to interact with the system.

A data controller allowed up to 15 terminals - initially teletypes - to be attached for use by time-sharing or other programs.

There was also the usual peripherals - magnetic tape drives. card punch, card reader and line printer.

B5000 System Diagram. Note this is for the B5000 so shows a drum instead of the disk used on the B5500. Source: The Descriptor at bitsavers.

As noted in the introductory, the original drum-based version of MCP was modified to use disks and called the Disk File MCP (DFMCP); another version used the data concentrator for terminal access and was called the DCMCP; finally there was the time-sharing variant of MCP was called the TSMCP.

The TSMCP allowed both batch and time-sharing jobs to be run simultaneously. The main way that time-sharing users communicate with the system is a job called CANDE, standing for Command and Edit. This managed communication with each data line, allowing users to log in, edit programs and run jobs.

Memory was divided into two sections ('the fence'); the MCP and CANDE run on one side, user programs run on the other. The TSMCP would schedule time-sharing jobs so they would receive regular short time-slices, while batch jobs would queue up until they had enough memory to run for longer time-slices.

The system had no assembler - it was programmed entirely in high level languages. Initially Algol and COBOL was supported, with BASIC and Fortran being added later. Compilers would generate machine code directly.

This lack of an assembler even extended to system software, with the entire operating system being written in an extended form or Algol called ESPOL that could do low level operations not defined in pure Algol. For example, you could access any position in memory via an array.

This also meant that the machine was never used 'bare' - programs would not run directly on the hardware, they would always be run under the MCP.

Machine operations were done with a push down stack, so to add two numbers you would push the numbers onto the stack and then execute an add, leaving the result on the top of the stack. This made writing a compiler much easier as expressions could be translated into stack operations without having to deal with temporary memory locations. This also enabled easy relocation of programs and support for recursion.

Larger areas of memory, such as programs or arrays, were arranged into segments that could be swapped in and out of memory, allowing programs or data sets larger than core to be handled. Each compiler organised how it broke down programs into segments, which did mean there was no facility to link together code from multiple languages.

Segments were tagged as either data or code, so it was impossible for user programs to modify its own code.

You may have noticed while installing the system there was no need for a system generation phase where you tell the OS what hardware it can access. Instead, the MCP senses what hardware is connected, and can cope with peripherals, memory and even the second CPU being temporarily offline without restarting.

Files had a two part name separated by a /, such as HELLO/GUEST. The second part indicated the grouping of a set of files, in this case the time-sharing user GUEST. This is not a directory, however: you could call a file HELLO/XYZ without having to create XYZ first.

Magnetic tape files are device independent: if a job wants to read from a certain tape file, it just needs to call for the tape file name. MCP senses what tapes are mounted where and will direct the read to the correct device.

See the documents on bitsavers, especially the Time-sharing System User's Guide and The Descriptor.

I welcome any questions or comments, and also especially any corrections if I have got something wrong. Please email me at rupert@timereshared.com and I will add it here and update the main text.