Jump to content

Burroughs Large Systems

From Alfawiki
Burroughs Large Systems Group
Company typeDivision
IndustryComputer hardware, Mainframe computers
PredecessorElectroData Corporation (acquired 1956)
Founded1961
FounderRobert (Bob) Barton (lead developer of B5000)
Headquarters
United States
ProductsB5000, B5500, B5700, B6500, B6700, B7700, B8500 mainframe computers
ParentBurroughs Corporation

The Burroughs Large Systems Group was responsible for creating a series of large-scale 48-bit mainframes that utilized stack machine architectures with compact syllable instruction formats. The first in this series, the B5000 (introduced in 1961), was specifically designed to efficiently compile ALGOL 60 programs using single-pass compilers. This product line later expanded to include the disk-based B5500 and the B5700, which allowed clustering of up to four systems. Subsequent significant redesigns resulted in the B6500/B6700 families and a separate B8500 series.

During the 1970s, Burroughs Corporation structured its product portfolio into three divisions aimed at high-end, mid-range, and entry-level business markets. Each division employed distinct instruction set architectures optimized for particular programming languages. The term "Burroughs Large Systems" referred to all high-end models, differentiating them from the COBOL-oriented Medium Systems (such as the B2000, B3000, and B4000) and the adaptable Small Systems (including the B1000).

Background

Established in the 1880s, Burroughs stood as one of the longest-running companies in computing history. By the late 1950s, its product range was largely confined to electromechanical accounting machines like the Sensimatic, which left it without competitive large-scale computing systems against industry leaders such as IBM, NCR, and emerging players like Univac. In 1956, Burroughs acquired ElectroData Corporation, adopting its design under the name B205.

The internally engineered B5000 (1961) marked a pivotal change with its groundbreaking architecture based on advanced computing principles. Although this architecture is no longer in use, it laid the foundation for successors including the B6500, B6700, and B7700. Variants of this design continue to be manufactured within the Unisys ClearPath Libra server line, which operates an evolved yet compatible version of the MCP operating system originally developed for the B6700. The third major branch, represented by the B8500, failed to achieve commercial traction. Over time, Unisys shifted from proprietary CMOS processors to Intel Xeon CPUs in their Libra servers, supporting operating systems such as MCP, Microsoft Windows, and Linux. By 2018, Libra systems exclusively relied on standard Intel hardware components.

B5000, B5500, and B5700

The development of the B5000 began in 1961 under the leadership of Robert (Bob) Barton, featuring an architecture that computing expert John Mashey described as "far ahead of its time." It was followed by the B5500 model, which replaced drum storage with disk drives, and then by the B5700 that enabled multiple processors clustered around shared disk resources. Although no direct successor came after the B5700, its design strongly influenced the creation of the B6500 platform, onto which Burroughs ported their Master Control Program (MCP).

Features

  • Hardware specifically designed to support software requirements with exclusive emphasis on high-level programming language usage
  • A streamlined instruction set architecture without assembler language; system software was written in ESPOL, an extended variant of ALGOL 60
  • A partially data-driven architecture featuring tagged data and descriptor-based mechanisms
  • Minimal use of programmer-accessible registers; functions as a Stack machine where all instructions operate on a stack
  • Utilizes stack-based handling for all interrupts and procedure calls
  • Compatibility with languages such as COBOL along with advanced string processing capabilities
  • Automatic generation of reentrant code to support multiprocessing environments
  • Enables asymmetric multiprocessing under MCP
  • Among the earliest commercial implementations of virtual memory and pioneers of segmented memory models
  • Security mechanisms aimed at preventing unauthorized access and operational interference[NB 1]
  • Early adoption of error detection features that facilitated software debugging and testing

System architecture

The B5000's design distinctively merged software demands directly into its hardware configuration, differing from the common approach at the time where hardware was developed independently from software considerations.

Within Word Mode, the B5000 family utilizes two distinct addressing schemes contingent on whether the processor is executing a main program (with SALF disabled) or a subroutine (with SALF enabled). Main program addressing refers to the Program Reference Table (PRT), whereas subroutine addressing varies based on certain operand bits and the state of the Mark Stack FlipFlop (MSFF), as outlined in the subsequent relative addressing chart.

