Burroughs Large Systems
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.
Computers using that architecture were[citation needed] still in production as the Unisys ClearPath Libra servers which run an evolved but compatible version of the MCP operating system first introduced with the B6700.
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.
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,[NB 4] 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.
Hardware and software design, development, and manufacturing were split between two primary locations, in Orange County, California, and the outskirts of Philadelphia.
Larger systems included hardware process scheduling and more capable input/output modules, and more highly functional maintenance processors.
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.
It includes powerful string manipulation instructions but excludes certain ALGOL constructs, notably unspecified formal parameters.
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.
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.
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.
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).
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.
Additionally, the verbs "BEGINTRANSACTION" and "ENDTRANSACTION" were also implemented to solve the deadlock situation when multiple processes accessed and updated the same structures.
Thus the designers of the current successors to the B5000 systems can optimize in whatever is the latest technique, and programmers do not have to adjust their code for it to run faster – they do not even need to recompile, thus protecting software investment.
However, this is not the case today and every B5000 successor machine now fits on a single chip as well as the performance support techniques such as caches and instruction pipelines.
Coroutines are partner tasks established as synchronous entities operating in their own stack at the same lexical level as the initiating process.
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.
On other systems, the compiler might build its symbol table in a similar manner, but eventually the storage requirements would be collated and the machine code would be written to use flat memory addresses of 16-bits or 32-bits or even 64-bits.
The address part of the VALC operation thus reserved just three bits for that purpose, with the remainder being available for referring to entities at that and lower levels.
Much more important is that this method meant that many errors possible on systems employing flat addressing could not occur because they were simply unspeakable even at the machine code level.
In any case, the tagging of all memory words provided a second level of protection: a misdirected assignment of a value could only go to a data-holding location, not to one holding a pointer or an array descriptor, etc.
The access mechanism was to calculate on the stack the index variable (which therefore had the full integer range potential, not just fourteen bits) and use it as the offset into the array's address space, with bound checking provided by the hardware.
The immediately preceding discussion uses the ALGOL syntax implementation to describe ARRAY declarations, but the same functionality is supported in COBOL and FORTRAN.
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!
[citation needed] 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.
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).
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.
