Jump to content

Burroughs B5000

From Alfawiki
Burroughs Large Systems Group
IndustryComputer hardware, Mainframe computers
Founded1961
FounderRobert (Bob) Barton
ProductsB5000, B5500, B5700, B6500, B6700, B7700, B8500 mainframe computers
ParentBurroughs Corporation (later part of Unisys)

The Burroughs Large Systems Group engineered a series of substantial 48-bit mainframe computers characterized by stack machine instruction sets utilizing compact syllables. The pioneering unit, the B5000 (1961), was specifically designed to efficiently compile ALGOL 60 programs through single-pass compilation. This platform subsequently advanced into the B5500, which incorporated disk drives, and then the B5700, capable of supporting clusters of up to four interconnected machines. Subsequent significant redesigns produced the B6500/B6700 series as well as the distinct B8500 line.

During the 1970s, Burroughs Corporation maintained three separate divisions addressing the high-end, mid-range, and entry-level business computing segments, each featuring unique architectures optimized for particular programming languages. The collective term "Burroughs Large Systems" referred to all these high-capacity lines, distinguishing them from the COBOL-oriented Medium Systems (B2000, B3000, B4000) and the versatile Small Systems (B1000).

Background

Established in the 1880s, Burroughs stood as one of the longest-standing companies in continuous computing operations. By the late 1950s, its main products were electromechanical accounting machines such as the Sensimatic, lacking competitive computer models compared to rivals like IBM, NCR, and newer competitors including Univac. In 1956, Burroughs acquired ElectroData Corporation, adopting its design under the name B205.

The internally designed B5000 (1961) represented Burroughs' strategic move to enter the computer market late by embracing innovative architectural principles. While the original B5000 architecture is now outdated, it laid the groundwork for successors including the B6500, B6700, and B7700. Elements of this architecture continue in production within Unisys ClearPath Libra servers running an evolved version of the MCP operating system initially created for the B6700. The third significant product line, the B8500, however, did not achieve commercial success. Over time, Unisys shifted from proprietary CMOS processors to Intel Xeon CPUs for Libra servers, supporting MCP alongside Microsoft Windows and Linux, fully discontinuing custom chips by 2018.

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 for its sophisticated integration of hardware and software design. This model was followed by the B5500, which replaced drum storage with disk drives, and then by the B5700, which allowed multiple CPUs to operate in clusters sharing common disk storage. Although no direct successor followed the B5700, its design influenced later systems such as the B6500, onto which Burroughs migrated the Master Control Program (MCP).

Features

  • Hardware engineered specifically to support high-level programming languages exclusively
  • Streamlined instruction set architecture with no assembly language; system software developed in ESPOL, an extended form of ALGOL 60
  • Partially data-driven design employing a tagged and descriptor-based approach
  • Limited programmer-visible registers; stack machine model where all operations manipulate the stack
  • Management of interrupts and procedure calls entirely through stack mechanisms
  • Compatibility with languages such as COBOL and robust string processing capabilities
  • Automatic code reentrancy, enabling multiprocessing without additional programmer intervention
  • Support for MCP operating system featuring asymmetric multiprocessing with master/slave configurations
  • Early implementation of a secure architecture restricting unauthorized data access
  • Advanced error detection features facilitating software debugging and testing
  • Among the earliest commercial virtual memory systems, second only to the Ferranti Atlas
  • Introduction of one of the first segmented memory models

System architecture

The B5000 series stood out for its architecture and instruction set being crafted around software needs—a marked contrast to the typical approach of the era, where hardware design preceded software development.

In Word Mode, the B5000, B5500, and B5700 implement two addressing modes contingent on the program context (main routine or subroutine). The addressing method depends on the Subroutine Level Flipflop (SALF) status along with other control bits, 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 Address of PRT + T 0-9 A 38-47 1023
ON (T0=OFF) OFF – – R Address of PRT + T 1-9 A 39-47 511
ON (T1=ON, T2=OFF) OFF F Address of last RCW or MSCW on stack + T 2-9 A 40-47 255
ON (T1=ON, T2=OFF) ON (R+7) F register from MSCW at PRT+7 + T 2-9 A 40-47 255
ON (T1=ON, T2=ON) OFF C (current instruction word) + T 3-9 A 41-47 127
ON (T1=ON, T2=ON) ON (MSFF=OFF) F Address of last RCW or MSCW on stack – T 3-9 A 41-47 127
ON (T1=ON, T2=ON) ON (MSFF=ON) (R+7) F register from MSCW at PRT+7 – T 3-9 A 41-47 127

