I thought this might interest some people because on the one hand it's a significant part of the history of ALGOL-derived languages, and on the other the implementation is deeply weird.

As some might recall, Burroughs had a range of "Large System" computers from the 1960s through '80s which were oriented to running ALGOL and related languages, with hardware-assisted stacks, a descriptor-oriented architecture and so on. These are frequently described as being programmable /only/ in ALGOL, i.e. there was no lower-level language, but in practice the machine-level opcodes were accessible to those of us who had to know, i.e. the maintenance guys and the people who had to configure initial boot (sometimes via a binary punched card, to tell the CPU how to find the disk pack with the MCP). [1]

Doctrine has it that Knuth and Dijkstra were involved to some extent as advocates of the architecture. It's unarguable that lots of people cited it as influential, e.g. Alan Kay (Smalltalk) and Charles Moore (Forth). There was a fairly good range of languages available, some from Burroughs but others from various univerisites.

It appears that somebody has written an emulator for the B5500, and it is able to boot the MCP extracted from tapes somebody had on their shelf and to run compilers. [2] [3] Also other people are finding listings (if not machine-readable media) of other software, e.g. an APL system written by a number of people including Gary Kildall (CP/M). [4] [5]

The really weird thing is that they've written this in Javascript, to run in a browser. In my opinion that's utterly crazy: a far better choice would have been ALGOL (possibly via Pascal) so that in principle at least the system could have been self-hosting.

So while I've got absolutely no intention of getting involved (the Burroughs Large System range is /dead/, in a way that e.g. the IBM S/370 isn't) I think that it raises an interesting question: is it possible to mechanically translate from Javascript to Free Pascal?

After all, if one developer has decided to use Javascript there might be others. And in some cases what they're working on might actually be useful to a wider community.

[1] http://en.wikipedia.org/wiki/Burroughs_large_systems [2] http://code.google.com/p/retro-b5500/w/list
[3] http://www.phkimpel.us/B5500/webSite/SoftwareRequest.html [4]
http://bitsavers.trailing-edge.com/pdf/burroughs/B5000_5500_5700/listing/ [5]
http://www.softwarepreservation.org/projects/apl/APLSoftware/APLSystems/B5500%20APL/

Deeply weird is right!

I fondly remember the Burroughs series. I had to port a very large FORTRAN system to it for our client, the Quaker Oats Company. They used a set of these mainframes for their main systems.

I loved the idea of the descriptor-oriented architecture. Each file was tagged with attributes, such as "Algol source file", "FORTRAN-produced object file", or "compiler-produced error log". Each program would only accept input from files of the correct type and only produced output files tagged with the correct type. This was enforced by the OS. For example, if a program was tagged as a compiler would only be able to accept input from a file that was properly tagged as a source file of the language it compiled and it could only produce files that were object code or error logs. Also, the OS only executed files that were properly tagged as executable. There were security attributes as well. A text editing program would not work on an object file or an executable. In fact it automatically knew what was being edited based on the file attributes so it could adapt the editing features the the content. Kept things nice and organized and orderly. Kept the hacking to a minimum, also, I bet.

The major use of the term "descriptor" was a data structure which pointed to a variable. If you told the hardware to put something on the stack and gave it the address of a descriptor it would dereference it, and if you gave it the address of a descriptor which pointed to another descriptor (etc.) it would follow the entire chain: the compiler quite simply didn't have to generate code to make this work.

Later implementations of the architecture added tag bits to each word in memory (something like 48 bits data, parity, 3 bits tag, ECC) which couldn't be manipulated by a user-mode program. That was obviously a major advance in robustness and security.

There were security attributes as well.

