Executive Systems Problem Oriented Language

Burroughs Large Systems Group

Company type	Division
Industry	Computer hardware, Mainframe computers
Founded	1961
Founder	Robert (Bob) Barton
Headquarters	United States
Products	B5000, B5500, B5700, B6500, B6700, B7700, B8500 mainframe computers
Parent	Burroughs Corporation

The Burroughs Large Systems Group engineered a series of high-capacity 48-bit mainframes characterized by stack machine instruction sets utilizing compact syllables. The initial model, the B5000 (1961), was specifically designed to optimize the compilation of ALGOL 60 programs through single-pass compilers. This platform later progressed into the disk-based B5500 and the B5700, which introduced clustered system capabilities. Subsequent significant redesigns produced the B6500/B6700 series alongside the distinct B8500 line.

During the 1970s, Burroughs Corporation structured its operations into three divisions aimed at delivering high-end, mid-range, and entry-level business computing solutions. Each division employed unique instruction set architectures tailored to particular programming languages. The "Burroughs Large Systems" brand represented these premium offerings, distinguishing them from the COBOL-focused Medium Systems (B2000, B3000, B4000) and the adaptable Small Systems (B1000).

Background

Established in the 1880s, Burroughs ranked among the pioneering companies in computing history. By the end of the 1950s, its product range was confined mostly to electromechanical accounting machines such as the Sensimatic, lacking competitive computer models compared to contemporaries like IBM, NCR, and Univac. In 1956, Burroughs acquired ElectroData Corporation, adopting its design as the B205.

The internally created B5000 (1961) represented Burroughs’ strategic late entry into the computer market with an innovative architecture grounded in advanced computing principles. Although this original design is now obsolete, it laid the foundation for descendants like the B6500, B6700, and B7700. Variants of this lineage continue production as part of the Unisys ClearPath Libra servers, operating an evolved iteration of the MCP system introduced alongside the B6700. The third principal line, the B8500, did not achieve commercial viability. Over time, Unisys migrated from proprietary CMOS processors to Intel Xeon CPUs within Libra servers, enabling support for MCP in addition to Microsoft Windows and Linux. By 2018, Libra hardware was exclusively based on standard Intel components.

B5000, B5500, and B5700

Initiated in 1961 under the leadership of Robert (Bob) Barton, the B5000 introduced a groundbreaking architecture praised by computing expert John Mashey as remarkably ahead of its era. Its successor, the B5500, replaced drum storage with disk drives, while the B5700 enabled multiple CPUs to cluster around shared disk resources. Although no direct successor followed the B5700 model, its architectural concepts significantly influenced the design of the B6500, onto which Burroughs ported its Master Control Program (MCP).

Features

• Hardware architecture explicitly designed to support only high-level programming language software
• Simplified instruction set architecture eliminating assembly language; system software was developed using ESPOL, an extended form of ALGOL 60
• Partially data-driven with a tagged and descriptor-based design approach
• Limited registers accessible by programmers; operations were conducted via a stack machine paradigm
• Stack-based handling for all interrupts and procedure calls
• Language support included COBOL and advanced string manipulation capabilities
• Automatic code reentrancy, enabling efficient multiprocessing with minimal programmer intervention
• Compatibility with MCP operating system and support for asymmetric multiprocessing configurations
• Early adoption of a secure architecture preventing unauthorized data access
• Enhanced error detection mechanisms facilitating software development and debugging
• Amongst the earliest commercial systems to implement virtual memory technology, second only to the Ferranti Atlas
• Pioneered introduction of segmented memory models

System architecture

The B5000 series stood out by tailoring its architecture and instruction set specifically to fulfill software demands, a departure from the processor-centric design approach common during its time.

Within Word Mode, the B5000, B5500, and B5700 employed two distinct addressing methods based on the execution context: either the main program (with SALF disabled) or a subroutine (with SALF enabled). Main program addresses are calculated relative to the Program Reference Table (PRT), whereas subroutine addressing relies on specific operand bits combined with the state of the Mark Stack Flip-Flop (MSFF), as outlined in the table below.

B5x00 Relative Addressing

SALF	T0 A38	T1 A39	T2 A40	MSFF	Base	Contents	Index Sign	Index Bits	Max Index
OFF	–	–	–	–	R	PRT address	+	T 0-9 A 38-47	1023
ON	OFF	–	–	–	R	PRT address	+	T 1-9 A 39-47	511
ON	ON	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	Current instruction word address	+	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

