Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Since learning of it, I have always been disappointed that I was not able to write and run software for a Burroughs machine running the MCP

http://en.wikipedia.org/wiki/Burroughs_MCP

"the first operating system to manage multiple processors, the first commercial implementation of virtual memory, and the first OS written exclusively in a high-level language."

using the Work Flow Language

http://en.wikipedia.org/wiki/Work_Flow_Language

Like the success the 432 could have been I feel that the Burroughs architecture was prematurely abandoned and at modern speeds would have plenty to offer.



Burroughs MCP still exists, so I am not sure how true your statement that it was "prematurely abandoned" is. Burroughs became (through a series of M&As) Unisys, and Unisys still supports MCP and is updating it with new versions. It runs on Unisys Clearpath mainframes. Unisys has moved away from their distinctive physical hardware to software emulation on an x86 platform. x86 has improved so dramatically, that even given the emulation overhead, it still is faster than the old physical mainframe CPUs.

There is also an emulator which runs an old (1970s) version of MCP, not the current (2010s) version - http://www.phkimpel.us/B5500/


Thank you, your response was partly what I was hoping to get by saying it.


(As an old time B6700 hack ...) I think there were two main architectural problems with the Burroughs architecture:

- it depended on compilers making safe code for both its system security and system integrity - this mean that you couldn't write your own compiler without being the equivalent of root, and you couldn't test it without potentially taking down the system - there was no hard memory protection between processes

-memory descriptors contained both lengths and pointers - that limited memory size to 2^^((wordsize-overhead)/2) words - in Burroughs case it was 6Mb (6 byte words) huge at the time, tiny today

The 432 had it's own issues - I think it designed itself into a corner at a time when memory speeds were very low so tight instruction coding was important, microcode was where you got your speed - the problem with that is of course that buggy microcode is hard to fix - cheaper/faster memory made the risc revolution possible and now we look at different bottlenecks


Oh and WFL was nothing much to write home about - it was essentially the shell scriptin language - most people coded in Algol or Fortran (or for system stuff Espol which was just the Algol compiler with a few extra system related features enabled)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: