1960-70 жылдарғы Burroughs компаниясының негізгі компьютерлерi

Range of mainframe computers in the 1960s and 70s
The Burroughs Large Systems Group produced a family of large 48 bit mainframes using stack machine instruction sets with dense syllables. The first machine in the family was the B5000 in 1961, which was optimized for compiling ALGOL 60 programs extremely well, using single pass compilers. The B5000 evolved into the B5500 (disk rather than drum) and the B5700 (up to four systems running as a cluster). Subsequent major redesigns include the B6500/B6700 line and its successors, as well as the separate B8500 line. In the 1970s, the Burroughs Corporation was organized into three divisions with very different product line architectures for high end, mid range, and entry level business computer systems. Each division's product line grew from a different concept for how to optimize a computer's instruction set for particular programming languages. "Burroughs Large Systems" referred to all of these large system product lines together, in contrast to the COBOL optimized Medium Systems (B2000, B3000, and B4000) or the flexible architecture Small Systems (B1000).

The B5000 was designed to exclusively support high level languages. This was at a time when such languages were just coming to prominence with FORTRAN and then COBOL. FORTRAN and COBOL were considered weaker languages by some, when it comes to modern software techniques, so a newer, mostly untried language was adopted, ALGOL 60. The ALGOL dialect chosen for the B5000 was Elliott ALGOL, first designed and implemented by C. A. R. Hoare on an Elliott 503. This was a practical extension of ALGOL with I/O instructions (which ALGOL had ignored) and powerful string processing instructions. Hoare's famous Turing Award lecture was on this subject. Thus the B5000 was based on a very powerful language. Donald Knuth had previously implemented ALGOL 58 on an earlier Burroughs machine during the three months of his summer break, and he was peripherally involved in the B5000 design as a consultant. Many wrote ALGOL off, mistakenly believing that high level languages could not have the same power as assembler, and thus not realizing ALGOL's potential as a systems programming language. The Burroughs ALGOL compiler was very fast — this impressed the Dutch scientist Edsger Dijkstra when he submitted a program to be compiled at the B5000 Pasadena plant. His deck of cards was compiled almost immediately and he immediately wanted several machines for his university, Eindhoven University of Technology in the Netherlands. The compiler was fast for several reasons, but the primary reason was that it was a one pass compiler. Early computers did not have enough memory to store the source code, so compilers (and even assemblers) usually needed to read the source code more than once. The Burroughs ALGOL syntax, unlike the official language, requires that each variable (or other object) be declared before it is used, so it is feasible to write an ALGOL compiler that reads the data only once. This concept has profound theoretical implications, but it also permits very fast compiling. Burroughs large systems could compile as fast as they could read the source code from the punched cards, and they had the fastest card readers in the industry. The powerful Burroughs COBOL compiler was also a one pass compiler and equally fast. A 4000 card COBOL program compiled as fast as the 1000 card/minute readers could read the code. The program was ready to use as soon as the cards went through the reader.

The B8500 a military computer that was inspired by the B5000. The B8500 was designed in the 1960s as an attempt to merge the B5500 and the D825 designs. The system used monolithic integrated circuits with magnetic thin film memory. The architecture employed a 48 bit word, stack, and descriptors like the B5500, but was not advertised as being upward compatible. in the late 1950s. However, even if those designs had a direct influence on Burroughs, the architectures of the B5000, B6500 and B8500 were very different from those of the Atlas and the Rice machine; they are also very different from each other. The first of the Burroughs large systems was the B5000. Designed in 1961, it was a second generation computer using discrete transistor logic and magnetic core memory, followed by the B5500 and B5700. The first machines to replace the B5000 architecture were the B6500 and B7500. The successor machines to the B6500 and B7500 followed the hardware development trends to re implement the architectures in new logic over the next 25 years, with the B6500, B7500, B6700, B7700, B6800, B7800, B5900, B7900 and finally the Burroughs A series. After a merger in which Burroughs acquired Sperry Corporation and changed its name to Unisys, the company continued to develop new machines based on the MCP CMOS ASIC. These machines were the Libra 100 through the Libra 500, with the Libra 590 being announced in 2005. Later Libras, including the 590, also incorporate Intel Xeon processors and can run the Burroughs large systems architecture in emulation as well as on the MCP CMOS processors. It is unclear if Unisys will continue development of new MCP CMOS ASICs. B5000 1961 initial system, 2nd generation (transistor) computer B5500 1964 3x speed improvement processor. Clearpath HMP NX 4000 1996? ? Clearpath HMP NX 5000 1996? ? Libra 100 2002? ? ? Libra 200 200? ? ? Libra 300 200? ? ? Libra 400 200? ? ? Libra 500 2005? e. g. Libra 595 Libra 600 2006? ? ? Libra 700 2010 e. g. Libra 750

