Editing Burroughs Large Systems (section)

=== Stack structure advantages ===

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.{{Citation needed|date=February 2007}} 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 [[Kenneth E. Iverson|Iverson]], the designer of [[APL (programming language)|APL]] declared that the Burroughs implementation of APL was the best he'd seen.{{Citation needed|date=February 2007}} [[John McCarthy (computer scientist)|John McCarthy]], the language designer of [[LISP]] disagreed, since LISP was based on modifiable code{{Citation needed|date=February 2007}}, he did not like the unmodifiable code of the B5000{{Citation needed|date=February 2007}}, 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 management (operating systems)#Partitioned allocation|memory partitions]] in which to run tasks.