
The Architecture of the Burroughs B5000 (1982) - luu
http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm
======
dang
Link was originally
[http://www.ajwm.net/amayer/papers/B5000.html](http://www.ajwm.net/amayer/papers/B5000.html)
but that one's dead so we changed it.

------
strlen
Reminds me somewhat of the Minsk- series of indigeneously developed Soviet
mainframes -- stack architecture, RISC-like ISA, far ahead of its time. Due to
pressure from the higher ups -- or as my parents bluntly put it, "комуняки"
(the commies) -- it was abandoned in favour of reverse engineering and cloning
the IBM 360 (an enormous feat of engineering) an inferior architecture (my dad
called this a setback for Computer Science[1] -- not just in USSR, but in
general).

Read more here: [http://www.computer-
museum.ru/english/minsk0.htm](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.

~~~
ajuc
Soviets did it quite often. Production of one of the first minicomputers
[http://en.wikipedia.org/wiki/K-202](http://en.wikipedia.org/wiki/K-202)
designed by Poles in cooperation with British was also canceled despite being
very advanced for the time.

~~~
strlen
That's why I'm a capitalist: if an American computer firm told their best
employees "we're scraping this project you love and are building IBM 360
clone", the employees have had the option of going elsewhere. Indeed, exactly
this happened many times.

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.

------
hisham_hm
Incidentally, I just finished reading "The Mythical Man-Month", which also
discusses another old large system, IBM System/360 and its operating system
OS/360.

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.

~~~
mikestew
What was it, _South Park_ that did the "Simpsons did it" episode? Thinking
about some of the things that came along 20 or 30 years later remind of that.
Virtual machines? OS/360 did it. Virtual memory? OS/360 did it. Non-executable
data? OS/360 did it. I was a security lead for a product while at Microsoft
when the NX was being implemented, and wondered at the time why it took 35
years to get around to that. (I've never worked on a 360, but did some work
its successor the 370 and OS/370 some many years ago.)

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?

~~~
da02
Ever get an answer, or come close to one, as to why it took 35 years?

~~~
cliffbean
Before the Internet arrived, very few people had a big need for it. It makes
some things marginally harder, and it's more work to implement, so it makes
sense that it got left off.

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.

------
girvo
Somewhat related, but how feasible is it to experiment with building
interesting architectures like this using an FPGA? I've been trying to
convince myself to get one to fiddle with, and making experimental CPU
architectures would be something that would do so :)

~~~
klodolph
Definitely feasible. The original was done in discrete logic, so the FPGA
makes the process like 100x cheaper and 100x simpler. There's actually a
Wikipedia article about doing this,

[http://en.wikipedia.org/wiki/Soft_microprocessor](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.

~~~
girvo
An 8-bit design is what I actually want to fiddle with to begin with. I've
been looking at OpenCores lately to get a feel for what it's like, and it's
quite exciting. I'm thinking of getting a Spartan-3 or -6 board to play with,
but yeah running some simulations is a great idea!

Thanks for the awesome answer :)

------
ams6110
There are still systems descended from this architecture being produced, the
Unisys Libra servers, that can still run the MCP OS and programs.

~~~
nitrogen
Interesting. What industries benefit more from preserving this old
architecture than they would from reimplementing for a more mainstream system?

~~~
derefr
A more interesting question to me is, what is the benefit of maintaining the
architecture _in silicon_ , rather than as a software emulation/compatibility
layer on top of modern commodity hardware (e.g. x86)? Keeps all the lock-in
and services contracts, loses the supply-chain costs.

~~~
Someone
Apparently, performance:
[http://www.theregister.co.uk/2012/06/19/unisys_libra_460_mai...](http://www.theregister.co.uk/2012/06/19/unisys_libra_460_mainframe/):

 _" 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."_

~~~
derefr
Oh, it took a moment for that to click. _Of course_ these batch jobs--most
being written decades ago--are inherently serial, and throwing a bunch of x86
at them will thus do no more to help than throwing _one_ x86 at them. The best
bet, as with Bitcoin mining, is thus a specialized ASIC.

~~~
gaius
It's not to do with the age, some processes are inherently non parallelizable
due to the way the dependencies work. E.g. You can't have a lot of parallel
processes making payments because you have to make sure there is enough money
in the account for each one.

------
protomyth
Looks like there is at least one emulation project
[http://retro-b5500.blogspot.com](http://retro-b5500.blogspot.com)