Notes:

• C (current instruction word) relative addressing is converted to R (PRT) relative for Store, Program, and I/O Release instructions
• MSCW refers to Mark Stack Control Word
• MSFF stands for Mark Stack Flip-Flop
• F denotes the register from MSCW located at PRT+7
• For Operand Call (OPDC) and Descriptor Call (DESC) syllables, relative addresses are contained in bits 0–9 of the T register; in Store operations, the A register holds either an absolute or relative address depending on a flag bit
• RCW signifies Return Control Word
• SALF means Subroutine Level Flip-Flop

Programming language support

The B5000 was engineered exclusively to support high-level programming languages during the early expansion of FORTRAN and COBOL. Rather than adopting these languages, Burroughs chose Algol 60#ALGOL-60—specifically the Elliott ALGOL variant created by C. A. R. Hoare on an Elliott 503. This dialect enhanced ALGOL by adding input/output and string manipulation features, making it more suitable for systems programming tasks.

Importantly, Donald Knuth had previously implemented ALGOL 58 on an earlier Burroughs machine and contributed advice during the B5000’s development. Despite doubts about ALGOL’s capabilities compared to assembly language, Burroughs successfully validated its utility as an effective systems programming language.

The Burroughs ALGOL compiler was renowned for its exceptional speed, garnering admiration from notable figures such as Edsger Dijkstra, who promptly acquired machines for Eindhoven University of Technology. This rapid compilation performance was largely due to its one-pass compiler architecture, made possible by enforcing variable declarations prior to usage—allowing compilation to proceed at roughly the same pace as reading source code from punched cards. Similarly, Burroughs’ COBOL compiler was also one-pass and matched the fastest card readers, facilitating swift program preparation.

B6500, B6700/B7700, and Their Successors

Introduced in 1969, the B6500 and its counterpart, the B7500, marked a new architectural direction derived from the B5000 but featuring substantial enhancements:

• Instructions of variable length utilizing an 8-bit syllable rather than a fixed 12-bit format
• 51-bit word size (compared to 48-bit) with 3 bits allocated for a tag
• Capability for SMP
• Implementation of a Saguaro stack
• Support for paged arrays
• Display Registers (D1–D32) facilitating access to variables in nested subroutines
• Integration of monolithic integrated circuits combined with magnetic thin-film memory

By 1971, all five universities in New Zealand had adopted these systems. Additionally, the ILLIAC IV supercomputer employed a B6500 as its input/output control unit, overseeing supervisory tasks and I/O management.

These technological advances established the B6500 series as a resilient foundation that continues to influence Burroughs' large system architecture today.

B8500

The B8500 originated from the D825 military computer, itself influenced by the B5000. Developed during the 1960s to unify features of both the B5500 and D825 architectures, it incorporated monolithic integrated circuit technology alongside magnetic thin-film memory. Although it maintained a 48-bit word structure, stack organization, and descriptor system comparable to the B5500, it was not upward compatible. The B8500 failed to achieve stable operation and was discontinued after 1970 without delivering any fully operational units.

History

Early implementations of virtual memory appeared in pioneering systems such as the Ferranti Atlas and the Rice Institute Computer, which also introduced descriptors and tagged architectures. While these early innovations informed Burroughs' designs, the architectures of the B5000, B6500, and B8500 were distinct both from those initial machines and from each other.

Burroughs' large-scale computing line commenced with the B5000 in 1961—a second-generation transistor-based system utilizing magnetic-core memory—followed by successors including the B5500 and B5700. The B6500 and B7500 succeeded the B5000 architecture by incorporating integrated circuits and multiprocessing capabilities. Subsequent models such as the B6700, B7700, B6800, B7800, B5900 (which used the B6500 architecture despite its designation), B7900, and eventually the A series continued hardware development over a span of twenty-five years.

Following Burroughs' merger with Sperry Corporation to form Unisys, new systems were developed based on MCP CMOS ASIC technology. This lineup included the Libra series (from Libra 100 through Libra 700), with later iterations like Libra 590 employing Intel Xeon processors to emulate Burroughs’ large system architecture alongside native MCP CMOS processors. The future trajectory for MCP CMOS ASIC advancements within Unisys remains unclear.