The idea of code signing originated (I believe) on this architecture: you could compile a compiler from source, but unlike application programs it had to be "blessed" by somebody traceable before it could generate executable code. Larry Wall (Perl) at one point worked for Unisys (Burroughs' successor company) and refers to "blessing" data structures into objects: he's been harshly criticised for that by people who claim that he is insinuating his christian convictions into the programming language and its infrastructure.

In any event, the Large System architecture is dead as a native platform: for the last decade or so it's been available in emulated form on Unisys's Xeon and Itanium systems, and The Register reports that the Xeon systems can now run the emulation faster than the available specialist CMOS processors.

Thanks for the correction about descriptor architecture. I thought you were referring to the file system tagging stuff.

I would hope that someday the good ideas of the past would find their way back into general use.

I also remember some really awesome attributes of VMS that have been discarded. At least HP has been keeping OpenVMS alive so people can actually see what it can do. Probably the most secure and reliable OS in general use today. 17 year cluster uptime? Amazing.

If we're discussing obsolete historic platforms, I would like to add my story, too.
It sounds a little bit similar.

In Germany, we had a mainframe platform from the now non-existent computer manufacturer Telefunken, starting with the TR4 in the early 60s, which was, according to Dijkstra, a "hardware implementation of ALGOL". It had 48 bit words, and every word had two tag bits, which telled if the word was fixed point,
floating point, instructions (two 24 bit instructions) or text (for example 6 characters,
but there were other formats, too). If you used the wrong instruction (which
didn't match the tag bits), you got an error called "Typenkennungs-Alarm". This way it was possible for example to detect the use of uninitialized variables
at runtime.

The offspring was the TR 440, which was a large time-sharing machine with display monitors, virtual storage and (in the end) up to 3 processors. It was used at the universities in Germany througout the 70s and early 80s and most of the students of Computer Science (called Informatik in Germany) grew up with this machines at this time. There was a Pascal compiler written
in Kaiserslautern first and completed in Stuttgart later, which was a port of
the Zurich P4 compiler, and it had all the features, that were normal at this
time, that is, an interactive debugger, and dumps which printed the variables
in the layout of the programming language, not hexadecimal, that is: variable names and values.

It was in use at the Stuttgart university from 1973 to 1980, and I studied Informatik there from 1977 until 1985, so I spent some days and nights with this machine. After that, we got a VAX 11/780; that was a very nice machine, too.

The Telefunken manuals are at the Deutsches Museum in Munich, but - I have some private copies. There are not
many people today that still know this platform.

Kind regards

Bernd

It was in use at the Stuttgart university from 1973 to 1980, and I studied Informatik there from 1977 until 1985, so I spent some days and nights with this machine. After that, we got a VAX 11/780; that was a very nice machine, too.

I also had much fun with the TR-440, from 1971 to
first few years we were connected to a machine at Karlsruhe, until we got our own TR-440. My first programming exercise, a board game, resulted in a printout of 30 pages (the limit) of "Gewonnen!", because I missed to read in the next data record, and I considered to use it as a wall paper in my next apartment :-)

The Telefunken manuals are at the Deutsches Museum in Munich, but - I have some private copies. There are not many people today that still know this platform.

I'm also a proud owner of an original TR-440 instruction set manual :-)

BTW do you know HP Kehm, HofnArr or Flip-Flop?

DoDi

The big question of course is whether anybody has any systems software. There are of course available copies of older IBM OSes, Burroughs Large Systems and ICL 1900 run on emulators, and I believe that the project to run an emulated Cray-I (on a single FPGA) is doing fairly well after a disc pack was read with difficulty.

But even allowing that programs from 30 years ago were vastly smaller than they are today, typing in something from a listing is a horrid job: I've done it for a CDC APL implementation in Pascal, and I've got a nagging suspicion (but can never be really sure) that the bugs aren't entirely my fault.

I came across this over the weekend, which illustrates some of the odder properties of the descriptor architecture:

"Part of the idea was that when you fetch something, the processor wouldn't know until it hit the word it was fetching whether there was going to be data there [0 in the MSB] or whether it was going to be an indirect reference [1 in the MSB] to code which would be executed to furnish the data. It made it a very clean way of implementing ALGOL name call expressions because the basic code inside the procedure wouldn't have to do anything special to access a call-by-name parameter. With access just like a call-by-value parameter."
http://conservancy.umn.edu/handle/107105

There's suggestions in the paper that Intel's aborted iAPX432 architecture borrowed ideas, and I think I'd say that the protected-mode architecture of the '286 (and successors) is at least an example of convergent evolution. But in practice, after 50 years of competition, this type of architecture is thoroughly dead with the dominant philosophy being much more IBM-like.

There appears to be a lot of interest at the moment in resurrecting old architectures and finding their system software. However I think the only one which has any "survival value" is the IBM S/370 and its successor machines.