
The Burroughs B5000 - 20 Years Later and Still Ahead of the Times? - da02
http://www.ajwm.net/amayer/papers/B5000.html
======
sp332
Alan Kay often uses the Burroughs architecture as an example of hardware
that's good for software.

 _Neither Intel nor Motorola nor any other chip company understands the first
thing about why that architecture was a good idea.

Just as an aside, to give you an interesting benchmark—on roughly the same
system, roughly optimized the same way, a benchmark from 1979 at Xerox PARC
runs only 50 times faster today. Moore’s law has given us somewhere between
40,000 and 60,000 times improvement in that time. So there’s approximately a
factor of 1,000 in efficiency that has been lost by bad CPU architectures.

The myth that it doesn’t matter what your processor architecture is—that
Moore’s law will take care of you—is totally false._

<https://queue.acm.org/detail.cfm?id=1039523>

~~~
wmf
Without details this borders on trolling. If Kay could build a processor that
was even 10x faster than Intel he'd be a billionaire.

~~~
astrodust
You can build a better processor, but who would use it if you don't have the
manufacturing technology to mass produce it at a cost-effective price, or
market it to consumers to get the scale you need to drive prices down in the
first place?

At this point being "faster" is only a bullet point on a long list of reasons
to buy the chip.

~~~
wmf
If you're actually 10x faster (2x is not enough), people will give you the
money.

~~~
astrodust
At the same price point and power consumption? Then it'd be worth recompiling,
for sure.

~~~
darkarmani
_fires up Gentoo box and starts recompiling_

------
bcantrill
Amazingly, the B5000 was ahead of its time in so many regards that you can't
expect someone surveying it a mere two decades later to fully understand its
scope. In particular, I don't think that the linked article does nearly enough
justice to the B5000's pioneering use of multiple CPUs -- in part because
symmetric multiprocessing was still very much in utero in 1982. When I wrote
an article on concurrency for ACM Queue another twenty-six years later[1], the
degree to which the B5000 had been ahead of its time with respect to
multiprocessing was much clearer -- and I felt duty-bound to give the B5000
its propers.

[1] <http://queue.acm.org/detail.cfm?id=1454462>

~~~
joshu
I didn't think this was a great article. Just a sortof grabbag list of
features. Some of which feel quite retrograde, like stack-based architecture
etc.

(Hi Bryan!)

~~~
bcantrill
(Hey Joshua!) Assuming that you're referring to the linked article and not to
mine, I emphatically agree. ;)

~~~
joshu
Yes, I meant the linked article.

------
ChuckMcM
Ah the old Burroughs architecture. It truly was ahead of its time. Although
some of its operating systems were pretty atrocious (I'm looking at you
CANDE).

One of the really cool things that is possible these days is to build nearly
all first, second, and third generation CPU architectures out of a 'student'
FPGA kit. If you ever want to get a visceral sense of how computers work I can
recommend building the whole thing.

My personal favorite tool for that is the Altera DE-2 [1] because it already
has the lights and switches :-)

[1]
[http://www.altera.com/education/univ/materials/boards/de2/un...](http://www.altera.com/education/univ/materials/boards/de2/unv-
de2-board.html?GSA_pos=3&WT.oss_r=1&WT.oss=DE-2)

------
acqq
One interesting example from the text:

"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 (something reserved for
privileged processes)."

Sounds awfully like a

<http://en.wikipedia.org/wiki/NX_bit>

which Intel introduced first time in 2004 their mainstream CPU's as they took
the AMD64 specification:

<http://en.wikipedia.org/wiki/AMD64>

Therefore on the common processors we have that feature only 8 years, now when
B5000 is around 50 years old.

~~~
njharman
> code and data were distinguished

Lisp is not impressed.

------
waveman
It was a truly awesome machine. When I left college (which had a B6700) and
went to work on Honeywell and IBM machines it was like taking a long sad walk
back to the dark ages.

One small example: the job control language (WFL) was an Algol variant which
was great to program and Turing complete. Compare to IBM's appalling "JCL".

<http://en.wikipedia.org/wiki/Job_Control_Language>

Array bounds checking with useful source level error messages (versus S0C4
abends and a core dump on IBM), writing multi-processor apps in Algol or COBOL
was easy (versus close to rocket scientist level on an IBM requring for
example that you code in assembler). Flags to distinguish code from data so
data would not get executed etc etc.