Burroughs (1961–1986)
B5000	1961	initial model; second-generation transistor computer
B5500	1964	offered threefold speed increase
B6500	1969	third-generation machine featuring integrated circuits; supports up to four processors
B5700	1971	rebranded version of B5500
B6700	1971	enhanced iteration of the B6500
B7700	1972	higher-speed processor with stack cache; supports up to eight requestors across one or two partitions
B6800	circa 1977	introduced semiconductor memory with NUMA design
B7800	circa 1977	semiconductor memory-based; faster performance supporting up to eight requestors
B6900	circa 1979	NUMA architecture with semiconductor memory; maximum of four CPUs sharing local and global memory
B5900	1981	NUMA design using semiconductor memory; supports up to four CPUs sharing local/global memory II
B7900	circa 1982	enhanced speed with code and data caches; NUMA architecture offering flexible CPU-memory association
A9/A10	1984	mid-tier pipelined processor; first to incorporate expanded Memory Addressing (eMode Beta)
A12/A15	1985	redesigned using custom Motorola ECL MCA gate arrays; scalable from single-CPU to multi-CPU setups
Unisys (1986–present)
Micro A	1989	desktop mainframe featuring single-chip SCAMP processor
Clearpath HMP NX 4000	circa 1996	enterprise-level server platform
Clearpath HMP NX 5000	circa 1996	enterprise server platform variant
Clearpath HMP LX 5000	1998	executes Burroughs large systems through Xeon-based emulation
Libra 100–700	approximately 2002–2010?	family of MCP CMOS ASIC mainframes; notable models include Libra 595 and Libra 750

Primary hardware divisions

The design, development, and production of both hardware and software were split between two principal sites: one in Orange County, California and another near Philadelphia. The original Large Systems Plant, responsible for the B5000 and B5500 models, was initially located in Pasadena, California before relocating to City of Industry, California to focus on the B6500 series. The Orange County operations, centered in Mission Viejo, California and occasionally including facilities in Irvine, California and Lake Forest, California, oversaw the smaller-scale B6x00 product line. On the East Coast, the Tredyffrin, Pennsylvania facility managed the larger B7x00 series. All systems across these lines maintained full object compatibility—software compiled for one model could seamlessly run on another. Newer versions introduced additional instruction sets absent in earlier machines; instructions unrecognized by older systems were handled by an operating system routine that interpreted them. Variations also existed in aspects such as process switching, input/output processing, maintenance procedures, and cold-start operations. Larger systems incorporated hardware-based process scheduling, enhanced I/O components, and more advanced maintenance processors. When the Bxx00 series was succeeded by the A Series, these architectural differences persisted but ceased to be indicated by model numbering.

ALGOL

Burroughs large-scale systems utilized ALGOL-inspired stack architectures, with the B5000 pioneering stack-based computing.

Although optimized for ALGOL support, the B5000 also provided strong compatibility with business-oriented languages like COBOL, particularly through sophisticated string handling features that facilitated rapid compiler creation.

Burroughs ALGOL represents an extended version of ALGOL, enhancing string manipulation capabilities while omitting certain features such as unspecified formal parameters. It incorporates a DEFINE construct similar to C’s #define directive directly within the language syntax. The EVENT data type enables process synchronization, whereas ON FAULT blocks provide structured error handling.

The user-level ALGOL excludes unsafe constructs necessary for system-level programming. Two extension tiers supply these capabilities: ESPOL and NEWP cater to MCP development and associated system software; DCALGOL and DMALGOL present further enhancements for specialized system programming tasks.

ESPOL and NEWP

The original Master Control Program (MCP) for the B5000 was developed using ESPOL (Executive Systems Programming Oriented Language), an extended superset of ALGOL 60 tailored as a system programming language for Burroughs large multiprocessor environments. ESPOL supported low-level functions such as processor interrupt handling and was employed across Burroughs systems from the B5000 through the B6700 generations. Its single-pass compiler was capable of processing over 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 language features. NEWP enforces safety by disallowing unsafe constructs unless explicitly permitted within designated code blocks, establishing a layered protection scheme. Programs containing unsafe code require authorization from a security administrator prior to execution, imposing restrictions even on privileged users depending on site policies.

NEWP was engineered for large-scale software projects and supports named interfaces (functions and data), collections of interfaces, modules, and super-modules. Modules encapsulate related data and functions while enabling controlled global access; interfaces regulate import and export of functionality. Super-modules group related modules together, facilitating complex system development tasks such as operating system construction.