B5x00 Relative Addressing
SALF T0
A38 		T1
A39 		T2
A40 		MSFF Base Contents Index
Sign 		Index
Bits 		Max
Index
OFF — — — — R Location of PRT + T 0-9
A 38-47 		1023
ON OFF — — — R Location of PRT + T 1-9
A 39-47 		511
ON ON OFF — OFF F Address of last RCW or MSCW on stack + T 2-9
A 40-47 		255
ON ON OFF — ON (R+7) F register from MSCW at PRT+7 + T 2-9
A 40-47 		255
ON ON ON OFF — C Location of current instruction word + T 3-9
A 41-47 		127
ON ON ON ON OFF F Address of last RCW or MSCW on stack — T 3-9
A 41-47 		127
ON ON ON ON ON (R+7) F register from MSCW at PRT+7 — T 3-9
A 41-47 		127

Clarifications:

  • C (current instruction word) relative addressing is forced to R (PRT) relative for Store, Program, and I/O Release instructions
  • MSCW stands for Mark Stack Control Word
  • MSFF denotes Mark Stack FlipFlop
  • F indicates the register from MSCW located at PRT+7
  • For Operand Call and Descriptor Call syllables, relative address is derived from bits 0–9 (T register) of the syllable. In Store operations, if the Flag bit is set, the top of stack holds an absolute address; if not, it holds a relative address
  • RCW means Return Control Word
  • SALF refers to Subroutine Level Flipflop

Programming language compatibility

The B5000 was engineered to exclusively accommodate high-level programming languages during the initial emergence of FORTRAN and COBOL. Instead of adopting these languages, it embraced Algol 60#ALGOL-60, specifically utilizing the Elliott ALGOL variant created by C. A. R. Hoare on an Elliott 503. This adapted version enhanced ALGOL by incorporating I/O capabilities and robust string manipulation instructions, thereby improving its functional utility.

Prominent experts such as Donald Knuth contributed to the B5000’s development, supporting ALGOL’s viability as a systems programming language despite doubts about whether high-level languages could rival assembler efficiency.

Burroughs’ ALGOL compiler was notably rapid, earning praise from scientists including Edsger Dijkstra, who promptly adopted the platform at Eindhoven University of Technology. The compiler’s speed stemmed largely from its one-pass compilation strategy, which mandated variable declarations prior to use—enabling compilation concurrently with source code reading. Burroughs machines matched their top-tier card reader throughput by compiling programs as swiftly as cards were processed.

In a similar vein, Burroughs’ COBOL compiler also employed a single-pass design that compiled extensive programs at card reader speeds, allowing immediate program availability upon input completion.

B6500, B6700/B7700, and Their Successors

Introduced in 1969, the B6500 along with the B7500 represent the sole surviving Burroughs system lineage, showcasing an innovative architecture derived from the B5000. Notable features included:

  • Instructions of variable length composed of 8-bit syllables rather than fixed 12-bit units
  • A 51-bit word size (excluding error-checking bits), with 3 bits allocated as a tag
  • Capability for SMP configurations
  • Implementation of a Saguaro stack mechanism
  • Support for paged arrays
  • Display Registers (D1 through D32) facilitating access to variables in outer blocks during nested subroutine calls
  • Integration of monolithic integrated circuit technology alongside magnetic thin-film memory

By 1971, all five universities in New Zealand had adopted the B6700 and B7700 systems.

The supercomputer ILLIAC IV employed a B6500 as its "I/O control computer," which managed supervisory tasks and coordinated input/output operations with ILLIAC IV's memory.

B8500

The B8500 series stemmed from the D825, a military-grade computer influenced by the B5000 design. Developed during the 1960s, its objective was to unify the architectures of the B5500 and D825, utilizing monolithic integrated circuits and magnetic thin-film memory. It featured a 48-bit word structure, stack operations, and descriptors similar to those in the B5500 but lacked backward compatibility. Due to persistent reliability challenges, the B8500 project was discontinued after 1970 without delivering any operational systems.

History

Early explorations into virtual memory appeared in pioneering machines such as the Ferranti Atlas and the Rice Institute Computer, which also introduced concepts like descriptors and tagged architectures. While these innovations influenced Burroughs designs, the architectures of the B5000, B6500, and B8500 diverged considerably from one another as well as from their predecessors.

Burroughs’ large-scale systems began with the 1961 introduction of the B5000—a second-generation transistor-based computer equipped with magnetic-core memory—followed by iterations like the B5500 and B5700. The B6500 and B7500 succeeded the original B5000 architecture, evolving through subsequent models including the B6700, B7700, B6800, B7800, B5900, and B7900, ultimately leading to the Burroughs A series. Following Burroughs’ merger with Sperry Corporation forming Unisys, development persisted with MCP-based machines employing CMOS ASIC technology such as the Libra 100 through Libra 500 series. Later Libra models—like the Libra 590 announced in 2005—incorporate Intel Xeon processors capable of emulating Burroughs large systems architecture alongside MCP CMOS processors. Plans regarding future ASIC development within Unisys remain uncertain.