Hardware and software design, development, and manufacturing were split between two primary locations, in Orange County, California, and the outskirts of Philadelphia. The initial Large Systems Plant, which developed the B5000 and B5500, was located in Pasadena, California but moved to City of Industry, California, where it developed the B6500. The Orange County location, which was based in a plant in Mission Viejo, California but at times included facilities in nearby Irvine and Lake Forest, was responsible for the smaller B6x00 line, while the East Coast operations, based in Tredyffrin, Pennsylvania, handled the larger B7x00 line. All machines from both lines were fully object compatible, meaning a program compiled on one could be executed on another. Newer and larger models had instructions which were not supported on older and slower models, but the hardware, when encountering an unrecognized instruction, invoked an operating system function which interpreted it. Other differences include how process switching and I/O were handled, and maintenance and cold starting functionality. Larger systems included hardware process scheduling and more capable input/output modules, and more highly functional maintenance processors. When the Bxx00 models were replaced by the A Series models, the differences were retained but no longer readily identifiable by model number.

The Burroughs large systems implement ALGOL derived stack architectures. The B5000 was the first stack based system. While B5000 was specifically designed to support ALGOL, this was only a starting point. Other business oriented languages such as COBOL were also well supported, most notably by the powerful string operators which were included for the development of fast compilers. The ALGOL used on the B5000 is an extended ALGOL subset. It includes powerful string manipulation instructions but excludes certain ALGOL constructs, notably unspecified formal parameters. A DEFINE mechanism serves a similar purpose to the #defines found in C, but is fully integrated into the language rather than being a preprocessor. The EVENT data type facilitates coordination between processes, and ON FAULT blocks enable handling program faults. The user level of ALGOL does not include many of the insecure constructs needed by the operating system and other system software. Two levels of language extensions provide the additional constructs: ESPOL and NEWP for writing the MCP and closely related software, and DCALGOL and DMALGOL to provide more specific extensions for specific kinds of system software.

Originally, the B5000 MCP operating system was written in an extension of extended ALGOL called ESPOL (Executive Systems Programming Oriented Language). This was replaced in the mid to late 70s by a language called NEWP. Though NEWP probably just meant "New Programming language", legends surround the name. A common (perhaps apocryphal) story within Burroughs at the time suggested it came from "No Executive Washroom Privileges." Another story is that circa 1976, John McClintock of Burroughs (the software engineer developing NEWP) named the language "NEWP" after being asked, yet again, "does it have a name yet": answering "nyoooop", he adopted that as a name. NEWP, too, was a subset ALGOL extension, but it was more secure than ESPOL, and dropped some little used complexities of ALGOL. In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi level protection mechanism. NEWP programs that contain unsafe constructs are initially non executable. The security administrator of a system is able to "bless" such programs and make them executable, but normal users are not able to do this. (Even "privileged users", who normally have essentially root privilege, may be unable to do this depending on the configuration chosen by the site.) While NEWP can be used to write general programs and has a number of features designed for large software projects, it does not support everything ALGOL does. NEWP has a number of facilities to enable large scale software projects, such as the operating system, including named interfaces (functions and data), groups of interfaces, modules, and super modules. Modules group data and functions together, allowing easy access to the data as global within the module. Interfaces allow a module to import and export functions and data. Super modules allow modules to be grouped.

