| Burroughs Large Systems |
Article Index for Burroughs |
Website Links For Burroughs |
Information AboutBurroughs Large Systems |
| CATEGORIES ABOUT BURROUGHS LARGE SYSTEMS | |
| early computers | |
| mainframe computers | |
|
1973.'']] B5000 The first member of the series, the B5000, was designed beginning in 1961 by a team under the leadership of Robert (Bob) Barton . It was a unique machine, well ahead of its time. It has been listed by the influential computer architect John Mashey as one of the architectures that he admires the most. "I always thought it was one of the most innovative examples of combined hardware/software design I've seen, and far ahead of its time." UNIQUE FEATURES
In the following discussion, the machine designations, B5000, A Series, and ClearPath/MCP are used interchangeably although this needlessly conflates the features and concepts of the various machines and should be edited someday to keep clear the distinctions between the 5000, 5500, 6500 et seq, and A Series. Unique system design The B5000 was revolutionary at the time in that the architecture and instruction set were designed with the needs of software taken into consideration. This was a large departure from the computer system design of the time, where a processor and its instruction set would be designed and then handed over to the software people, and is still. That is modern architectures such as PPC or iAPXx86 are essentially tradional instruction set based architectures rather than holistic designs like the original Burroughs systems. Language support 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 are both deficient languages 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 Elliot 503. This was a practical extension of ALGOL with IO instructions (which ALGOL had ignored) and powerful string processing instructions. Hoare's famous Turing lecture was on this subject. Thus the B5000 was based on a very powerful language. Most other vendors could only dream of implementing an ALGOL compiler and most in the industry dismissed ALGOL as being unimplementable. However, a bright young student named Donald Knuth had previously implemented ALGOL-58 on an earlier Burroughs machine during the three months of his summer break. 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, an opinion not revised until the development of the C Programming Language . The Burroughs ALGOL compiler was extremely fast — this impressed 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 back in Europe. 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 ALGOL syntax 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 extremely fast compilation. Burroughs large systems could compile as fast as they could read the source code from the Punched Card s, and they had the fastest card readers in the industry. HISTORY 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 . The successor machines followed the hardware development trends to re-implenent the architecture in new logic over the next 25 years, with the B5500, B6500, B5700, B6700, B7700, B6800, B7800, and finally the Burroughs A series. After Burroughs Became part of Unisys, Unisys 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. ALGOL The Burroughs large systems implement an ALGOL Stack Architecture , unlike linear architectures such as PDP-11 , Motorola M68k , and Itanium or segmented architectures such as X86 and Texas Instruments . While B5000 was designed specifically around 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 actually an extended ALGOL, which includes powerful string manipulation instructions. It also has an elegant preprocessing DEFINE mechanism which is much neater than the #defines found in C. Another extension of note is the EVENT data type facilitating coordination between processes and integrated with INTERRUPTs which may be attached to events to handle them. Thus an interrupt can be coded as an ALGOL code block in order to handle exceptions such as numeric overflow and other user defined EVENTs. The user-level of ALGOL does not include many of the more dangerous facilities needed by the operating system. There are two levels of more powerful facilities not required in the normal user level of algorithmic processing. The first level is writing the operating system. ESPOL and NEWP 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; it is not clear what the name of this language originally stood for, although a common (perhaps apocryphal) story around Burroughs at the time suggested it came from “''No Executive Washroom Privileges''.” Circa 1976, Bob Jardine of Burroughs allegedly named the language "NEWP" after being asked, yet again, "does it have a name yet" ... and answering "noooop", he adopted that as a name. NEWP, too, was an ALGOL extension, but it was more secure than ESPOL. 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 (even privileged users) are not able to do this. 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 code control features beyond that of ALGOL, such as INLINE procedures. This feature goes beyond Algol’s DEFINE and allows short logical constructs to be logically defined as procedures, but physically be generated as in-line codestreams. This aids both program comprehensibility and code efficiency. 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. DCALGOL and Message Control Systems (MCS) The second intermediate level of security between operating system code (in NEWP) and user programs (in ALGOL) is for middleware programs, which are written in DCALGOL (data comms ALGOL). This is used for message reception and dispatching which remove messages from input queues and places them on queues for other processes in the system to handle. Middleware such as COMS (introduced around 1984) receive messages from around the network and dispatch these messages to specific handling processes or to an MCS (Message Control System) such as CANDE ("Compile '''AND E'''dit," the program development environment). 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. DMALGOL and databases Another variant of ALGOL is also worth noting – DMALGOL (Data Management ALGOL). DMALGOL is a language extended for compiling Database System s and for generating code from database descriptions. 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 languages such as ALGOL, COBOL and others, extended with database instructions and transaction processing directives. The most notable feature of DMALGOL is that, on top of ALGOL's elegant define mechanism already mentioned, DMALGOL has an even more sophisticated preprocessing mechanism to generate code for handling tables and indexes. DMALGOL has extensive preprocessing, allowing fairly sophisticated programs to be written/executed, just in the preprocessing phase. 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. Roy Guck of Burroughs was one of the main developers of DMSII . STACK ARCHITECTURE In many early systems and languages, programmers were often told not to make their routines too small – because procedure calls and returns were expensive operations, a number of operations had to be performed to maintain the stack. The B5000 was designed as a stack machine – all program data except for arrays (which include strings and objects) was kept on the stack. This meant that stack operations were optimized for efficiency. As a stack-oriented machine, there are no programmer addressable registers. Note: Internally, some of the machines had 60 bit words, with the extra bits being used for engineering purposes such as a Hamming Code error-correction field, but these were never seen by programmers. Note: The current incarnation of these machines, the Unisys ClearPath has extended tags further into a four bit tag. The microcode level that specified four bit tags was referred to as level Gamma. Even-tagged words are user data which can be modified by a user program as user state. Odd-tagged words are created and used directly by the hardware and represent a program's execution state. Since these words are created and consumed by specific instructions or the hardware, the exact format of these words can change between hardware implementation and user programs do not need to be recompiled, since the same code stream will produce the same results, even though system word format may have changed. Tag 1 words represent on-stack data addresses. The normal IRW simply stores an address couple to data on the current stack. The SIRW references data on any stack by including a stack number in the address. Tag 5 words are descriptors, which are more fully described in the next section. Tag 5 words represent off-stack data addresses. Tag 7 is the program control word which describes a procedure entry point. When operators hit a PCW, the procedure is entered. The ENTR operator explicitly enters a procedure (non-value-returning routine). Functions (value-returning routines) are implicitly entered by operators such as value call (VALC). Note that global routines are stored in the D environment as SIRWs that point to a PCW stored in the code segment dictionary in the D[1 environment. The D[1] environment is not stored on the current stack because it can be referenced by all processes sharing this code. Thus code is reentrant and shared. Tag 3 represents code words themselves, which won't occur on the stack. Tag 3 is also used for the stack control words MSCW, RCW, TOSCW. 1973.'']] DESCRIPTOR-BASED ARCHITECTURE The figure to the left shows how the Burroughs Large System architecture was fundamentally a hardware architecture for OOP , something that still doesn't exist in conventional architectures. See Also: Descriptors in Burroughs large systems INSTRUCTION SET See Also: Burroughs large systems instruction set (See also ) MULTIPLE PROCESSORS The B5000 line also were pioneers in having multiple processors connected together on a high-speed bus. The B7000 line could have up to 8 processors, as long as at least one was an IO module. Note that RDLK is a very low-level way of synchronizing between processors. The high level used by user programs is the EVENT data type. The EVENT data type did have some system overhead. To avoid this overhead, a special locking technique called Dahm locks (named after a Burroughs software guru, Dave Dahm) can be used. Notable operators are: HEYU — send an interrupt to another processor RDLK — Low-level semaphore operator: Load the A register with the memory location given by the A register and place the value in the B register at that memory location in a single uninterruptible cycle WHOI — Processor identification IDLE — Idle until an interrupt is received INFLUENCE OF THE B5000 Undoubtedly, the direct influence of the B5000 is the current Unisys ClearPath range of mainframes which are the direct descendants of 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 B5000 architecture can be implemented on many platforms. There was also going to be an nmode ( Native Mode ), but this was dropped, so you may often hear the B5000 successor machines being referred to as "emode machines". B5000 machines were programmed exclusively in high-level languages, there is no assembler, obviously this would not apply to emode which is intended to run on stock hardware and thus breaks the fundamental basis of the architecture noted above except as noted below. 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). Hewlett Packard systems were influenced by the B5000, since some Burroughs engineers found later employment designing machines for HP and these also were stack machines. Bob Barton's work on Reverse Polish Notation (RPN) found its way into HP Calculators beginning with the 9100A, and notably the HP-35 and subsequent calculators. 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 prior to emmode would be substantially preserved in iAPXx86 to the extent that MCP was the one and only control program but the support provided by stock hardwares is still inferior to that of the native mode. A little known Intel processor architecture that actually preceeded iAPXx86 ''would'' have provided ( Intel IAPX 432 ) an equivalent physical basis as it too was essentially an object oriented dataflow architecture. SEE ALSO NOTES REFERENCES
EXTERNAL LINKS |
|
|