Burroughs (1961–1986)
B5000 1961 inaugural system; second-generation transistor computer
B5500 1964 threefold performance increase
B6500 1969 third-generation system using integrated circuits; supports up to four processors
B5700 1971 rebranded version of B5500
B6700 1971 enhanced iteration of B6500
B7700 1972 faster CPU with stack cache; supports up to eight partition requestors
B6800 circa 1977 semiconductor memory implementation; features NUMA architecture
B7800 circa 1977 advanced semiconductor memory system supporting up to eight requestors
B6900 circa 1979 NUMA design; maximum four CPUs sharing local and global memory
B5900 1981 NUMA architecture continuation; supports up to four CPUs sharing local and global memory II
B7900 circa 1982 accelerated NUMA system with caches; flexible CPU-memory association
A9/A10 1984 mid-range pipelined processor; first to enable expanded Memory Addressing (eMode Beta)
A12/A15 1985 redesigned using Motorola ECL MCA gate arrays; scalable CPU/HDUs
Unisys (1986–present)
Micro A 1989 desktop mainframe featuring single-chip SCAMP processor
Clearpath HMP NX 4000 circa 1996 enterprise server platform
Clearpath HMP NX 5000 circa 1996 enterprise server platform
Clearpath HMP LX 5000 1998 Burroughs large systems emulated on Xeon CPUs
Libra 100 early 2000s mainframe-class server
Libra 200 early to mid-2000s mainframe-class server
Libra 300 early to mid-2000s mainframe-class server
Libra 400 early to mid-2000s mainframe-class server
Libra 500 circa 2005 e.g., Libra 595 model
Libra 600 mid-2000s mainframe-class server
Libra 700 2010 e.g., Libra 750 model supporting modern applications and mobile device integration


Core hardware divisions

The design, development, and production of both hardware and software were divided between two primary sites: one located in Orange County, California and the other near Philadelphia. The original Large Systems Plant, responsible for creating the B5000 and B5500 models, was initially situated in Pasadena, California before relocating to City of Industry, California, where the B6500 was developed. Facilities in Orange County—mainly based in Mission Viejo, California, with intermittent operations in Irvine and Lake Forest—focused on the smaller B6x00 series. Meanwhile, East Coast operations in Tredyffrin, Pennsylvania oversaw the larger B7x00 series. All these systems maintained full object compatibility, enabling software compiled for one model to run seamlessly on others. Newer models introduced instructions not supported by earlier versions; when encountering unknown instructions, the operating system would interpret them. Variations also existed in process switching mechanisms, input/output management, and maintenance functionalities. Larger systems incorporated hardware-level process scheduling, advanced I/O components, and upgraded maintenance processors. These distinctions persisted even as the Bxx00 series evolved into the A Series, though they were no longer indicated by model numbers.

ALGOL

Burroughs’ large-scale systems utilized stack architectures derived from ALGOL principles, with the B5000 recognized as the first system based on a stack structure. Although primarily engineered for ALGOL programming, these machines also supported business-oriented languages such as COBOL, benefiting from powerful string operations that facilitated rapid compiler construction.

Burroughs ALGOL represents an enhanced subset of ALGOL featuring sophisticated string manipulation capabilities while omitting certain elements like unspecified formal parameters. Its DEFINE construct resembles C language’s #define directive but is embedded within the language itself rather than functioning as a separate preprocessor step. The EVENT data type facilitates process synchronization, whereas ON FAULT blocks handle error management within programs.

At the user level, ALGOL excludes unsafe constructs required only by system-level software. Two extension tiers—ESPOL and NEWP—offer additional constructs necessary for developing the MCP and related system software. Furthermore, DCALGOL and DMALGOL provide specialized extensions tailored for particular system software functions.

ESPOL and NEWP

The Master Control Program (MCP) for the B5000 was originally developed using ESPOL (Executive Systems Programming Oriented Language), an extended superset of ALGOL 60 designed specifically for system programming on Burroughs multiprocessor platforms. ESPOL supported low-level operations such as processor interrupts and was utilized throughout the development of MCP from the B5000 up to the B6700 models. Its single-pass compiler delivered compilation speeds exceeding 250 lines per second.

During the mid to late 1970s, ESPOL was superseded by NEWP, a more secure subset of ALGOL that removed seldom-used features and enforced stringent safety standards. Constructs deemed unsafe in NEWP must be explicitly marked and require administrative authorization prior to execution, implementing a layered protection scheme. This security framework restricts even privileged users’ ability to run unsafe code depending on organizational policies.