Clarifications:

  • The C operand (current instruction word) is compelled to be relative to R (PRT) for Store, Program, and I/O Release instructions
  • MSCW stands for Mark Stack Control Word
  • MSFF denotes Mark Stack FlipFlop
  • RCW means Return Control Word
  • SALF refers to Subroutine Level Flipflop

Programming language integration

The B5000 was engineered specifically to support high-level programming languages during the emergence of FORTRAN and COBOL. Instead of adopting these early languages, Burroughs chose the more advanced Algol 60#ALGOL-60 dialect, particularly Elliott ALGOL, which was developed by C. A. R. Hoare on an Elliott 503 system. This variant enhanced ALGOL with input/output features and sophisticated string handling.

Donald Knuth acted as a consultant, having previously implemented ALGOL 58 on an earlier Burroughs machine. Although some doubted ALGOL’s capabilities compared to assembler language, the B5000 showcased ALGOL’s suitability for systems-level programming.

Burroughs’ ALGOL compiler gained recognition for its speed, impressing figures such as Edsger Dijkstra, who rapidly adopted the platform at Eindhoven University of Technology. Its efficiency derived from being a one-pass compiler, made possible by requiring all variables to be declared upfront—unlike standard ALGOL—which allowed compilation in a single pass. Burroughs machines matched the throughput of their card readers, among the fastest available at that time.

Similarly, Burroughs’ COBOL compiler also employed a one-pass design, enabling large programs to compile as quickly as punched cards were processed, facilitating immediate program execution.

B6500, B6700/B7700 Series and Later Models

Delivered in 1969, the B6500 and B7500 continued Burroughs’ system evolution still active today. While based on concepts from the B5000, these models introduced significant architectural improvements:

  • Variable-length instructions composed of 8-bit syllables replacing fixed-length 12-bit syllables
  • Expansion to 51-bit words from 48-bit ones, incorporating 3-bit tags for data typing
  • Enhanced support for Symmetric multiprocessing (SMP)
  • Introduction of a new Spaghetti stack#Saguaro stack
  • Implementation of paged arrays for memory management
  • Display Registers (D1 through D32) facilitating access to variables in nested subroutines
  • Integration of monolithic integrated circuits utilizing magnetic thin-film memory

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

The supercomputer ILLIAC IV utilized a B6500 as its I/O control processor responsible for managing supervisory tasks and coordinating memory operations.

B8500

The B8500 series was derived from the D825, a military-grade computer influenced by the B5000 architecture. Developed during the 1960s to combine features of both the B5500 and D825, it employed monolithic integrated circuits alongside magnetic thin-film memory technology. Its design incorporated a 48-bit word size, stack structure, and descriptor mechanisms similar to the B5500; however, it was not promoted as being upward-compatible. The B8500 failed to reach dependable operation and was ultimately discontinued after 1970 without producing a finalized system.

History

The idea of virtual memory first emerged in pioneering systems such as the Ferranti Atlas and the Rice Institute Computer, which also pioneered the use of descriptors and tagged architectures. Although these early machines influenced Burroughs' designs, the architectures of the B5000, B6500, and B8500 differ markedly from those predecessors and from each other.

Burroughs introduced its large-scale computing systems starting with the B5000 in 1961—a second-generation transistor-based machine utilizing magnetic-core memory—followed by enhancements such as the B5500 and B5700. The B6500 and B7500 built upon the B5000 framework by incorporating integrated circuits and enabling multiprocessing. This architectural lineage continued through successive hardware upgrades over a span of 25 years, including models like the B6700, B7700, B6800, B7800, B5900 (which, despite its numbering, was based on the B6500 architecture), B7900, culminating with the A series.

