> > On Jan 17, 2025, at 12:10 PM, ben via cctalk > > <cctalk(a)classiccmp.org> wrote: > > > > On 2025-01-17 8:46 a.m., Paul Koning wrote: > > > > As for ALGOL, I know that Burroughs ALGOL (which > > is an extended ALGOL-60) has separate compilation, through a linker called > > "Binder". There is even a Binder for PDP-11 ALGOL, though I haven't tried > > it. PDP-11 ALGOL looks very much like a 16-bit derivative of Burroughs > > ALGOL. > > Gadzooks, A PDP running something other than B ^H C. :) > Other than Unix, C wasn't a common PDP-11 language. Mine run BASIC-PLUS, > Macro-11, > TECO, FORTH, and ALGOL. > > > paul > > Did Burroughs ALGOL, make cleaner software for people that used it? > > What about FORTRAN users? (I keep wanting to spell FORTAN) > > Ben. > What do you mean by "cleaner software"? > > ALGOL was the primary language on Burroughs mainframes, and the machine > architecture was > specificaly optimized for ALGOL. I don't know about FORTRAN (or COBOL) on > those > machines, I expect it existed but I never ran into it. > > Burroughs used ALGOL variants for various specialized purposes on those > systems. For the > terminal I/O machinery there was DCALGOL (data comm Algol) and for the kernel > there was > ESPOL -- basically ALGOL with C-like extensions to allow playing with lower > level machine > details. Apparently there was no assembler; a document I saw says that the > only low level > code is in the startup of the kernel, written in machine language (straight > hex), just > enough to set up the stack and a few other registers and transfer control to > the ESPOL > code entry point. > > Interestingly enough, the system security depended in large part on the fact > that there > was no assembler and access to ESPOL was restricted by file system access > rules. If you > could write ESPOL programs you could do things that break security, but the > regular ALGOL > compiler would not generate such code. This explains why at the shop where I > used that > machine (TU Eindhoven, B 6700 system) I got some very suspicious looks from > the staff when > I asked about wanting to read an ESPOL manual. > > paul
Burroughs (it's now called Unisys) mainframes and their ALGOL dialect shouldn't be discussed in the past tense, because the current versions of those systems are still being marketed, supported, and used. Burroughs had a variety of mainframe architectures. The one under discussion here has variously been called Large Systems (B6x00/7x00), A Series, and now ClearPath MCP. That product line was derived from the B5000/5500 and has an architecture specifically designed to support ALGOL, including hardware support for dynamically-allocated arrays and call-by-name semantics. Binder is still used, but it never was that common outside of FORTRAN and C applications. For the past 40 years, separate compilation has usually been done by means of dynamically-linked libraries, which are quite efficient. That is also now the most common way to call routines written in other languages, e.g., a COBOL program calling routines in an ALGOL library. FORTRAN and COBOL definitely exist on those machines. COBOL in particular is still used heavily. There was a PL/I compiler for a while, but almost no one used it, and it was discontinued years ago. Other languages are Pascal and C (with a fairly complete POSIX library). There are also a few utility languages, such as a sort generator and WFL, the batch job control language. There is still no assembler. ESPOL did not have anything like C extensions (never mind that it existed before C did). It was basically ALGOL with language extensions to access low-level hardware facilities and handle control words transparently. ESPOL was replaced in the early '80s by a new language, NEWP, which is somewhat Modula-like. All of the system software is written in ALGOL (or one of its variants), and NEWP, with some of the newer stuff in Pascal and C. It's true that the B6700 (early '70s) systems depended heavily on the compiler to restrict access to sensitive capabilities of the system, but that's been tightened up a lot over the years. You never could just sit down and write a program to generate runnable code -- runnable code can only be generated by compilers, and the code file for a compiler must be "blessed" by the system administrator. ESPOL could never be used to write a program that would run under the MCP (the OS). It could only be used to generate standalone programs that had to be booted manually. You could, however, write a procedure (subroutine) in ESPOL and bind it to another program. NEWP can generate runnable programs, but if you use any "unsafe" features of the language, the resulting code file is marked unsafe and requires administrator blessing before it can be run. We just don't have a problem with bad code getting into the modern systems. There is no such thing as anti-virus software for them. A different Paul
