Descriptors are an architectural feature of Burroughs Large Systems, including the current () Unisys Clearpath/MCP systems. Apart from being stack- and tag-based, a notable architectural feature of these systems is that they are descriptor-based. Descriptors are the means of having data that does not reside on the stack such as arrays and objects. Descriptors are also used for string data as in compilers and commercial applications, and for I/O.
Descriptors are integral to the automatic memory management system and virtual memory. Descriptors contain metadata about memory blocks including address, length, machine type (word or byte — for strings) and other metadata. Descriptors provide essential memory protection, security, safety, catching all attempts at out-of-bounds access and buffer overflow. Descriptors are a form of capability system.
History The development of the descriptor was Burroughs method of implementing memory management, allocation and deallocation, as well as virtual memory. In 1958, Robert S. Barton, then at Shell Research, suggested that main storage should be allocated automatically rather than having the programmer being concerned with overlays from secondary memory, in effect virtual memory. Virtual memory was originally developed for the Atlas project at the University of Manchester in the late 1950s.
By 1960, Barton had become lead architect on the Burroughs B5000 project. From 1959 to 1961, W.R. Lonergan was manager of the Burroughs Product Planning Group which included Barton, Donald Knuth as consultant, and Paul King. According to Lonergan, in May 1960, UCLA ran a two-week seminar ‘Using and Exploiting Giant Computers’ to which Paul King and two others were sent. Stan Gill gave a presentation on virtual memory in the Atlas I computer. Paul King took the ideas back to Burroughs and it was determined that virtual memory should be designed into the core of the B5000. Burroughs Corporation released the B5000 in 1964 as the first commercial computer with virtual memory.
In the mid-1960s, other vendors, including General Electric, IBM, RCA, and Scientific Data Systems, developed machines that supported virtual memory, with operating systems oriented towards time-sharing. IBM didn't support virtual memory in machines intended for general data processing until 1972. However, those other systems are not descriptor based and have added virtual memory above the basic processor architecture.
The descriptor was an essential part of the development of the B5000 with automatic memory management and virtual memory at Burroughs. The 1969 B6500 was a new design, but the descriptor was still a central feature. While the details have changed since 1969, the idea of the descriptor essentially remains the same up until the current Unisys Clearpath MCP (Libra) machines which are direct descendants of the B6500.
Details Descriptors describe storage areas, I/O requests and I/O results. They contain fields indicating, e.g. the type of descriptor, the address, the length, whether the data are present in storage. The details differ depending on the product line and the type of descriptor. The following text numbers the leftmost (most significant) bit as 0, in accordance with the Burroughs documentation.
Program and data descriptors have a bit called the "presence bit" or "p-bit"; it indicates whether the object referred to by the descriptor is currently in memory or in secondary storage. This bit is used to implements virtual memory.
When a descriptor is referenced, the hardware checks the p-bit. If it is 1, the data are present in memory at the location indicated in the address field. If the p-bit is 0, the data block is not present and an interrupt (p-bit interrupt) is raised and MCP code entered to make the block present. In this case, if the address field is 0, the data block has not been allocated (init p-bit) and the MCP searches for a free block the size of which is given in the length field.
The last p-bit scenario is when the p-bit is 0, indicating that the data are not in memory, but the address is non-zero, indicating that the data have been allocated and in this case the address represents a disk address in the virtual memory area on disk. In this case a p-bit interrupt is raised and it is noted as an "other" p-bit.
B5000, B5500 and B5700
The B5000 was the first descriptor-based computer. Every descriptor has a flag (bit 0) of 1. Data descriptors contain a 15-bit storage address and a 10-bit size, as do most I/O descriptors. Program descriptors and External Result descriptors have a 15-bit address but no size field.
B5x00 Program Descriptors Program descriptors are used to define program segments. Either an Operand Call or a Descriptor call that refers to a Program Descriptor will cause a subroutine call if the presence bit is 1. Otherwise, it will cause a presence interrupt. +B5x00 Program Descriptors 0 1 2 3 4 5 6 7 8-17 18-32 33-47 Flag I Presence I Mode A Address 1 1 0=not in memory1=in memory 1 0=word1=character 0=argument not required1=argument required
Data Descriptors Data Descriptors refer either to a block of data present in memory (P=1) or to a block of data that must be read into memory (P=0), Depending on the value of the Presence bit. Either an Operand Call or a Descriptor call that refers to a Data Descriptor will check the presence bit and the size field; if the presence bit is 0 then a presence interrupt will occur; if the size field is nonzero then the second word on the stack must be within range or an index interrupt will occur. +B5x00 Data Descriptors 0 1 2 3-7 8-17 18 19 20 21-32 33-47 Flag I Presence Size I C Address 1 0 0=not in memory1=in memoryReservedfor MCP Reservedfor MCP 0=Floating1=Integer Continuity bit - for controlling the type of interrupt caused by a program release operator0=Set the Program Release Interrupt - I/O areas not tanked or last I/O area1=Set the Continuity Interrupt - I/O areas are tankedReservedfor MCP
I/O Descriptors +B5x00 I/O Descriptors 0 1 2 3-7 8-17 18-32 33-47 Flag I AlternateExternal Unit Size DeviceDependent Address 1 1 0=write1=read
External Result Descriptors An External Result Descriptor contains the I/O Descriptor used to initiate the operation with some fields replaced. +B5x00 External Result Descriptors 0 1 2 3-7 8-25 26-32 33-47 Flag I AlternateExternal Unit Irrelevant DeviceDependent Address 1 1 0=write1=read errorconditions lastlocation
B6500, B7500, and successors
Words contain a 3-bit tag and 48 data bits.
Descriptors describe data blocks. Each descriptor contains a 20-bit address field referencing the data block. Each block has a length which is stored in the descriptor, also 20 bits. Bits 42–40 of a data descriptor designate single precision, double precision, 4-bit digits, 6-bit characters, 7-bit ASCII characters or 8-bit bytes.
The first computer with this architecture was the B6500. The descriptor formats for that machine, later B6x00 machines, and B7x00 machines are described below.
In later implementations, descriptor formats evolved to keep up with growing memory sizes and insights gained over time.
+Word Data descriptor 50-48 47 46 45 44 43 42-40 39-20 19-0 Tag Presence Copy Indexed Segmented Read-only Type/Precision Length/Index Address 101 0=not in memory1=in memory 0=original1=copy 0=no1=yes 0=no1=yes 0=writable1=read-only 000=single001=double
+String Data descriptor 50-48 47 46 45 44 43 42-40 39-20 19-0 Tag Presence Copy Indexed Segmented Read-only Character size Length/Index Address 101 0=not in memory1=in memory 0=original1=copy 0=no1=yes 0=no1=yes 0=writable1=read-only 100=8-bit101=7-bit ASCII011=6-bit010=4-bit
+(Program) Segment descriptor 50-48 47 46 45 44-40 39-20 19-0 Tag Presence Copy Unused Unused Length Address 011 0=not in memory1=in memory 0=original1=copy
Usage in compilers In ALGOL, the bounds of an array are completely dynamic, can be taken from values computed at run time, unlike in Pascal, which came later, based on ALGOL, where the size of arrays is fixed at compile time. This is the main weakness of Pascal as defined in its standard, but which has been removed in many commercial implementations of Pascal, notably the Burroughs implementations (both the University of Tasmania version by Arthur Sale and Roy Freak, and the later implementation on Burroughs Slice Compiler system by Matt Miller et al.)
In a program in the Burroughs/Unisys MCP environment, an array is not allocated when it is declared, but only when it is touched at run time for the first time – thus arrays can be declared and the overhead of allocating them avoided if they are not used. Memory management is thus completely dynamic.
Also, low-level memory allocation system calls such as the malloc class of calls of C and Unix are not needed – arrays are automatically allocated as used. This saves the programmer the great burden of filling programs with the error-prone activity of memory management, which is crucial in mainframe applications.
When porting programs in lower-level languages such as C, the C memory structure is dealt with by doing its own memory allocation within a large allocated block – thus the security of the rest of the system cannot be compromised by buffer overflows by errant C programs. In fact, many buffer overruns in apparently otherwise correctly running C programs have been caught when ported to Unisys MCP architecture. C, like Pascal, is also implemented using the Slice compiler system, which uses a common code generator and optimizer for all languages. The C compiler, run-time system, POSIX interfaces, as well as a port of many Unix tools was done by Steve Bartels. An Eiffel compiler was also developed using Slice.
For object-oriented programs which require more dynamic creation of objects than the MCP architecture, objects are best allocated within a single block. Such object allocation is higher level than C's malloc and is best implemented with a modern efficient garbage collector.
Integration in memory architecture The address field in the B5000, B5500, and B5700 was only 15 bits, which meant that only 32K words (192KB) of memory could be addressed by descriptors. The address field in the B6500 became 20 bits or 1 Meg words(6MB). By the mid seventies this was still a significant restriction of the architecture. To overcome this, two solutions were implemented:
Swapper – this solution actually implements another layer on top of memory management, moving large clusters of related data in and out of memory at once. ASN – this solution allowed physically more memory to be configured in a system, divided into separately addressable chunks. This architecture became known as ASN (Address Space Number) memory. Memory was logically divided into two areas, allocating low memory addresses to a Global address space for the operating system and support software and high memory addresses to several parallel Local address spaces for individual programs. Address spaces are numbered, zero indicating Global, 1..n indicating the local address spaces. Programs sharing data are automatically placed in the same address space.
No program code modifications were necessary for these features to be utilized. Both solutions could be combined, but eventually the MCP memory requirements and program data sharing requirements outgrew the maximum size of the address spaces itself.