Following Burroughs' merger with Sperry Corporation to form Unisys, development advanced with MCP CMOS ASIC-based systems under the Libra series (100–700). Some models integrated Intel Xeon processors to emulate Burroughs large systems architecture alongside MCP CMOS processors. The trajectory for future MCP CMOS ASIC development remains uncertain.

Burroughs (1961–1986)
B5000 1961 Initial release; second-generation transistor computer
B5500 1964 Tripled processing speed
B6500 1969 Third generation; incorporated integrated circuits; supported up to four processors
B5700 1971 Rebranded version of the B5500
B6700 1971 Updated/bug-fixed variant of the B6500
B7700 1972 Enhanced processor speed; stack caching; supported up to eight requestors in partitions
B6800 circa 1977 Introduced semiconductor memory; NUMA architecture implemented
B7800 circa 1977 Faster with semiconductor memory; supported up to eight requestors
B6900 circa 1979 Semiconductor memory; NUMA design; maximum of four CPUs linked to local and global memory
B5900 1981 Semiconductor memory; NUMA; max four CPUs connected to local/global memory (second generation)
B7900 circa 1982 Semiconductor memory; increased speed; caching; NUMA; flexible CPU-memory bindings
A9/A10 1984 Mid-range pipelined processors; single or dual CPU configurations; supports expanded memory addressing (eMode Beta)
A12/A15 1985 Redesigned using custom Motorola ECL gate arrays; single/multi CPU and HDU configurations available
Unisys (1986–present)
Micro A 1989 Desktop mainframe featuring a single-chip SCAMP processor
Clearpath HMP NX 4000 circa 1996 Specific mainframe details not clearly documented
Clearpath HMP NX 5000 circa 1996 Mainframe model details remain unspecified
Clearpath HMP LX 5000 1998 Emulates Burroughs large systems on Intel Xeon processors
Libra 100 Early 2000s Details not specified
Libra 200 Early 2000s Details not specified
Libra 300 Early 2000s Details not specified
Libra 400 Early 2000s Details not specified
Libra 500 circa 2005 Includes Libra 595 variant
Libra 600 Mid-2000s Details not specified
Libra 700 2010 Features Libra 750 model with enhanced application support and mobile device compatibility


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 the other near Philadelphia. The original Large Systems Plant, responsible for creating the B5000 and B5500 models, was initially located in Pasadena, California before moving to City of Industry, California to work on the B6500. The Orange County facility, centered in Mission Viejo, California and at times including locations in Irvine and Lake Forest, focused on the smaller B6x00 series. On the East Coast, operations based in Tredyffrin, Pennsylvania managed the larger B7x00 lineup.

All systems across these product lines maintained full object compatibility, enabling software compiled on one machine to execute seamlessly on another. While newer models introduced instructions absent from older versions, these were handled through operating system interpretation. Variations also appeared in areas such as process switching, input/output management, maintenance procedures, and cold-start capabilities. Larger systems incorporated hardware-level process scheduling, sophisticated I/O modules, and enhanced maintenance processors. Even after the transition from the Bxx00 series to the A Series models, these differences remained present though they no longer corresponded directly to model identifiers.

ALGOL

Burroughs’ large-scale systems utilized ALGOL-based stack architectures, with the B5000 marking the first implementation of a stack-oriented computer. Although primarily designed to support ALGOL programming, these platforms also effectively accommodated business languages like COBOL by employing powerful string manipulation operators that facilitated efficient compiler construction.

