The Architecture of the Burroughs B5000 (1982)
smecc.org
smecc.org
Read more here: http://www.computer-museum.ru/english/minsk0.htm
I guess "no one got fired for choosing IBM" held true not only under capitalism, but under communism as well.
(In a "small world coincidence", I happened to work with the son of the designer of the Minsk-32 -- the most advanced machine in the series -- at Yahoo. Belarus was one Soviet Union's Silicon Valleys, and incidentally the Belarusian State University Institute's Radio Technical Institute still has an excellent EE/CS program (hint: I think you'll have a lot less competition recruiting there than at Stanford!)
[1] Personally I'm a bit skeptical of stack architectures despite their huge popularity (JVM, CLR, Forth, etc...):I understand the cachet, but (to also quote my dad...) "programs can play chess very well", i.e., register windowing is one of the most well understood and mature algorithms, let the compiler handle that job. LLVM's use of a register-based IR is a good step in that direction.
On the other hand, I've heard many horror stories of similar goings happening with regards to technology at NASA/JPL and other tech-heavy government agencies: a great project gets built in house, it gets scraped because it isn't "up to WS-management standards and best practices and uses customized open source and not off-the-shelf commercial software". I call this the "not-invented-elsewhere syndrome", which can be just as pernicious as the more familiar NIH. am hoping recent debacles like healthcare.gov failure will get governments to revisit the way they look at building software.
It's really interesting to see how current the discussions on these old machines can be. From the OP:
"For additional security, code and data were distinguished in memory by the use of a "flag bit", and the hardware would not execute data or alter code without first having explicitly changed the flag"
We've been dealing with buffer-overruns and code injection in the stack until very very recently, and there are surely machines out there that still don't have support for the NX bit.
We surely still have a lot to learn from the past.
Even the Burroughs had multitasking before then, in the early 60s. And how can you not like a system with a "HEYU" instruction to interrupt other processors?
By the time the Internet generally arrived, and people generally realized what the Internet meant, we had accumulated enough backwards compatibility burden that sweeping architectural changes were difficult.
Microprocessors when they first came out were also feeling their way into architecture, Intel sort of headed down the Burroughs tagged capability architecture route - 286 segments, the 960, the 432 et al
But in the long term the PDP11/Vax were more the machines that people loved and their simple memory model (a simple array of bytes) and generic identical registers allowed portable languages and operating systems to flourish - prior to this operating systems were designed for particular hardware platforms - Burroughs MCP was never going to run on any other machine. People forget that the idea of a portable operating system in a time where operating systems were written and were the closed property of hardware manufacturers was a pretty radical idea at the time.
RISC, where simple was beautiful, loved the simple memory/execution models, Unix having grown up on PDP11s and Vaxen was the same.
Intel's through this was bit of a weird duck - they tried everything and failed at many of them - the CISCiest thing imaginable (the 432 a true capability machine) and the 960/860 (both kind of RISCy) all appeared at about the same time - but the 'x86 architecture has walked a pretty magically fine line - in a time of VAX derived CISCy architectures (68k 32k etc) they had a relatively simple memory addressing model (no indirect stuff) and a pretty simply instruction set - in retrospect much more RISCY than it's contemporaries, though missing the generic register file, the 386 eventually adopted the simple linear memory model and tried to forget about all that silly segment stuff and the 64-bit instruction set has moved to a RISCy world - I used to really hate the x86, especially when I wrote compilers, but in retrospect it's mellowed
The thing that microprocessors and the architectural trends they adopted have really done is they've taken us from a proprietary world where nothing was portable, where once you'd bought a system you were a captive customer - to a marketplace with competitive manufacturing and happier consumers
This doesn't actually sound like such a bad thing, provided enough processing-power to back it up (i.e. if you had an architecture like this in modernity.)
As as I see it, the problem is, at its core, in having a system call to spawn a process given a file full of (unsafe, unchecked) machine-code. You can avoid this: instead, only have a system call to execute a file of bytecode. Everything in userspace would target that bytecode format as if it were the machine's instruction-set. The kernel would then have to have an interpreter and JIT built into it, and do static safety checking--ala Google's NaCl sandboxing--before it ran the results. Both are CPU-costly, but doable, and the results could be cached.
Of course, root would still have to write the compiler... because the true "compiler"--the one targeting the native machine-architecture--would be the kernel.
You're a full professor, very important in the world, and you're running a big multi-hour data analysis run and the compsci student at the terminal next to you is writing a compiler (that would have been me) - every time they test their compiler code the system crashes and scribbles garbage over the hard drive a day later they've recovered the disk and that student is sitting there again ..... you go and see the powers that be
Basically if you wanted to write a compiler for this multi-million dollar platform you needed to have one for yourself ..... only one I know of was written outside Burroughs (UCSD Pascal) - my compilers were all interpreted until we got a Vax
We've come a long way since then, and in retrospective the most interesting thing about the article may be what it does not mention at all: the IBM PC, released in the previous year, which would go on to establish a mass-market platform where software compatibility became such a strong concern that praise of elegant and innovative hardware details that support a custom OS seem quaint or absurd.
To be fair it's used to be impossible to bring a hardware product to market without an OS and at least one compiler, and there were no portable compilers or operating systems when Burroughs, IBM, DEC et al were starting out - OS's and early compilers were often written in assembly, they just weren't going to be portable, and those walled gardens kept captured customers in the fold, you couldn't escape.
http://en.wikipedia.org/wiki/Soft_microprocessor
Although you might want to start with something simpler, like an 8-bit design so you can get the hang of sequencing before you start adding things like a MMU. It's also easy to simulate FPGAs on a computer, so you could get a simulation running before you go out and start spending your beer money buying Xilinx boards. The simulation will also help you choose a reasonable board, since the big ones are expensive and the small ones might not run your CPU. Or they might.
Thanks for the awesome answer :)
"Unisys has two different families of mainframes in the ClearPath line. From its Burroughs heritage comes the Libra family with their Master Control Program (MCP) operating system, and from the Sperry-Univac side comes the Dorado family with their OS 2200 operating system.
At the high-end and upper midrange of the Unisys product line are custom CMOS processors designed by Unisys and manufactured by IBM Microelectronics that have the high single-threaded performance on batch jobs that mainframe customers need.
In the midrange, there are smaller CMOS-based mainframes that bear the Dorado or Libra labels as well as a mix of machines that have ports of the MCP and OS 2200 operating systems and special virtualization and emulation sauce that lets CMOS binaries run atop x86 processors. The entry Libra and Dorado products are all based on Xeon machinery."