DCALGOL and Message Control Systems (MCS)

Initially, message input/output from remote devices was managed by a dedicated data communications processor (DCP), a 24-bit minicomputer. Communication between the DCP and the B6500 occurred through in-memory messaging, while the MCS handled processing on the B6500 side. Early development tools comprised an assembler named Dacoma and an application called DCPProgen, both developed in B6500 ALGOL. Subsequently, the Network Definition Language (NDL) compiler was introduced to produce DCP code along with network definition files, later advancing to NDLII for model 4 and 5 DCPs. The functions written in ALGOL corresponded directly to DCP instructions, allowing ALGOL programs to compile into DCP binaries via a two-pass compilation method.

In the early 1980s, the DCP was superseded by the Integrated Communications Processor (ICP), which provided LAN connectivity for mainframe systems. Remote devices connected through CP2000 nodes utilizing Burroughs Network Architecture Version 2 (BNAV2), a protocol comparable to IBM’s SNA that supported interoperability modes PUT2 and PUT5. This hardware transition did not necessitate modifications to the existing MCS software.

Message input flowed from the DCP over an internal bus to the MCP Datacom Control (DCC) process stack—one stack per configured DCP. This stack queued incoming messages for delivery to the assigned MCS and routed response messages back to their source devices. From a processing perspective, MCS software maintained uniformity across various gateway hardware configurations, whether operating with different DCP models or ICP/CP2000 combinations.

Beyond simply routing messages, MCS software functions as middleware, providing an additional security layer between the operating system (NEWP) and user applications written in languages such as ALGOL, COBOL, FORTRAN, and later JAVA. Developed in DCALGOL (Data Communications ALGOL), MCS accepts messages from DCC queues and forwards them to relevant applications. Early versions of MCS included CANDE (Command AND Edit), an interactive program development environment. During this period, the University of Otago created SCREAM/6700, a similar lightweight environment contemporaneous with IBM’s CALL/360 for its 360 series systems.

By approximately 1984, COMS was introduced as a high-throughput transaction processing control system. Its predecessors included GEMCOS (Generalized Message Control System) and TPMCS from an Australian Burroughs subsidiary. These transaction processing MCS variants managed application data delivery within online production environments and returned responses to remote users or connected systems.

MCS software plays a vital role in managing user sessions and efficiently maintaining user state without spawning individual processes per user. A single MCS stack can support multiple simultaneous users, facilitating load balancing by scaling stacks according to user volume—for instance, one stack handling up to 30 users, two stacks for 31 to 60 users, and so forth—yielding considerable performance gains on B5000 machines by eliminating per-user process overhead. This design underlies robust large-scale transaction processing functionality.

By 1988, a TCP/IP implementation was created primarily for a U.S. government customer using CP2000 as the protocol host. Within two to three years, this solution was reengineered into a host/server architecture featuring improved performance and capabilities. At the same time, OSI protocol stacks were deployed mainly on CP2000 hardware with extensive mainframe integration, encompassing full OSI applications such as X.400 mail services and X.500 directory support.

DMALGOL and database systems

DMALGOL, short for Data Management ALGOL, represents a specialized ALGOL derivative designed to compile DMSII database software from schema definitions produced by the DASDL compiler. Database architects use these descriptions to generate DMALGOL source code customized for particular tables and indexes, thereby removing the necessity for database administrators to manually code in DMALGOL. Application development predominantly utilizes ALGOL and COBOL enhanced with embedded database commands and transaction control statements to facilitate access. A distinguishing characteristic of DMALGOL is its preprocessing capability, which automatically produces code managing tables and indexes through variables, loops, and compile-time-generated identifiers—providing greater adaptability than conventional preprocessors.

By converting DASDL-defined database schemas into DMALGOL routines, DMALGOL creates optimized access procedures specifically for DMSII databases, significantly reducing the need for conditional logic dependent on the database structure during execution. In the 1970s, this approach substantially minimized both program size and runtime duration; however, its prominence waned as memory and speed constraints relaxed and simpler coding practices enabled enhanced optimization techniques.

BDMSALGOL, an ALGOL variant intended for application development, incorporates database access verbs such as "FIND," "LOCK," "STORE," "GET," "PUT," alongside transaction management directives like "BEGINTRANSACTION" and "ENDTRANSACTION," which help prevent deadlocks during simultaneous data modifications.

Roy Guck of Burroughs played a leading role in the development of DMSII.

