Unisys 2200 Series system architecture

The figure shows a high-level architecture of the OS 2200 system identifying major hardware and software components.

The details of the system architecture are covered in Unisys publication 3850 7802 Instruction Processor Programming Reference Manual.

Almost all computer manufacturers of the time delivered 36-bit systems with 6-bit characters including IBM, DEC, General Electric, and Sylvania.

[1] The 1108 provided a 9-bit character format in order to support ASCII and later the ISO 8-bit sets, but they were not extensively used until the 1980s again because of space constraints.

Base registers logically contain a virtual address that points to a word in a code or data bank (segment).

Arithmetic registers allow the full set of computational instructions including all floating point operations.

All registers are also visible in the address space, but the Exec portion is protected and a reference by non-privileged code will result in a fault interrupt.

Some of the variants are encoded directly in the instruction format (partial word references) and some are dependent on Processor State Register settings.

Many instructions also perform very complex functions such as one that implements a large part of the COBOL EDIT verb.

"Data" and "COMM" are two of the primary examples of software subsystems that live in a protection ring between that of a user application and the Exec.

One is the Return Control Stack which holds information about the calling structure including any security relevant privilege and state changes.

The most obvious difference is that OS 2200 only permits a single program per Run (Job, Session) to be executing at a time.

They contain things like the thread state save areas, file control blocks, and accounting information.

It is possible to create a shared subsystem which is generally readable, or even writable, by multiple programs, but it must be explicitly installed that way by a privileged system administrator.

Within their home subsystem, activities typically share common access rights to code and data banks.

Code banks in the home subsystem are usually read-only, or even execute-only if they contain no constant data, but all activities will have the right to execute them.

The operating system will attach its own banks to a subsystem to hold the file control tables.

Calls made to the OS are always via "gates," instructions that exist for that purpose (ER = Executive Request), or via interrupts.

This allows small banks, for example containing a message, to have only the virtual space reserved for it that it actually needs and provides a debugging check against bad pointers and indices.

The fields indicate whether read, write, or execute permission is granted to the instruction processor (3 bits).

The Special Access Permissions (SAP) applies only to activities executing within the owning subsystem (really only those with a matching key value).

The Exec sets a key value in the state of each activity which may be changed by gate and interrupt transitions.

None of the privileged registers contain any truly sensitive information, but allowing general read access could easily lead to undetected errors in user programs.

Since this is guaranteed to be correct as it was created by the OS when the user opened the file, many error checks can be eliminated from the path length to do I/O.

When the function code with its qualifier indicates immediate data, the displacement, base, i, and h fields combine to form a single 18-bit immediate value.

On a TS interrupt the OS takes one of several actions depending on the instruction sequence and activity priority.

Test & Set Queuing is typically used for synchronization within subsystems such as the database manager where activities from many programs may be executing.

These processors offload large portions of the I/O path length and recovery, and by fully isolating the main system from I/O faults, interrupts, bus errors, etc.

The OS takes very general calls from programs and generates command packets with real memory and device addresses which are then passed to the I/O processor.

Firmware in the I/O processor actually creates the device specific (e.g., SCSI) packets, sets up the DMA, issues the I/O, and services the interrupts.