------
wglb
Couple of interesting things that the article did not describe. The addresses
of instructions in the b5500 were _decimal_. Yes, decimal.

IBM came out with the IBM 380 model 67 in about 1967 with it's first
implementation of virtual memory. I believe that was done in conjunction with
U. Mich.

In the 60s there was lots of discussion about virtual memory, what size should
the "working set" be, and so on. As for many things in that time and actually
decades later, ideas were not accepted until IBM implemented them. Many folk
at the time thought that IBM invented virtual memory.

What is missing from most of these discussions is an even more remarkable
machine (in my view), the Burroughs B1700. It did not have a fixed instruction
set size--each program had a definition in the header of the file that
specified the size of the word, the number of bits in the instruction field,
and so on. In fact, the instruction codes were not fixed, and changed several
times. Only the compiler writer and the firmware engineer had to agree on the
meaning of the codes.

And yes, I believe that Alan Kay is right about misguided hardware
architectures after all these years. There was lots of disappointment when the
360 instruction set came out when it was compared to the instruction sets that
came before it. The instruction set of the DEC-10 and relatives was a thing of
beauty. The PDP-11 was also quite nice, and if you have ever looked at a
Motorola 6809, you can see some resemblance.

The Intel instruction sets continued this negative trend. It has always seemed
to me that the instructions were designed with an eye to optimizing the wrong
thing, and prematurely.

What Intel is good at are 1) design wins and 2) fab process improvements.
Instruction set or software design, not so much.

We need somebody to turn this cart over and straighten up this mess.

------
lolcraft
I see not that many features that I like and modern processors don't have.
Array bound checking would be nice, of course. And yes, not having different
pools of unrelated, different-size registers, and a more RISCy opset would be
very very considerate. But some of these features seem _very inferior_ by
design:

Virtual memory -- useless with 4 GB of RAM at 30$. I'm personally also a
proponent of managing this kind of thing with software, since we have OS's,
and with good reasons.

String instructions: became useless in terms of performance when the Pentium
pipeline came along. Which was undoubtedly a good design decision.

Custom opcodes: just write an interrupt handler for INT3, or whatever INT you
like. Your OS might not let you in user mode, but some might say that's a
feature.

LOCK existed from the beginning of the multiprocessor era, so please don't act
so smug about it. It's like saying that your submarine swims.

The paging unit of the x86 allows the presence of a tag, independent of
pointers, including code/data separation. And I'm not that keen on
implementing a typesystem in hardware. Extensibility and all that.

Not separating opcodes for different semantics is a bad idea. It's like
overloaded operators. Who knows what you are doing, given that types are not
known in runtime. I'd personally like to see assembly become a more typeless
programming language, anyway.

Vector operations and such... Well, in reality, they probably would slow down
the processor, compared to having many atomic instructions, RISC being faster
to execute than CISC and all that.

~~~
joshu
Virtual memory is exceedingly slow and difficult without hardware support.

Vector operations (SIMD etc) aren't necessarily RISC vs CISC; it is
orthogonal. The very notion of RISC vs CISC is practically an antiquated
notion now.

~~~
astrodust
Especially since modern Intel processors are mostly RISC-like inside with a
CISC decoding layer wrapped around it. The difference is academic as it all
boils down to similar CPU-level code and seems more dependent on the internal
design of the chip than the instruction set.

------
jleader
For some interesting history about the development of the B5000, see "Stories
About the B5000 and People Who Were There" (<http://ed-thelen.org/comp-
hist/B5000-AlgolRWaychoff.html>)

------
ableal
[1982]

To rub it in.

I suppose modern microprocessors have mostly caught up, and whatever is left
out comes off in the speed scaling wash (as in "RAM is new disk")

------
aufreak3
The concept of a "descriptor" as an object for memory accesses that helps with
bounds checking and preventing memory overruns was borrowed lock stock and
barrel (including the terminology) into the Symbian OS's C++ API - classes
TDesC, TDes, TPtrC, etc. Contrary to the amount of bitching one hears, they
were a pleasure to work with, for me, due to the confidence due to bounds
checking, efficient representation (perfectly ok to stack copy them) and it
was just convenient to have to never pass additional length arguments anywhere
internally.

... ok 'nuff fond reminiscing.