With the relaxation of compiler size limitations, most preprocessing functionalities have migrated to the ALGOL user environment; only inherently unsafe operations and direct processing of database descriptions remain exclusive to DMALGOL.

Stack architecture

Earlier computing systems tended to avoid small subroutines because procedure calls entailed expensive stack management overhead. The B5000 architecture was conceived as a stack-based machine where virtually all program data—excluding arrays such as strings and objects—resides on the stack. This design optimized stack operations for maximal efficiency without exposing programmer-accessible registers.

Multitasking capabilities on B5000 and B6500 series machines are highly optimized through dedicated process-switch instructions: IP1 and IP2 on the B5000 line; MVST on B6500 and later models. Each stack paired with its Program Reference Table (PRT) functions as an independent process (task or thread), which can become blocked awaiting resources or CPU time within a preemptive multitasking environment. These instructions are reserved for operating system use; user-level programs cannot invoke them directly.

When a process requests a resource that is currently unavailable or when an interrupt occurs, the operating system executes on the user stack, disables user timers, places the blocked process in an appropriate wait queue, selects another ready process to run, and calls move_stack to switch contexts—thus enabling efficient multitasking management.

Stack performance

Historically, stack-based architectures were considered slower than register-oriented designs—the latter having been evaluated but ultimately rejected for the System/360. To enhance performance, the B5000 reserved its top two stack positions as registers A and B, where most operations take place. Successor systems have extended this concept by maintaining larger portions of the stack within registers or processor-adjacent cache.

This architectural approach allows contemporary B5000 descendants to exploit modern hardware enhancements such as caching and pipelining without necessitating source code modifications or recompilation, thereby safeguarding software investments. It is common for programs to operate seamlessly across multiple processor generations with improved execution speeds—a flexibility less feasible in strictly register-based machines.

Advocates of RISC architectures argued that single-chip processors deliver superior speed—a valid observation during the 1970s when complex designs like the B5000 required too many transistors to fit onto one chip. Presently, all successors to the B5000 are implemented on single integrated circuits incorporating performance features like caches and pipelines. Notably, in the late 1980s, the A Series introduced the Micro-A processor—the first single-chip mainframe CPU (SCAMP)—which functioned on an Intel-based plug-in PC card.

Mapping Programs to the Stack

Programs are organized on the stack according to their lexical levels, with level zero designated for the operating system and level one assigned to code segments. For instance:

begin
   — Lexical level 2: global variables
   integer i, j, k;
   real f, g;
   array a [0:9];
   
   procedure p (real p1, p2);
      value p1;  — passed by value; p2 passed by reference
      begin
         — Lexical level 3 block
         real r1, r2;
         r2 := p1 * 5;
         p2 := r2;  — modifies global variable g
         p1 := r2;  — changes local copy only
         
         if r2 > 10 then
            begin
               — Lexical level 4 block with local variable
               integer n;
               ... <== execution proceeds here
            end;
      end;
      
   .....
   
   p (f, g);
end.

Each activation record on the stack corresponds to a lexical scope that reflects the static nesting of the program rather than the dynamic call sequence. ALGOL's scoping rules mandate forward declarations and permit inner blocks to shadow outer variables with identical names. Typically, programs do not exceed five nested levels; however, B5000 architectures accommodate up to 32 levels, which can complicate automated code generation for deeply nested ALGOL sources.

Procedures

Procedures may be invoked through four distinct methods: normal, call, process, and run.

The normal invocation halts the caller until the procedure completes and returns control.

The call method initiates a procedure as a coroutine—paired tasks that operate cooperatively with their own stacks at the same lexical level. Control is explicitly transferred between the calling process and coroutine using a CONTINUE statement.

The process invocation launches a procedure as an asynchronous task possessing a separate stack at its lexical level. Unlike coroutines, task scheduling is nondeterministic. The procedure retains access to its surrounding environment, facilitating efficient interprocess communication (IPC). Since multiple tasks share variables, synchronization mechanisms are essential to avoid race conditions, implemented via the EVENT data type. Processes may WAIT on events until activated by collaborating processes. EVENTs also provide mutual exclusion through PROCURE and LIBERATE operations. If a child task terminates, its parent continues execution; conversely, if the parent terminates, all child tasks are also ended. On multiprocessor systems, processes can execute concurrently. This EVENT-driven system forms the foundation for multiprocessing alongside multitasking.