In the original implementation, the system used an attached specialized data communications processor (DCP) to handle the input and output of messages from/to remote devices. This was a 24 bit minicomputer with a conventional register architecture and hardware I/O capability to handle thousands of remote terminals. The DCP and the B6500 communicated by messages in memory, essentially packets in today's terms, and the MCS did the B6500 side processing of those messages. In the early years the DCP did have an assembler (Dacoma), an application program called DCPProgen written in B6500 ALGOL. Later the NDL (Network Definition Language) compiler generated the DCP code and NDF (network definition file). Ultimately, a further update resulted in the development of the NDLII language and compiler which were used in conjunction with the model 4 and 5 DCPs. There was one ALGOL function for each kind of DCP instruction, and if you called that function, then the corresponding DCP instruction bits would be emitted to the output. A DCP program was an ALGOL program comprising nothing but a long list of calls on these functions, one for each assembly language statement. Essentially ALGOL acted like the macro pass of a macro assembler. The first pass was the ALGOL compiler; the second pass was running the resulting program (on the B6500) which would then emit the binary for the DCP. Starting in the early 1980's, the DCP technology was replaced by the ICP (Integrated Communications Processor) which provided LAN based connectivity for the mainframe system. Remote devices, and remote servers/mainframes, were connected to the network via freestanding devices called CP2000s. The CP2000s were designed to provide network node support in a distributed network wherein the nodes were connected using the BNAV2 (Burroughs Network Architecture Version 2) networking technology. BNAV2 was a Burroughs functional equivalent of the IBM SNA product and did support interoperation with IBM environments in both PUT2 and PUT5 transport modes. The change in external datacommunications hardware did not require any change to existing MCS (Message Control System (discussed below)) software. On input, messages were passed from the DCP via an internal bus to the relevant MCP Datacom Control (DCC) DCP process stack. One DCC process was initiated for each DCP configured on the system. The DCP Process stack would then ensure that the inbound message was queued for delivery to the MCS identified to handle traffic from the particular source device and return any response to the DCP for delivery to the destination device. From a processing perspective no changes were required to the MCS software to handle different types of gateway hardware, be it any of the 5 styles of DCP or the ICP or ICP/CP2000 combinations. Apart from being a message delivery service, an MCS is an intermediate level of security between operating system code (in NEWP) and user programs (in ALGOL, or other application languages including COBOL, FORTRAN, and, in later days, JAVA). An MCS may be considered to be a middleware program and is written in DCALGOL (Data Communications ALGOL). As stated above, the MCS received messages from queues maintained by the Datacom Control Stack (DCC) and forwarded these messages to the appropriate application/function for processing. One of the original MCS's was CANDE (Command AND Edit) which was developed as the online program development environment. The University of Otago in New Zealand developed a skinny program development environment equivalent to CANDE which they called SCREAM/6700 in the same time that IBM was offering a remote time sharing/program development service known as CALL/360 which ran on IBM 360 series systems. Another MCS named COMS was introduced around 1984 and developed as a high performance transaction processing control system. There were predecessor transaction processing environments which included GEMCOS (GEneralized Message COntrol System), and an Australian Burroughs subsidiary developed MCS called TPMCS (Transaction Processing MCS). The transaction processing MCS's supported the delivery of application data to online production environments and the return of responses to remote users/devices/systems. MCSs are items of software worth noting – they control user sessions and provide keeping track of user state without having to run per user processes since a single MCS stack can be shared by many users. Load balancing can also be achieved at the MCS level. For example, saying that you want to handle 30 users per stack, in which case if you have 31 to 60 users, you have two stacks, 61 to 90 users, three stacks, etc. This gives B5000 machines a great performance advantage in a server since you don't need to start up another user process and thus create a new stack each time a user attaches to the system. Thus you can efficiently service users (whether they require state or not) with MCSs. MCSs also provide the backbone of large scale transaction processing. Around 1988 an implementation of TCP/IP was developed principally for a U. S. government customer utilizing the CP2000 distributed communications processor as the protocol host. Two to three years later, the TCP/IP implementation was rewritten to be host/server based with significant performance and functionality improvements. In the same general time frame an implementation of the OSI protocol stacks was made, principally on the CP2000, but a large supporting infrastructure was implemented on the main system. All of the OSI standard defined applications were implemented including X.400 mail hosting and X.500 directory services.

Another variant of ALGOL is DMALGOL (Data Management ALGOL). DMALGOL is ALGOL extended for compiling the DMSII database software from database description files created by the DASDL (Data Access and Structure Definition Language) compiler. Database designers and administrators compile database descriptions to generate DMALGOL code tailored for the tables and indexes specified. Administrators never need to write DMALGOL themselves. Normal user level programs obtain database access by using code written in application languages, mainly ALGOL and COBOL, extended with database instructions and transaction processing directives. The most notable feature of DMALGOL is its preprocessing mechanisms to generate code for handling tables and indices. DMALGOL preprocessing includes variables and loops, and can generate names based on compile time variables. This enables tailoring far beyond what can be done by preprocessing facilities which lack loops. DMALGOL is used to provide tailored access routines for DMSII databases. After a database is defined using the Data Access and Structure Definition Language (DASDL), the schema is translated by the preprocessor into tailored DMALGOL access routines and then compiled. This means that, unlike in other DBMS implementations, there is often no need for database specific if/then/else code at run time. In the 1970s, this "tailoring" was used very extensively to reduce the code footprint and execution time. It became much less used in later years, partly because low level fine tuning for memory and speed became less critical, and partly because eliminating the preprocessing made coding simpler and thus enabled more important optimizations. An applications version of ALGOL to support the accessing of databases from application programs is called BDMSALGOL and included verbs like "FIND", "LOCK", "STORE", "GET", and "PUT" for database access and record manipulation. Additionally, the verbs "BEGINTRANSACTION" and "ENDTRANSACTION" were also implemented to solve the deadlock situation when multiple processes accessed and updated the same structures. Roy Guck of Burroughs was one of the main developers of DMSII. In later years, with compiler code size being less of a concern, most of the preprocessing constructs were made available in the user level of ALGOL. Only the unsafe constructs and the direct processing of the database description file remain restricted to DMALGOL.