NEWP is designed to support extensive software projects through features like named interfaces, interface groups, modules, and super-modules. Modules encapsulate data and procedures with controlled access via interfaces; super-modules aggregate multiple modules to enable complex system structures such as those needed for operating system development. While NEWP omits certain ALGOL features, it remains well-suited for robust system programming within Burroughs environments.

DCALGOL and Message Control Systems (MCS)

Initially, message input and output from remote devices were managed by a dedicated 24-bit data communications processor (DCP). Communication between the DCP and the B6500 system was conducted through memory messaging, while the Message Control System (MCS) handled processing on the B6500 side. Early development tools included the DCP assembler called Dacoma and a B6500-based ALGOL application known as DCPProgen. Subsequently, the Network Definition Language (NDL) compiler was introduced to produce DCP code alongside network definition files, later advancing to NDLII for use with models 4 and 5 DCPs. The ALGOL routines mirrored DCP instructions, effectively functioning as a macro assembler—compiling ALGOL code generated programs that outputted binary code for the DCP.

Starting in the early 1980s, the Integrated Communications Processor (ICP) replaced the earlier DCP technology, enabling mainframe connectivity over local area networks (LANs). Remote terminals connected via CP2000 nodes, which supported BNAV2 (Burroughs Network Architecture Version 2), a protocol comparable to IBM’s SNA with interoperability features. This hardware transition did not necessitate modifications to the existing MCS software.

Incoming messages were routed from the DCP through an internal bus to the MCP Datacom Control (DCC) process stack. The DCC queued messages for dispatch to the appropriate MCS instance and returned responses to originating devices. The MCS software remained consistent across various gateway hardware configurations, including different generations of DCPs as well as ICP/CP2000 setups.

Beyond its role in message routing, MCS functioned as middleware that provided an additional security layer between operating system components (NEWP) and user-level applications written in ALGOL, COBOL, FORTRAN, and later JAVA. Developed in DCALGOL (Data Communications ALGOL), MCS accepted messages from DCC queues and forwarded them for further handling. Prominent MCS implementations comprised CANDE (Command AND Edit), an interactive program development environment; COMS, launched circa 1984 as a high-throughput transaction processing platform; GEMCOS; and TPMCS, developed by an Australian Burroughs affiliate. These systems facilitated application data transmission and response coordination in online production settings.

MCS optimized user session management by maintaining user states without spawning individual processes per user, enabling multiple users to share a single MCS stack. Performance scaling was achieved by adjusting stack numbers based on active user counts, thereby avoiding overhead associated with initiating separate user processes. This architectural choice offered significant performance benefits on B5000 servers and supported robust transaction processing at scale.

Around 1988, a TCP/IP implementation was crafted primarily for a U.S. government customer using CP2000 as the protocol host. Within two to three years, this was redeveloped into a host/server architecture delivering enhanced performance and expanded capabilities. Parallel efforts implemented OSI protocol stacks predominantly on CP2000 hardware with extensive mainframe integration, supporting full OSI applications such as X.400 email services and X.500 directory management.

DMALGOL and databases

DMALGOL (Data Management ALGOL) represents an ALGOL dialect extended specifically to compile database software for DMSII based on definitions created by the DASDL compiler. Database designers compile these DASDL descriptions into DMALGOL source code tailored to particular tables and indexes—eliminating manual DMALGOL programming by database administrators. Application-level programs written in languages like ALGOL or COBOL are augmented with database-specific commands and transactional directives to interact with these databases. A distinctive feature of DMALGOL is its preprocessing capability that generates code managing tables and indices through variables, loops, and compile-time identifier generation—offering greater customization than conventional preprocessors.

DMALGOL supplies specialized access routines for DMSII databases. After defining a database schema in DASDL, it is preprocessed into DMALGOL routines which are then compiled. This methodology minimizes runtime conditional logic related to database operations, thereby optimizing memory usage and execution speed—an essential advantage given the resource constraints of the 1970s. As hardware capabilities improved over time, reliance on preprocessing diminished in favor of simpler coding styles and broader compiler optimizations.

BDMSALGOL, an applications-oriented ALGOL variant, provides database interaction verbs such as "FIND," "LOCK," "STORE," "GET," "PUT," along with transaction control commands "BEGINTRANSACTION" and "ENDTRANSACTION" designed to handle deadlock scenarios during concurrent data updates.

Roy Guck of Burroughs played a key role in developing DMSII.

Subsequent advancements moved most preprocessing constructs into standard user-level ALGOL code, reserving only unsafe operations and direct database description processing for DMALGOL itself.

Stack architecture