Run Invocation

The run invocation starts an autonomous task that persists beyond the lifetime of its initiating process. As a result, this child task cannot access variables from its parent; consequently, all parameters must be passed by value.

Burroughs Extended ALGOL integrated multiprocessing and synchronization capabilities comparable to those found in later languages such as Ada, utilizing hardware features designed for asynchronous process management.

Inline procedures

Within NEWP, procedures can be defined as INLINE, which embeds their code directly at the call site to eliminate the overhead of procedure invocation—particularly beneficial for concise code fragments. These inline routines function similarly to parameterized macros (such as C #defines) but avoid typical pitfalls associated with macro parameters.

Asynchronous calls

The sample program employs only standard calls utilizing a single stack. In contrast, asynchronous calls create distinct stacks for each process, enabling data sharing while allowing independent execution flows.

Display registers

A significant hardware enhancement involves D registers (or "display" registers), which correspond to the lexical nesting structure present in source code. These 32 registers point to the base of each active stack frame and are automatically managed by the MCP during procedure invocations. This design supports up to 32 levels of lexical scope nesting.

Absent D registers, accessing variables in outer lexical scopes requires navigating control words through multiple stack frames, resulting in inefficiency. With D registers, each one directly references the base address of its lexical environment, permitting variable address computation simply by adding the variable’s offset. This renders access to outer and global variables as efficient as local ones.

When a procedure runs as a coroutine or process, it operates on an independent stack while retaining access to outer environments consistent with ALGOL semantics. Cross-program calls are facilitated by creating stack frames that reference across different process stacks, enabling interoperability between languages and compilers.

The environments at D[1] and D[0] hold special significance: D[1] contains the shared code segment dictionary common to all processes executing the same code, while D[0] maps to operating system exports.

Stack frames are not confined to process stacks; early optimizations for file I/O linked file information blocks into display registers at D[1]. Subsequent language features like STRUCTURE BLOCKs and CONNECTION BLOCKs utilized this mechanism, effectively implementing object-oriented concepts long before they became widespread.

Unlike conventional flat memory addressing systems, this architecture employs a two-part addressing scheme: variables reside at offsets within lexical level stack frames, and arrays are represented by single-word descriptors. This approach minimizes storage requirements and supports compact instruction encoding (for example, the VALC opcode uses 14-bit addressing fields). Procedures deeply nested in lexical scope require fewer bits for entity identification while preserving efficient addressing.

Crucially, this method enhances memory safety: tasks cannot overwrite one another’s memory because addresses derive solely from validated offsets within D-register frames. Hardware-enforced bounds checking prevents out-of-range accesses, and tagged memory words maintain type safety by restricting assignments to appropriate locations, thereby safeguarding pointers and code from corruption.

Array storage

Arrays were assigned dedicated address spaces accessed through descriptors. Index calculations occurred on the stack using full integer ranges and served as offsets into the array’s address space, with hardware ensuring bounds compliance. Arrays larger than 1,024 words were segmented by default; indexing then translated into segment plus offset values. Declaring arrays with LONG prevented segmentation. Multidimensional ALGOL arrays employed hierarchical addressing—for instance, A[i,j] accessed a row descriptor array for i before indexing within that row for j. Hardware verified all indices to avoid boundary violations.

By comparison, FORTRAN treats multidimensional arrays as linear sequences, computing offsets via arithmetic operations. While bounds checking applied to the entire sequence, individual dimension indices were unchecked, potentially allowing subtle errors in indexing.

Non-contiguous array storage permitted dynamic resizing without altering declared dimensions, enabling "ragged" arrays where rows vary in length—a useful feature for sparse data sets. For example, a large mostly zero-filled array A[100,100] could be represented as SA[100,0], adjusting each row’s size to encompass only non-zero elements.

Segmented arrays enhanced memory utilization; increasing declared sizes slightly beyond 1,024 words reduced thrashing by loading only necessary segments during runtime. Segments were zero-initialized upon first access, making explicit initialization sometimes unnecessary.

Array equivalencing allowed multiple data type interpretations over the same memory region. The ARRAY declaration allocated 48-bit words typically used for REAL data types. Equivalence declarations enabled viewing this memory as EBCDIC, HEX, or ASCII character arrays without additional allocations. Compile-time generated data descriptors ensured proper indexing and type consistency across equivalenced arrays.

Data-type-specific arrays could also be declared explicitly (e.g., EBCDIC ARRAY MY_EA [0:99]), with allocation aligned to word boundaries due to the word-oriented architecture.

BOOLEAN and INTEGER arrays were supported as well and could serve as bit vectors or collections of numeric values.

These array storage strategies and declarations were uniformly implemented across ALGOL, COBOL, and FORTRAN language environments.

Benefits of the stack architecture

Debugging is made more straightforward through the stack architecture, which generates stack dumps that clearly display the program’s current state, in contrast to conventional core dumps. One significant advantage was its native support for recursion; although FORTRAN initially did not accommodate recursion, the B5000 enabled recursive function calls effortlessly, enhancing error management and overall program stability. Burroughs’ FORTRAN implementation was notable for enforcing parameter validation and array boundary checks, effectively minimizing frequent runtime errors common on other platforms.

Burroughs earned recognition for its advanced compilers and language implementations, including the object-oriented language Simula. Kenneth E. Iverson, creator of APL, regarded Burroughs’ APL implementation as superior to others available. While John McCarthy, the originator of LISP, favored environments where code could be modified dynamically—unlike the fixed-code model of the B5000—most LISP systems were interpreted rather than compiled.

Memory handling was optimized by dynamically assigning storage from a centralized system pool, removing the necessity for pre-allocated memory partitions (SYSGEN) that competitors required.

Tagged architecture

In addition to functioning as a stack machine, the B5000’s design is characterized by a tag- and descriptor-based architecture. Initially, a single flag bit distinguished control words from numeric data to safeguard control information on the stack. This concept was expanded in the B6500 with a three-bit tag positioned outside the 48-bit word; bits 48 through 50 encode tags that categorize word types and enforce access restrictions.

Tag	Word type	Explanation
0	Data	User and system data including text and single-precision numbers
2	Double	Double-precision numeric data
4	SIW	Step Index Word used for loop control
6		Uninitialized data segments
	SCW	Software Control Word responsible for stack management
1	IRW	Indirect Reference Word pointing to addresses on the stack
	SIRW	Stuffed Indirect Reference Word enabling cross-stack addressing
3	Code	Program code words and stack control words such as MSCW, RCW, TOSCW
	SD	Segment Descriptor
5	Descriptor	Descriptors of data blocks located off-stack
7	PCW	Program Control Word marking procedure entry points

Certain systems internally utilized 60-bit words with additional bits dedicated to error correction, which were hidden from programmers. Contemporary Unisys ClearPath machines extended tag length to four bits within microcode level implementations known as “Gamma.”

Tags with even numbers represent modifiable user data, whereas odd-numbered tags correspond to hardware-managed execution states. This distinction allows hardware to alter word formats without requiring recompilation.

Tag 1 IRWs refer to data on the active stack; SIRWs incorporate stack identifiers facilitating cross-stack referencing essential for CALL and PROCESS operations. Tag 5 descriptors point to off-stack data blocks.

Tag 7 PCWs designate procedure entry points: ENTR instructions explicitly invoke routines that do not return values, while value-returning functions are entered implicitly through operators like VALC. Global procedures are stored as SIRWs referencing PCWs within shared code segment dictionaries (D[1]), supporting reentrant and shared code usage across multiple processes.

Tag 3 identifies code words that are not placed on the stack but also encompasses various stack control words.

Descriptor-based architecture

The Burroughs Large System was originally engineered as a hardware platform tailored for object-oriented programming, a characteristic rarely found in traditional computer architectures.

Instruction sets

These large Burroughs systems incorporate three separate instruction sets, each composed of brief syllables that align neatly within machine words.

B5000, B5500 and B5700

On the B5000, B5500, and B5700 models, programs utilize 12-bit syllables, with four syllables packed into each word. The architecture operates in two distinct modes—Word Mode and Character Mode—each employing its own unique syllable collection. Processors switch between Control State and Normal State, with some syllables executable only in Control State. Addressing is performed indirectly through a 1024-word Program Reference Table, the active code segment, stack locations, or via the A and B registers that store the top elements of the stack.

B6500 and successors

In these systems, programs are composed of 8-bit syllables categorized as Name Call, Value Call, or operators spanning from one to twelve syllables in length. The total number of operators remains under 200, many of which exhibit polymorphism depending on associated data tags. User-level programs generally employ fewer than 100 operators when excluding specialized string operations and those reserved for the operating system. Both Name Call and Value Call syllables contain address couples, whereas operator syllables rely on control words and descriptors on the stack or sometimes omit addresses altogether.

Multiple processors

The B5000 series was among the first to implement dual-processor setups featuring master-slave communication over a high-speed bus. Subsequent models such as the B6000, B7000, and B8000 adopted symmetric multiprocessing architectures; notably, the B7000 could support up to eight processors including I/O units.

RDLK (ReaD with LocK) facilitates low-level synchronization within a single processor cycle. For synchronization at higher abstraction levels, the EVENT data type is used but involves additional system overhead. To optimize this, Dahm locks—named after Burroughs software specialist Dave Dahm—utilize the READLOCK ALGOL statement which compiles into efficient RDLK instructions.

Critical operators include:

• HEYU — triggers an interrupt on another processor
• RDLK — a low-level semaphore operator enabling atomic exchange operations without temporary variables (x:=RDLK(x,y);)
• WHOI — retrieves the current processor’s identifier
• IDLE — suspends activity until an interrupt occurs

At times, simultaneous 'HEYU' commands issued by two processors could cause a system deadlock known as a 'deadly embrace'.

Influence of the B5000

The heritage of the B5000 endures within Unisys ClearPath mainframes, direct successors to the B6500 that preserve its architectural principles while running the MCP operating system after four decades of continuous evolution. This design is now referred to as emode (emulation mode) and functions atop Intel Xeon processors utilizing the x86 instruction set by emulating B5000 instructions. A planned native execution mode (nmode) was abandoned; consequently, these systems are commonly identified as "emode machines."

Programming on B5000 systems was exclusively conducted using high-level languages; assembly language was never employed.

The stack-based architecture of the B5000 influenced Chuck Moore—the creator of Forth—who incorporated instructions such as DUP, DROP, and SWAP derived from the B5500. Additionally, its tagged memory model and stack orientation inspired the Soviet Elbrus mainframe and supercomputer lines. Early Elbrus generations featured similar architectures programmed solely in high-level languages alongside a structured ALGOL 68 assembly variant. Later iterations transitioned to EPIC-style VLIW processors.

Designers at Hewlett-Packard developing the HP 3000 business computer were impressed by the B5500’s approach and sought to create a 16-bit minicomputer with comparable software capabilities. HP’s exploration of reverse Polish notation (RPN), influenced by Bob Barton’s research, was incorporated into HP calculators such as the 9100A and HP-35.

Tandem Computers’ NonStop systems during the late 1970s and early 1980s were 16-bit stack machines indirectly inspired by the B5000 through HP connections. These systems migrated to MIPS RISC architectures around 1990 and subsequently adopted Itanium processors post-2000 while maintaining backward compatibility with legacy stack machine binaries via translation or emulation techniques.

Bob Barton also played a role in shaping Alan Kay’s work; Kay drew upon his understanding of the B5000’s data-driven tagged design when pioneering object-oriented programming and developing Smalltalk.

The hardware-enforced security model of the B5000 anticipated contemporary virtual machines focused on secure execution environments—Java’s JVM being a prominent example delivering sandboxed operation.

While MCP remains uniquely supported on x86-based ClearPath platforms, optimal performance continues on hardware where the B6500 instruction set runs natively. The Intel iAPX 432 processor architecture—preceding widespread adoption of 32-bit x86 CPUs—similarly embodied an object-oriented hardware philosophy aligned with that of the B5000.

See also

• Burroughs Medium Systems
• Burroughs Small Systems
• CANDE
• Network Definition Language (NDL)
• Work Flow Language (WFL)
• Octal floating point

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

• Covers the creation and commercial strategy of the Burroughs 5000 series from 1957 through the 1960s.
• Martin, Ian. "'Too far ahead of its time': Britain, Burroughs and real-time banking in the 1960s", presented at the Society for the History of Technology Annual Meeting, 2010.

External links

• Ian Joyner's Burroughs page
• The Burroughs B5900 and E-Mode: A bridge to 21st Century Computing – Jack Allweiss
• (archived) Ralph Klimek’s overview of the B7800 at Monash University
• "Early Burroughs Machines", Computer Museum at the University of Virginia
• "Computer System Organization", ACM Monograph Series
• Index of B8500 documentation
• B5500 Emulation Project – development of a working emulator for the Burroughs B5500 system
• "Burroughs B6500 film & transcript"