Procedures can be invoked in four ways – normal, call, process, and run. The normal invocation invokes a procedure in the normal way any language invokes a routine, by suspending the calling routine until the invoked procedure returns. The call mechanism invokes a procedure as a coroutine. Coroutines are partner tasks established as synchronous entities operating in their own stack at the same lexical level as the initiating process. Control is explicitly passed between the initiating process and the coroutine by means of a CONTINUE instruction. The process mechanism invokes a procedure as an asynchronous task with a separate stack set up starting at the lexical level of the processed procedure. As an asynchronous task, there is no control over exactly when control will be passed between the tasks, unlike coroutines. The processed procedure still has access to the enclosing environment and this is a very efficient IPC (Inter Process Communication) mechanism. Since two or more tasks now have access to common variables, the tasks must be synchronized to prevent race conditions, which is handled by the EVENT data type, where processes can WAIT on one, or more, events until it is caused by another cooperating process. EVENTs also allow for mutual exclusion synchronization through the PROCURE and LIBERATE functions. If for any reason the child task dies, the calling task can continue – however, if the parent process dies, then all child processes are automatically terminated. On a machine with more than one processor, the processes may run simultaneously. This EVENT mechanism is a basic enabler for multiprocessing in addition to multitasking.

The last invocation type is run. This runs a procedure as an independent task which can continue on after the originating process terminates. For this reason, the child process cannot access variables in the parent's environment, and all parameters passed to the invoked procedure must be call by value. Thus, Burroughs Extended ALGOL had some of the multi processing and synchronization features of later languages like Ada. It made use of the support for asynchronous processes that was built into the hardware.

One last possibility is that in NEWP a procedure may be declared INLINE, that is when the compiler sees a reference to it the code for the procedure is generated inline to save the overhead of a procedure call; this is best done for small pieces of code. Inline functions are similar to parameterized macros such as C #defines, except you don't get the problems with parameters that you can with macros.

In the example program only normal calls are used, so all the information will be on a single stack. For asynchronous calls, a separate stack is initiated for each asynchronous process so that the processes share data but run asynchronously.

One nice thing about the stack structure is that if a program does happen to fail, a stack dump is taken and it is very easy for a programmer to find out exactly what the state of a running program was. Compare that to core dumps and exchange packages of other systems. Another thing about the stack structure is that programs are implicitly recursive. FORTRAN was not expected to support recursion and perhaps one stumbling block to people's understanding of how ALGOL was to be implemented was how to implement recursion. On the B5000, this was not a problem – in fact, they had the reverse problem, how to stop programs from being recursive. In the end they didn't bother. The Burroughs FORTRAN compiler allowed recursive calls (just as every other FORTRAN compiler does), but unlike many other computers, on a stack based system the returns from such calls succeeded as well. This could have odd effects, as with a system for the formal manipulation of mathematical expressions whose central subroutines repeatedly invoked each other without ever returning: large jobs were ended by stack overflow! Thus Burroughs FORTRAN had better error checking than other contemporary implementation of FORTRAN. For instance, for subroutines and functions it checked that they were invoked with the correct number of parameters, as is normal for ALGOL style compilers. On other computers, such mismatches were common causes of crashes. Similarly with the array bound checking: programs that had been used for years on other systems embarrassingly often would fail when run on a Burroughs system. In fact, Burroughs became known for its superior compilers and implementation of languages, including the object oriented Simula (a superset of ALGOL), and Iverson, the designer of APL declared that the Burroughs implementation of APL was the best he'd seen. John McCarthy, the language designer of LISP disagreed, since LISP was based on modifiable code, he did not like the unmodifiable code of the B5000, but most LISP implementations would run in an interpretive environment anyway. The storage required for the multiple processes came from the system's memory pool as needed. There was no need to do SYSGENs on Burroughs systems as with competing systems in order to preconfigure memory partitions in which to run tasks.