Early computing systems generally discouraged the use of small subroutines due to the high overhead associated with procedure calls and stack management. In contrast, the B5000 was engineered as a stack-based machine, placing all program data—except for arrays, including strings and objects—directly on the stack. This design optimized stack operations for greater efficiency. Being a stack-centric architecture, it does not provide registers accessible to programmers.

The B5000 and its successor B6500 series offer effective multitasking capabilities, supported by dedicated instructions for process switching: IP1 and IP2 on the B5000 models, and MVST on the B6500 and later versions. Each process (task or thread) is represented by its own stack along with an associated Program Reference Table (PRT). Tasks may enter a blocked state when awaiting resources or processor time in a preemptive multitasking environment. Importantly, only the operating system can execute IP1, IP2, or MVST instructions; user-level programs are restricted from issuing these commands.

Process switching is triggered when a process requests a resource that is currently unavailable or when a timer interrupt occurs. At this point, the operating system takes control over the user stack, disables user timers, queues the current process accordingly, selects the next ready process from the queue, and uses the move_stack instruction to activate it.

Stack speed and performance

Historically, stack-based machines were perceived as slower compared to register-oriented architectures such as those used in the IBM System/360, which favored registers over stacks. To address this performance gap, the B5000 reserved the top two positions of the stack as registers A and B, with most instructions operating on these registers. Subsequent B5000 models increased the portion of the stack held in registers or processor-adjacent cache memory, significantly enhancing performance without necessitating code modifications or recompilation. This approach safeguarded software investments by allowing programs to run unchanged across multiple hardware upgrades—a benefit less achievable with register-based systems.

Advocates of RISC architectures contended that processor speed benefits when all components fit onto a single chip—a valid argument during the 1970s when complex designs like the B5000 consumed excessive transistor counts. However, modern iterations of B5000 successors are implemented entirely on single chips and incorporate contemporary features such as caches and instruction pipelines. A notable milestone was reached in the late 1980s with the A Series’ Micro-A processor—the first mainframe CPU realized on a single chip (SCAMP), deployed on an Intel-compatible plug-in PC board.

How programs map to the stack

An illustration of how a program corresponds to stack structure:

begin — Lexical level 2 (level 0: OS; level 1: code segments)

— Global variables: integer i, j, k; real f, g; array a [0:9];

procedure p (real p1, p2); 

  value p1; — p1 passed by value; p2 by reference.
  begin
     — Lexical level 3
     real r1, r2;
     r2 := p1 * 5;
     p2 := r2; — assigns value to g
     p1 := r2; — modifies local copy of p1
     
     if r2 > 10 then
        begin
           — Lexical level 4
           integer n;
           ... <== sample stack execution point.
        end;
  end;

.....

p (f, g); end.

Each frame on the stack corresponds to a lexical scope level based on static source code nesting rather than dynamic call nesting. ALGOL’s scoping rules require forward declarations and allow inner blocks to overshadow outer variables bearing identical names. Although lexical nesting typically does not exceed five levels, B5000 systems support up to 32 levels to accommodate deeply nested structures—though excessive nesting can complicate generated Algol source code.

Procedures

Procedures may be activated using four distinct methods: normal, call, process, and run.

The normal method halts the execution of the invoking routine until the called procedure completes, adhering to conventional routine call semantics.

Using the call approach, a procedure is launched as a coroutine—these are cooperating tasks sharing the same lexical level but maintaining separate stacks. Control is explicitly transferred between the initiating routine and the coroutine through a CONTINUE command.

The process method initiates a procedure as an asynchronous task with its own dedicated stack, operating independently from its caller. This allows efficient access to the surrounding environment and supports robust Inter Process Communication (IPC). Since variables may be shared among concurrent tasks, synchronization mechanisms are essential to avoid race conditions. This is achieved via the EVENT data type, which enables processes to WAIT for events signaled by others and ensures mutual exclusion through PROCURE and LIBERATE operations. When a child process ends, the parent proceeds unaffected; however, if the parent terminates, all its child processes are also terminated. On multiprocessor platforms, these processes may execute concurrently, with EVENT structures forming the foundation of multiprocessing and multitasking functionality.

Run invocation type

The run invocation launches a procedure as an autonomous task that continues running even after the originating process has ended. As a result, it cannot access variables from the parent scope, and all arguments must be passed strictly by value.

Burroughs Extended ALGOL integrated multiprocessing and synchronization capabilities resembling those found in subsequent languages such as Ada, utilizing hardware support for asynchronous execution.

Inline procedures