The Burroughs version of ALGOL extended the standard language with advanced string handling features while omitting certain elements such as unspecified formal parameters. It incorporated a DEFINE mechanism embedded within the language (comparable to C’s #define directive), an EVENT data type for coordinating processes, and ON FAULT blocks for managing exceptions.

At the user level, ALGOL excluded unsafe constructs required by system software; these were instead provided through language extensions such as ESPOL and NEWP for MCP development, along with DCALGOL and DMALGOL tailored for specialized system programming tasks.

ESPOL and NEWP

The Master Control Program (MCP) operating system on the B5000 was originally implemented in ESPOL (Executive Systems Programming Oriented Language), an extended superset of ALGOL 60 designed specifically for system programming on Burroughs’ large multiprocessor systems. ESPOL supported low-level functionalities like processor interrupts and was employed across Burroughs systems ranging from the B5000 through the B6700. Its single-pass compiler was capable of compiling in excess of 250 lines per second.

During the mid to late 1970s, ESPOL was succeeded by NEWP, a more secure extension of ALGOL that eliminated infrequently used language features. NEWP enhances security by disallowing unsafe constructs unless explicitly authorized; this facilitates multi-level protection schemes. Programs containing unsafe code must be approved by a security administrator prior to execution, imposing restrictions even on privileged users depending on organizational policies.

NEWP was architected to support large-scale software projects by providing named interfaces (for functions and data), collections of interfaces, modules, and super-modules. Modules encapsulate data along with associated functions while controlling access through interfaces; super-modules group multiple modules to improve project organization. Although NEWP offers extensive project management capabilities, it does not implement every aspect of ALGOL fully.

DCALGOL and Message Control Systems (MCS)

Initially, message input and output from remote devices were managed by a dedicated data communications processor (DCP), a 24-bit minicomputer. Communication between the DCP and the B6500 occurred through memory messages, with the MCS responsible for processing on the B6500 side. Early development tools comprised the DCP assembler (Dacoma) and DCPProgen implemented in B6500 ALGOL. Subsequently, the Network Definition Language (NDL) compiler was introduced to produce both DCP code and network definition files, later evolving into NDLII to support model 4 and 5 DCPs. The ALGOL functions mirrored DCP instructions, effectively functioning as a macro assembler: compiling ALGOL resulted in programs that generated DCP executable binaries.

During the early 1980s, the DCP was supplanted by the Integrated Communications Processor (ICP), which facilitated LAN connectivity for mainframe systems. Remote devices connected through CP2000 nodes utilizing BNAV2 networking technology—Burroughs' counterpart to IBM's SNA—allowing compatibility with IBM environments. This hardware transition did not necessitate modifications to existing MCS software.

Inbound messages traveled from the DCP via internal buses to MCP Datacom Control (DCC) stacks—one stack per configured DCP. Each stack queued incoming messages for delivery to the corresponding MCS and returned responses to originating devices. The MCS software remained uniform across various gateway hardware platforms including DCPs, ICPs, and CP2000 units.

In addition to message routing, MCS functioned as middleware bridging operating system code (NEWP) with user applications coded in DCALGOL, ALGOL, COBOL, FORTRAN, and later JAVA. It retrieved messages from DCC queues and directed them to application routines. Prominent MCS implementations included CANDE (Command AND Edit), an interactive program development environment; SCREAM/6700 developed at the University of Otago; and COMS, introduced around 1984 as a high-performance transaction processing system. Earlier systems such as GEMCOS and TPMCS—created by an Australian Burroughs affiliate—preceded these solutions. These transaction processing MCSs enabled efficient data delivery and response management within online production settings.

MCS software played a critical role in managing user sessions and maintaining state without spawning individual processes per user. This facilitated effective load distribution by assigning users across multiple stacks—for example, supporting approximately 30 users per stack with near-linear scalability. Such architecture provided B5000 machines with performance benefits as servers by eliminating per-session process overhead, thereby supporting large-scale transaction workloads efficiently.

By 1988, a TCP/IP implementation was developed primarily for a U.S. government client utilizing CP2000 as the protocol host. This was later restructured into a host/server architecture featuring improved performance and additional capabilities. Simultaneously, OSI protocol stacks were deployed predominantly on CP2000 hardware with comprehensive mainframe integration, including X.400 email services and X.500 directory functionality, completing the suite of OSI-compliant applications.

DMALGOL and databases

DMALGOL (Data Management ALGOL) represents an ALGOL dialect extended to compile DMSII database software from database description files produced by the DASDL (Data Access and Structure Definition Language) compiler. Database architects compile these descriptions to generate DMALGOL source code customized for specific tables and indexes, eliminating the need for manual DMALGOL coding by administrators. Application programs access databases primarily through ALGOL and COBOL enhanced with database-specific instructions and transaction control statements. A defining characteristic of DMALGOL is its preprocessing capabilities designed to generate code managing tables and indexes.

This preprocessing supports variables, iteration constructs, and compile-time identifier generation, enabling more sophisticated customization than conventional preprocessors. DMALGOL delivers tailored access routines for DMSII databases; once a database is defined via DASDL, its schema is transformed into specialized DMALGOL routines that are then compiled. This method frequently obviates runtime conditional code tied to database specifics. In the 1970s, such customization significantly reduced both code size and execution duration but waned in importance as memory constraints eased and simplicity in coding gained priority.

A variant known as BDMSALGOL offers commands such as "FIND," "LOCK," "STORE," "GET," and "PUT" for database interactions along with "BEGINTRANSACTION" and "ENDTRANSACTION" statements designed to handle deadlock situations during concurrent access. Roy Guck of Burroughs was a key contributor to DMSII development.

As concerns about compiler footprint diminished over time, most preprocessing features became accessible directly at the ALGOL user level; only unsafe constructs and direct processing of database description files remain exclusive functionalities of DMALGOL.

Stack Architecture

Earlier computing systems tended to avoid small subroutines because of the high overhead associated with procedure calls and managing the stack. The B5000, however, was engineered as a stack-based machine, storing all program data—except arrays, including strings and objects—directly on the stack, thereby optimizing stack operations for greater efficiency. As a machine centered around stack usage, it does not provide registers that programmers can access directly.

Multitasking on the B5000 and its successors in the B6500 family is highly streamlined, facilitated by dedicated instructions designed for switching processes:

For B5000, B5500, and B5700 models
Initiate P1 (IP1) and Initiate P2 (IP2)
For B6500, B7500, and later versions
MVST (move stack)

Each process—whether a task or thread—is represented by a stack paired with its Program Reference Table (PRT). Processes may become blocked if they await resources or processor allocation when preempted. Importantly, user-level programs are prohibited from executing IP1, IP2, or MVST instructions; these commands are exclusively reserved for operating system use.

Process switching is triggered either by a process requesting an unavailable resource or when an interrupt arises. In such cases, the operating system operates on the user’s stack, disables user timers, places the current process into an appropriate queue, selects the next eligible process to run, and uses move_stack to activate that process.

Stack Speed and Performance

Historically, stack-oriented architectures were perceived as slower than register-based designs, a factor contributing to IBM’s decision against adopting such an architecture for the System/360. To improve speed, the B5000 designated the top two positions of the stack as registers A and B, allowing most operations to execute close to the processor core. Later models following the B5000 enhanced performance further by retaining larger portions of the stack within registers or cache memory. This approach enables software to execute faster without requiring recompilation, thereby safeguarding software investments across multiple hardware generations. This contrasts with register-based systems where performance gains often necessitate code modifications.

Proponents of RISC argued that integrating processors onto a single chip increases speed—a valid observation during the 1970s when complex designs like the B5000 could not be condensed into one chip. In contrast, all successors of the B5000 now fit on a single integrated circuit featuring modern enhancements such as caches and pipelines. Notably, in the late 1980s, the A Series introduced the Micro-A processor—the first single-chip mainframe processor (SCAMP)—implemented on an Intel-compatible plug-in board.

Program Mapping to the Stack

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

begin
   — Lexical level 2 contains 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;  — assigns value to g
         p1 := r2;  — modifies local copy of p1
         
         if r2 > 10 then
            begin
               — Lexical level 4 block:
               integer n;
               ... <== sample stack execution point
            end;
      end;
      
   .....
   
   p (f, g);
end.

Each frame on the stack corresponds to a lexical nesting level representing static program structure rather than dynamic call depth. ALGOL’s scope rules require forward declarations and permit inner blocks to overshadow outer variables with identical names. Although the B5000 architecture supports up to 32 nesting levels, practical programming rarely goes beyond five due to considerations of code clarity and maintainability. Excessive nesting can pose difficulties for systems that automatically generate Algol source code for specialized applications.

Procedures

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

The normal method halts the execution of the calling routine until the procedure completes, functioning similarly to conventional routine invocations.

Using the call approach, a procedure is executed as a coroutine—these are paired tasks running synchronously with their own individual stacks at the same lexical depth. Control transfer occurs explicitly via a CONTINUE command.

The process invocation launches a procedure as an asynchronous task possessing a separate stack at its lexical level. Unlike coroutines, the timing of control transfer is nondeterministic. This procedure can interact with its surrounding environment, facilitating efficient interprocess communication (IPC). When variables are shared, synchronization is necessary to avoid race conditions; this is managed through the EVENT data type. Processes can WAIT on events initiated by cooperating tasks, and EVENTs provide mutual exclusion using PROCURE and LIBERATE operations. If a child task fails, its parent remains unaffected; however, if the parent terminates, all child processes are also ended. On systems with multiple processors, processes may execute concurrently. This EVENT-based system forms the foundation for multiprocessing alongside multitasking.

Run invocation type

The run invocation starts a procedure as a fully independent task that continues execution even after the original process has terminated. Due to this autonomy, the child task cannot access the parent’s variables; therefore, all arguments must be passed by value.

Burroughs Extended ALGOL integrated multiprocessing and synchronization capabilities similar to those found in later languages such as Ada, utilizing hardware support for asynchronous processing.

Inline procedures

Within NEWP, procedures can be declared as INLINE, prompting the compiler to embed code directly at the call site to eliminate procedure call overhead—this is especially effective for small code fragments. Inline functions behave like parameterized macros (for example, C #defines) but avoid common macro-related parameter pitfalls.

Asynchronous calls

The sample program employs only normal calls using a single stack. In contrast, asynchronous calls create separate stacks for each process, permitting concurrent execution alongside shared data access.

Display registers

A significant hardware optimization involves D (or "display") registers that correspond directly to lexical scope levels in source code. These 32 registers point to the base of each active stack frame and are automatically maintained by the MCP during procedure invocations. This design limits lexical nesting to 32 levels.

Without D registers, accessing variables at outer lexical scopes demands traversing multiple stack frames via control words—a process that is inefficient. With D registers, the register for a specific lexical level directly references the frame base, enabling rapid address calculation by adding variable offsets. This mechanism allows access to outer and global variables with efficiency comparable to local ones.

When procedures are invoked as coroutines or processes, each maintains a separate stack environment linked through D registers. This arrangement permits asynchronous tasks to share environments as indicated in ALGOL source code. Cross-stack calls enable different programs to invoke one another’s routines, fostering interoperability among languages and compilers—this underlies library call functionality.

The D[1] register corresponds to the shared code segment dictionary, while D[0] represents operating system exports. Stack frames are not confined solely to process stacks; early file I/O optimizations attached file information blocks at D[1]. Subsequent language enhancements such as STRUCTURE BLOCKs and CONNECTION BLOCKs utilized this facility to implement object-oriented features—demonstrating that the B6500 architecture supported object-oriented paradigms well before they became widespread concepts.

Unlike architectures relying on flat memory addressing prone to corruption, this hardware-enforced two-part addressing scheme locates variables at offsets within lexical-level stack frames—typically one word per variable—with arrays represented solely by descriptors. Addressing employs compact instructions like VALC featuring 14-bit fields combining lexical level and offset information, optimizing both memory usage and instruction size.

Importantly, this design significantly improved system reliability: tasks cannot corrupt memory beyond their allocated scope because addressing is confined and validated by hardware against stack boundaries. Array descriptors enforce hardware-level bounds checking, while memory tagging prevents improper assignments to pointers or executable code areas. This robust architecture provided strong safeguards against common memory errors in multitasking environments.

Array Storage

Arrays were assigned distinct address spaces accessed through descriptors. Index variables, capable of spanning the entire integer range, functioned as offsets within these spaces, with hardware-enforced boundary checks. By default, arrays larger than 1,024 words were segmented, transforming the index into a segment and offset pair; declaring arrays with the LONG attribute bypassed this segmentation. For multidimensional ALGOL arrays, nested descriptors represented each dimension, ensuring bounds verification for every index.

Conversely, FORTRAN managed multidimensional arrays as flattened one-dimensional sequences, computing offsets using straightforward arithmetic operations. While access beyond array limits was blocked, individual index validation was not performed, potentially leading to subtle indexing mistakes.

The use of non-contiguous storage facilitated dynamic resizing of arrays, though altering dimensions was restricted by compiler limitations. ALGOL accommodated "ragged" arrays wherein rows could vary in length, enhancing efficiency for sparse data by tailoring row sizes to contain only non-zero elements.

Segmentation contributed to improved memory utilization: slightly increasing an array's size beyond 1,024 words minimized thrashing by loading only required segments. Segments were allocated dynamically at runtime upon access and initialized to zero; therefore, omitting zero-initialization was generally discouraged.

Array equivalencing permitted multiple interpretations of the same memory region. Declaring an ARRAY allocated 48-bit words typically interpreted as REAL numbers. Through equivalence declarations, these could be viewed as EBCDIC, HEX, or ASCII character arrays without additional memory allocation. Data type–specific arrays (e.g., EBCDIC ARRAY) could also be directly declared, with allocations rounded to word boundaries.

During compilation, Data Descriptors were generated to indicate the intended data types; equivalence declarations produced copy descriptors that referenced original descriptors to maintain correct indexing.

BOOLEAN and INTEGER arrays were supported and could serve as bit vectors. These array capabilities applied uniformly across ALGOL, COBOL, and FORTRAN syntax variants.

Advantages of the Stack Structure

The stack architecture simplifies debugging by producing stack dumps upon program failures, facilitating easier diagnosis of program state compared to core dumps used in other systems.

Programs running on the B5000 inherently supported recursion, unlike early FORTRAN implementations. The Burroughs FORTRAN compiler reliably handled recursion with successful returns on the stack-based system. However, this occasionally led to stack overflow in programs exhibiting infinite recursive calls.

Burroughs FORTRAN provided enhanced error checking by verifying parameter counts and array bounds—common sources of crashes on alternative platforms. Burroughs gained a reputation for advanced compilers and language implementations, including object-oriented Simula. Iverson, creator of APL, regarded Burroughs' APL implementation as the finest he had encountered. Although John McCarthy favored LISP’s modifiable code model over the B5000’s fixed approach, most LISP implementations operated interpretively regardless.

Memory allocation for multiple processes was dynamically managed from a shared system pool, removing the necessity for predefined memory partitions (SYSGEN) required by competing systems.

Tagged architecture

The B5000 is characterized by its stack machine design combined with a tag-based, descriptor-oriented architecture.

Initially, a single flag bit distinguished control words from numeric ones, preventing control word corruption on the stack and enhancing system security.

This concept was further developed in the B6500, which introduced a 3-bit tag (bits 48–50) positioned outside the 48-bit word. Bit 48 served as a read-only indicator, while odd-numbered tags identified control words safeguarded against user alterations. Tag 3 was reserved for code words. Important tags include:

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 segments
SCW Software Control Word for stack management
1 IRW Indirect Reference Word
SIRW Stuffed Indirect Reference Word
3 Code Program code words and stack control elements (MSCW, RCW, TOSCW)
SD Segment Descriptor
5 Descriptor Descriptors for data blocks
7 PCW Program Control Word marking procedure entry points

Certain systems internally used 60-bit words to facilitate error correction, though these specifics were abstracted away from the programmer.

Unisys ClearPath platforms expanded the tag size to four bits within microcode ("level Gamma").

Even-numbered tags denote user-modifiable data, whereas odd tags correspond to hardware-controlled execution state words. This approach allows hardware implementations to evolve without requiring recompilation of existing user programs.

Tag 1 IRWs refer to data on the stack; SIRWs extend referencing capabilities across multiple stacks, enabling inter-process communication through CALL and PROCESS commands.

Descriptors labeled with tag 5 reference off-stack data blocks, which are elaborated upon in the following section.

Tag 7 PCWs indicate procedure entry locations; hardware operators initiate procedures upon encountering these PCWs. For routines that do not return values, explicit ENTR instructions are used; functions are invoked implicitly by value call operators. Shared global routines reside in code segment dictionaries accessed via SIRWs, supporting reentrant and shared code execution.

Tag 3 identifies both code words and stack control constructs but does not appear on the stack during program execution.


Descriptor-based architecture

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


Instruction sets

Burroughs large-scale systems employ three separate instruction sets, each based on concise syllables that align evenly within word boundaries.

B5000, B5500 and B5700

These systems utilize 12-bit syllables, with four syllables fitting into a single word. The architecture accommodates both Word Mode and Character Mode, each featuring its own syllable repertoire. Processors operate in either Control or Normal State; some syllables are exclusively executable in Control State. Addressing is indirect through a Program Reference Table containing 1024 entries, code segments, stack locations, or registers holding the uppermost stack items.

B6500 and successors

Programs operate using 8-bit syllables that represent Name Calls, Value Calls, or operators spanning from one to twelve syllables. The total number of operators is under 200, with many exhibiting polymorphism depending on data tags. When excluding specialized string and OS-reserved operators, typical user-level programs utilize fewer than 100 operators. Addressing mechanisms rely on address couples or stack descriptors.

Multiple processors

The B5000 series introduced the concept of dual-processor setups employing a master-slave arrangement. Subsequent models such as the B6000, B7000, and B8000 advanced to symmetric multiprocessing architectures capable of supporting up to eight processors, including I/O units. Synchronization at the hardware level is managed through the RDLK (ReaD with LocK) operator, which executes atomically within a single cycle. At a higher abstraction, synchronization is facilitated via the EVENT data type, although this method introduces system overhead. To minimize this overhead, Dahm locks are implemented through the ALGOL READLOCK statement, which compiles into efficient RDLK instructions for locking purposes.

Primary processor operators include:

  • HEYU — issues an interrupt to another processor
  • RDLK — a low-level semaphore operator that enables atomic load-store operations; utilized by the ALGOL compiler to perform atomic swaps (for example, x:=RDLK(x,y);)
  • WHOI — retrieves the processor’s identification
  • IDLE — waits idly until an interrupt is received

Occasionally, simultaneous HEYU commands exchanged between two processors could trigger a deadlock condition referred to as a 'deadly embrace.'

Influence of the B5000

The direct heritage of the B5000 persists in Unisys ClearPath mainframes, which descend from the B6500—a system itself influenced by the B5000. These platforms continue running the MCP operating system after more than four decades of continuous development. This architecture, now termed emode (emulation mode), operates on Intel Xeon CPUs utilizing the x86 instruction set while emulating the original B5000 instruction set. Although there were plans for a native mode (nmode), it was ultimately abandoned; thus, these systems are commonly known as "emode machines."

Programming on B5000 systems was conducted exclusively in high-level languages without any assembler involvement.

The stack-based design of the B5000 inspired Chuck Moore—the creator of the Forth language—who encountered the B5500 during his time at MIT. Moore credited Forth’s DUP, DROP, and SWAP commands as adaptations of corresponding instructions from the B5500.

Additionally, the B5000’s tagged memory and stack-oriented architecture influenced the Soviet Elbrus mainframe and supercomputer line. Early Elbrus models incorporated tagged memory and stack CPUs programmed solely in high-level languages using El-76, a structured language derived from ALGOL 68. Later iterations shifted toward EPIC-style VLIW CPU architectures.

Engineers at Hewlett-Packard working on the HP 3000 business system admired both hardware and software aspects of the B5500, motivating them to develop a 16-bit minicomputer with comparable software features. Other HP divisions also produced stack-based minicomputers and microprocessors inspired by this design. Bob Barton’s innovations in reverse Polish notation (RPN) significantly influenced HP calculators starting with the 9100A model and notably the HP-35.

During the late 1970s and early 1980s, Tandem Computers’ NonStop systems were implemented as 16-bit stack machines indirectly shaped by B5000 concepts through HP connections. These systems transitioned to MIPS RISC architectures around 1990 but maintained compatibility with stack machine binaries via translation or emulation layers. Post-2000 developments saw migration to Itanium processors while continuing legacy binary support.

Bob Barton’s work also impacted Alan Kay, whose exposure to the data-driven tagged architecture of the B5000 informed his contributions to object-oriented programming and Smalltalk.

The B5000 introduced a secure hardware-bound architectural model that has evolved into present-day virtual machines such as Java’s JVM, which offers secure application sandboxing environments.

While MCP remains the exclusive control program on x86-based emode machines, optimal support exists on platforms where the B6500 instruction set runs natively. The Intel iAPX 432 processor architecture—a relatively obscure predecessor to 32-bit x86—provided a similarly object-oriented hardware foundation.

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

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