The figure to the left shows how the Burroughs Large System architecture was fundamentally a hardware architecture for object oriented programming, something that still doesn't exist in conventional architectures.

There are three distinct instruction sets for the Burroughs large systems. All three are based on short syllables that fit evenly into words.

Programs on a B5000, B5500 and B5700 are made up of 12 bit syllables, four to a word. The architecture has two modes, Word Mode and Character Mode, and each has a separate repertoire of syllables. A processor may be either Control State or Normal State, and certain syllables are only permissible in Control State. The architecture does not provide for addressing registers or storage directly; all references are through the 1024 word Program Reference Table, current code segment, marked locations within the stack or to the A and B registers holding the top two locations on the stack. Burroughs numbers bits in a syllable from 0 (high bit) to 11 (low bit)

Programs are made up of 8 bit syllables, which may be Name Call, Value Call, or form an operator, which may be from one to twelve syllables in length. There are less than 200 operators, all of which fit into 8 bit syllables. Many of these operators are polymorphic depending on the kind of data being acted on as given by the tag. If we ignore the powerful string scanning, transfer, and edit operators, the basic set is only about 120 operators. If we remove the operators reserved for the operating system such as MVST and HALT, the set of operators commonly used by user level programs is less than 100. The Name Call and Value Call syllables contain address couples; the Operator syllables either use no addresses or use control words and descriptors on the stack.

The direct influence of the B5000 can be seen in the current Unisys ClearPath range of mainframes which are the direct descendants of the B6500, which was influenced by the B5000, and still have the MCP operating system after 40 years of consistent development. This architecture is now called emode (for emulation mode) since the B6500 architecture has been implemented on machines built from Intel Xeon processors running the x86 instruction set as the native instruction set, with code running on those processors emulating the B5000 instruction set. In those machines, there was also going to be an nmode (native mode), but this was dropped, so you may often hear the B6500 successor machines being referred to as "emode machines". B5000 machines were programmed exclusively in high level languages; there is no assembler. The B5000 stack architecture inspired Chuck Moore, the designer of the programming language Forth, who encountered the B5500 while at MIT. In Forth The Early Years, Moore described the influence, noting that Forth's DUP, DROP and SWAP came from the corresponding B5500 instructions (DUPL, DLET, EXCH). B5000 machines with their stack based architecture and tagged memory also heavily influenced the Soviet Elbrus series of mainframes and supercomputers. The first two generations of the series featured tagged memory and stack based CPUs that were programmed only in high level languages. There existed a kind of an assembly language for them, called El 76, but it was more or less a modification of ALGOL 68 and supported structured programming and first class procedures. Later generations of the series, though, switched away from this architecture to the EPIC like VLIW CPUs. The Hewlett Packard designers of the HP 3000 business system had used a B5500 and were greatly impressed by its hardware and software; they aimed to build a 16 bit minicomputer with similar software. Several other HP divisions created similar minicomputer or microprocessor stack machines. Bob Barton's work on reverse Polish notation (RPN) also found its way into HP calculators beginning with the 9100A, and notably the HP 35 and subsequent calculators. The NonStop systems designed by Tandem Computers in the late 1970s and early 1980s were also 16 bit stack machines, influenced by the B5000 indirectly through the HP 3000 connection, as several of the early Tandem engineers were formerly with HP. Around 1990, these systems migrated to MIPS RISC architecture but continued to support execution of stack machine binaries by object code translation or direct emulation. Sometime after 2000, these systems migrated to Itanium architecture and continued to run the legacy stack machine binaries. Bob Barton was also very influential on Alan Kay. Kay was also impressed by the data driven tagged architecture of the B5000 and this influenced his thinking in his developments in object oriented programming and Smalltalk. Another facet of the B5000 architecture was that it was a secure architecture that runs directly on hardware. This technique has descendants in the virtual machines of today in their attempts to provide secure environments. One notable such product is the Java JVM which provides a secure sandbox in which applications run. The value of the hardware architecture binding that existed before emode would be substantially preserved in the x86 based machines to the extent that MCP was the one and only control program, but the support provided by those machines is still inferior to that provided on the machines where the B6500 instruction set is the native instruction set. A little known Intel processor architecture that actually preceded 32 bit implementations of the x86 instruction set, the Intel iAPX 432, would have provided an equivalent physical basis, as it too was essentially an object oriented architecture.