In NEWP, procedures can be designated as INLINE, prompting the compiler to embed their code directly at call sites to remove call overhead—this is particularly advantageous for brief code segments. Inline procedures function similarly to parameterized macros (like C #defines), but avoid the common pitfalls associated with macros and parameter substitution.

Asynchronous calls

While normal calls operate on a single stack, asynchronous calls create individual stacks for each process, permitting concurrent execution alongside shared data access.

Display registers

A significant hardware enhancement involves D (or "display") registers that correspond to lexical scope levels within source code. These 32 registers point to the base of each active stack frame and update automatically as procedures enter or exit their scopes; only the MCP can access them. This setup supports up to 32 levels of lexical nesting.

Without D registers, referencing a variable at lexical level 2 from level 5 would require traversing control words across intermediate stack frames—a slow process. With D registers, variable addresses are swiftly computed by adding their offset to the base address stored in the relevant register, enabling access to outer or global environments with efficiency comparable to local variables.

When a procedure runs as a coroutine or process, its environment occupies a separate D-based stack, allowing asynchronous tasks to access outer scopes as dictated by ALGOL semantics. Cross-program calls are facilitated by constructing stack frames that reference across different process stacks, enabling interoperability between programs written in various languages and compiled by diverse compilers.

The environments represented by D[1] and D[0] correspond to shared code segment dictionaries and operating system exports respectively; these do not reside within any particular process's stack.

Stack frames are not confined solely to process stacks; early file I/O optimizations linked file information blocks into display registers at D[1]. Advanced language constructs such as STRUCTURE BLOCKs and CONNECTION BLOCKs leveraged this feature to implement object-oriented concepts well before such terminology became widespread.

Unlike systems that compile code into flat memory addresses of fixed bit widths (16-, 32-, or 64-bit), this architecture employs a two-part addressing scheme: variables reside at offsets within lexical-level stack frames rather than absolute memory locations. Arrays hold only single-word descriptors here. This compact addressing strategy reduces storage requirements and enhances performance. For instance, the VALC instruction uses 14-bit addressing fields that include bits dedicated to specifying lexical levels, facilitating concise referencing of entities within nested scopes.

Importantly, this design mitigates many memory errors often seen in flat addressing environments. Tasks cannot overwrite each other's memory due to restricted addressing capabilities; hardware enforces boundary checks against stack frames to detect invalid accesses. Array descriptors incorporate hardware-enforced bounds checking, effectively isolating address spaces for each array. Additionally, memory tagging safeguards data integrity by preventing inappropriate assignments—for example, disallowing pointers or executable code from being overwritten with incompatible data.

Array Storage

Arrays were assigned distinct address spaces identified through descriptors rather than being stored contiguously alongside other variables. Accessing elements required computing the index on the stack, which supported the entire integer range, and then applying it as an offset with hardware-enforced bounds checking. By default, arrays larger than 1,024 words were divided into segments, transforming the index into a combination of segment index and offset; specifying LONG prevented this segmentation.

In ALGOL, multidimensional arrays employed multiple levels of addressing: for an element like A[i,j], the first index selected a descriptor array representing each row, followed by indexing within that specific row. Hardware ensured bounds verification for every index used. Conversely, FORTRAN treated multidimensional arrays as a flat one-dimensional sequence, calculating offsets through arithmetic operations without individual index validation, which could occasionally allow out-of-bound accesses to remain unnoticed.

Because array storage was isolated, resizing arrays was straightforward; however, altering dimensions was prohibited due to compiler limitations. This design facilitated "ragged" arrays in ALGOL, where rows could differ in length—for instance, sparse arrays where each row contained only enough space for non-zero elements.

Segmentation also enhanced memory efficiency: slightly increasing an array’s size beyond 1,024 words could mitigate thrashing by segmenting the array so that only necessary segments were loaded into memory. Segments were allocated dynamically during runtime upon access and initialized to zero; therefore, bypassing initial zeroing was sometimes acceptable despite potential risks.

Array equivalencing permitted viewing the same memory area through different data types. The ARRAY declaration allocated 48-bit words typically used for REAL data, for example: 

  ARRAY A [0:99]

reserved 100 REAL words. Equivalence declarations allowed this data to be accessed as character-based arrays (EBCDIC), hexadecimal, or ASCII: 

  EBCDIC ARRAY EA [0] = A[*];  
  HEX ARRAY HA [0] = A[*];  
  ASCII ARRAY AA [0] = A[*];

It was also possible to request data type-specific arrays directly, such as: 

  EBCDIC ARRAY MY_EA [0:99]

which allocated character arrays aligned to word boundaries. The compiler-generated Data Descriptor specified the intended data type usage; equivalence declarations created copy descriptors referencing the original descriptor to maintain correct memory indexing.

BOOLEAN and INTEGER arrays were supported as well and could serve as bit vectors or collections of integers. Although ALGOL syntax is used here for illustration purposes, comparable array capabilities existed in COBOL and FORTRAN.

Advantages of Stack Structure

One notable advantage of using a stack structure is that if a program encounters failure, a stack dump captures the precise program state at the time of error, making debugging significantly easier compared to core dumps on other systems.

The stack architecture inherently supports recursion. While traditional FORTRAN lacked recursion capabilities, the B5000 system enabled it effortlessly. Burroughs’ FORTRAN compiler accommodated recursive calls with correct returns—a feature uncommon among contemporaries. Although this sometimes resulted in stack overflows during complex recursive operations, it also allowed enhanced error detection. For example, it verified that subroutines and functions received the correct number of parameters—a frequent cause of crashes elsewhere—and enforced strict array-bound checks. Burroughs earned a reputation for pioneering compilers and language implementations, including object-oriented Simula support. Kenneth E. Iverson, creator of APL, regarded Burroughs’ APL implementation as the finest he had encountered. While John McCarthy, originator of LISP, preferred modifiable code unlike B5000’s fixed-code approach, most LISP systems ran interpretively regardless.

Memory allocation for multiple processes was handled dynamically from a shared system pool, eliminating the need for preconfigured memory partitions (SYSGEN) required by competing systems.

Tagged architecture

In addition to its stack machine design, the B5000 is notably characterized by its tagged and descriptor-oriented architecture.

Initially, a single flag bit was used to differentiate control words from numeric words in memory, which enhanced system integrity by preventing programs from overwriting control words on the stack.

With the introduction of the B6500, this idea evolved into a three-bit tag positioned outside the 48-bit word: bits 0 through 47 contained the data, while bits 48 to 50 formed the tag. Bit 48 signified a read-only attribute; control words were identified by odd-numbered tags and were safeguarded against user modifications. Tag 3 was reserved for code words. The primary tags included:

Tag Word type Explanation
0 Data System and user data such as text and single-precision numbers
2 Double Double-precision numerical data
4 SIW Step Index Word used for loop control
6 Uninitialized data
SCW Software Control Word managing stack operations
1 IRW Indirect Reference Word
SIRW Stuffed Indirect Reference Word
3 Code Program code words
MSCW Mark Stack Control Word
RCW Return Control Word
TOSCW Top of Stack Control Word
SD Segment Descriptor
5 Descriptor Descriptors for data blocks
7 PCW Program Control Word indicating procedure entry points

Certain models internally utilized 60-bit words augmented with additional bits for error correction, although these extra bits remained hidden from programmers.

Contemporary Unisys ClearPath systems have extended tags to four bits at the Gamma microcode level.

Words tagged with even numbers represent modifiable user data, while those with odd tags correspond to hardware-generated execution states. Because odd-tagged formats are hardware-managed, alterations in system word formats do not necessitate recompilation; thus, code behavior remains consistent across different implementations.

Tag 1 words serve as on-stack data pointers: IRWs hold addresses within the current stack, whereas SIRWs incorporate a stack identifier allowing references across separate stacks created by CALL and PROCESS commands.

Tag 5 identifies descriptors that point to data located off-stack (explained further below).

Tag 7 corresponds to the Program Control Word (PCW), which marks procedure entry locations. When hardware encounters a PCW, it initiates procedure execution; ENTR instructions explicitly enter routines that do not return values, while functions are implicitly invoked by operators such as VALC. Shared global routines exist as SIRWs pointing to PCWs within shared code segment dictionaries, facilitating reentrant and shared code usage among multiple processes.

Tag 3 designates both program code words and specific stack control words including MSCW, RCW, and TOSCW.


Descriptor-based architecture

The Burroughs Large System architecture was essentially designed as hardware support for object-oriented programming, a capability that remains relatively rare in traditional architectures.


Instruction sets

Burroughs large systems employ three separate instruction sets, all constructed from short syllables that fit evenly into machine words.

B5000, B5500 and B5700

Software running on the B5000, B5500, and B5700 utilizes 12-bit syllables, with four syllables packed into each word. The architecture supports two distinct modes—Word Mode and Character Mode—each with its own unique syllable repertoire. Processors operate in either Control State or Normal State; certain syllables are restricted exclusively to Control State. Addressing is performed indirectly via a 1024-word Program Reference Table, the active code segment, stack positions, or through A and B registers representing the top of the stack.

B6500 and Its Successors

Programs are constructed from 8-bit syllable units, which can be categorized as Name Call, Value Call, or operators ranging from one to twelve syllables in length. There are fewer than 200 distinct operators, many of which exhibit polymorphism based on data tagging. When excluding string-related operations and system-reserved commands such as MVST and HALT, typical user-level applications generally utilize under 100 operators. Name Call and Value Call syllables incorporate address couples, whereas operators either operate without addresses or employ stack-oriented control words and descriptors.

Multiprocessing Architectures

The B5000 series was a pioneer in implementing dual-processor setups with a master-slave configuration. Subsequent models—the B6000, B7000, and B8000—adopted symmetric multiprocessing architectures; notably, the B7000 could support up to eight processors provided that at least one was dedicated to I/O tasks. For low-level synchronization between processors, the RDLK (ReaD with LocK) instruction offers atomic single-cycle semaphore operations. Higher-level synchronization mechanisms rely on the EVENT data type, though these incur additional system overhead. To alleviate this cost, Dahm locks—named after Burroughs software specialist Dave Dahm—utilize the READLOCK ALGOL construct, which compiles down to RDLK-based operations.

Essential multiprocessing operators include:

  • HEYU — issues an interrupt signal to another processor
  • RDLK — a low-level semaphore facilitating atomic "swap" operations without temporary registers; commonly invoked in Algol via expressions like x:=RDLK(x,y);
  • WHOI — returns the identifier of the executing processor
  • IDLE — suspends execution until an interrupt is received

A known issue arises when two processors simultaneously send each other 'HEYU' interrupts, resulting in a deadlock condition termed a 'deadly embrace,' which halts system operation.

Legacy and Impact of the B5000

The architectural legacy of the B5000 endures within Unisys ClearPath mainframes, direct descendants of the B6500 that continue running the MCP operating system after over four decades of evolution. This architecture operates in what is known as emode (emulation mode), where Intel Xeon CPUs employing the x86 instruction set emulate the original B5000 instruction set. Although there were intentions to develop a native execution mode (nmode), this effort was discontinued; consequently, these systems are primarily recognized as "emode machines."

B5000 systems were distinctive for being programmed exclusively in high-level languages without any assembly language usage.

Chuck Moore, creator of the Forth programming language, acknowledged inspiration from the B5500's stack instructions such as DUPL, DLET, and EXCH, which influenced Forth's fundamental commands DUP, DROP, and SWAP.

The B5000's stack-based architecture combined with tagged memory concepts also shaped the design of Soviet Elbrus mainframes and supercomputers. Initial Elbrus models featured comparable architectures programmed in high-level languages alongside a tailored ALGOL 68 assembly dialect supporting structured programming paradigms. Later iterations transitioned toward EPIC-style VLIW processors.

Hewlett-Packard engineers working on the HP 3000 business computer drew inspiration from the B5500’s design philosophy and sought to emulate its software on a 16-bit minicomputer platform. Other HP divisions developed similar stack-oriented minicomputers and microprocessors. Bob Barton’s contributions to reverse Polish notation (RPN) notably influenced HP’s calculator line beginning with the 9100A and prominently with the HP-35.

Tandem Computers’ NonStop systems from the late 1970s through early 1980s were 16-bit stack-based machines indirectly influenced by B5000 concepts via HP personnel. These systems migrated to MIPS RISC architectures around 1990 but maintained compatibility with stack machine binaries through translation or emulation layers. Post-2000 transitions moved them onto Itanium platforms while preserving legacy binary support.

Bob Barton’s impact extended to Alan Kay, whose understanding of the B5000’s data-driven tagged memory model informed his pioneering work on object-oriented programming languages and Smalltalk development.

The B5000’s hardware-enforced secure architecture anticipated modern virtual machine designs such as the Java JVM that provide protected runtime environments for applications.

Although MCP remains the exclusive operating system on emode x86-based machines—retaining much of the original hardware-architecture integration—the support quality on these emulated environments is inferior compared to true native B6500 hardware implementations. Similarly, Intel’s earlier iAPX 432 processor architecture offered an object-oriented hardware foundation conceptually akin to that of the B5000.

See also

References

  • The Extended ALGOL Primer (Three Volumes), Donald J. Gregory.
  • Computer Architecture: A Structured Approach, R. Doran, Academic Press (1979).
  • Stack Computers: The New Wave, Philip J. Koopman, accessible at: [1]
  • Manuals for B5500, B6500, B6700, B6800, B6900, B7700 available at: bitsavers.org


Further reading


External links


Cite error: <ref> tags exist for a group named "NB", but no corresponding <references group="NB"/> tag was found

Retrieved from "https://www.alfawiki.org/index.php?title=Burroughs_Large_Systems&oldid=26381"