8 ms·

The Burroughs B5000 - 20 Years Later and Still Ahead of the Times?

45 points by da02 14y ago

sp332 14y ago
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 https://queue.acm.org/detail.cfm?id=1039523
- tedunangst 14y ago
  I would love to know what that benchmark is. I feel pretty confident I could cherry pick a benchmark that runs a lot faster than 50x on modern hardware. Some variant of Amdahl's law probably applies here.
  - ScottBurson 14y ago
    I'll hazard a guess as to what's going on here. The OP mentions the B5000's use of descriptors. I think it's decoding a descriptor and doing bounds checking on every array access. That would certainly slow down a machine that didn't have hardware support for these operations.
    - tedunangst 14y ago
      That's a fairly trivial optimization for a jit to perform. And a 1000x penalty for bounds checking? No way, that would literally require your bounds check to take a minimum of 1000 instructions, even assuming your inner loop didn't do anything meaningful with the accessed value.
  - DanBC 14y ago
    Maybe this email list has some details? (http://lists.canonical.org/pipermail/kragen-tol/2007-March/000850.html http://lists.canonical.org/pipermail/kragen-tol/2007-March/0...) Here's a mildly interesting rant: (http://www.yosefk.com/blog/the-high-level-cpu-challenge.html http://www.yosefk.com/blog/the-high-level-cpu-challenge.html) This post doesn't give any details of the benchmark, but describes another test (boot, load word processor, open document, close wp, shut down) and compares an old mac and a (at the time) modern laptop. (http://tekkie.wordpress.com/2009/08/12/does-computer-science-have-a-future/ http://tekkie.wordpress.com/2009/08/12/does-computer-science...)
    - tedunangst 14y ago
      Thank you. Looks like I'm not the first to ask. Doubt I'll be the first to get an answer. Wrt the last post, I'll note my openbsd laptop can complete that challenge before many other machines have made it past post, so all hope is not lost. And we had wysiwyg HTML editors eons ago. The switch to online markdown editors was a trade off, but it's not like the secrets of the ancients were lost when the library of parc was burned to the ground.
- wmf 14y ago
  Without details this borders on trolling. If Kay could build a processor that was even 10x faster than Intel he'd be a billionaire.
  - sp332 14y ago
    Intel didn't get popular because of speed. They got popular for only two things: people write software for their platform, and they're cheap. Just as one example, the DEC Alpha was never slower but they were cancelled by Compaq who backed Intel's Itanium instead.
    - cbsmith 14y ago
      Alpha was slower for fixed point, particularly if you factor in bang for the buck.
      - sp332 14y ago
        I couldn't quite remember about that, I just knew they had a better architecture for 2+ GHz. Wikipedia's chart shows Alpha and Intel being very close for fixed point as well.
        cbsmith 14y ago
        AlphaServers were not exactly as inexpensive as the Intel systems in those examples. The Alpha had a huge disadvantage in that low cost motherboards were hard to come by, and those that were available actually did tend to kill its performance. There were certain kinds of benchmarks (including some in SPECcpu) that really favoured CPU's with 64-bit fixed point arithmetic, but if you left those out, it wasn't even a contest. Even when you left them in, the Alpha systems had a hard time justifying themselves for people who weren't doing floating point work.
  - acqq 14y ago
    Kay is dear to me, but dearer still is truth: Moore's law has nothing to do with the speed anyway: http://en.wikipedia.org/wiki/Moores_law http://en.wikipedia.org/wiki/Moores_law
ChuckMcM 14y ago
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/unv-de2-board.html?GSA_pos=3&WT.oss_r=1&WT.oss=DE-2 http://www.altera.com/education/univ/materials/boards/de2/un...
lolcraft 14y ago
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.
- justin_vanw 14y ago
  Oh jeez... I wish I could just assume you were trolling here. Virtual memory: This is used to give every process a flat and consistent address space. It is not just a synonym for 'swapping', and it will be around forever. String instructions: Seriously, are you just making it up as you go along? http://www.strchr.com/strcmp_and_strlen_using_sse_4.2 http://www.strchr.com/strcmp_and_strlen_using_sse_4.2 Custom opcodes: Usually done via API's that have an emulation or compatability function, DirectX, OpenGL for examples. LOCK existed: The article describes an atomic compare and write, not just a LOCK. In fact, MUTEX is implemented with the compare and exchange instruction in most OS's. http://marc.info/?t=113443157800005&r=1&w=2 http://marc.info/?t=113443157800005&r=1&w=2 I believe the no execute bit is a very recent addition to AMD64, and is not available at all on x86. Vector operations and such: Have you not heard of MMX, SSE or even graphics cards? Either I'm feeding a troll here, or you have no clues available to you.
jleader 14y ago
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 http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html)
wglb 14y ago
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.
ableal 14y ago
[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")
bcantrill 14y ago
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 http://queue.acm.org/detail.cfm?id=1454462
- joshu 14y ago
  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 14y ago
    (Hey Joshua!) Assuming that you're referring to the linked article and not to mine, I emphatically agree. ;)
    - joshu 14y ago
      Yes, I meant the linked article.
- cbsmith 14y ago
  Interesting... A lot of the "ahead of its time" features were those that have only made sense as various other factors in computing have matured... including multiprocessing. Is it possible that these features that were essentially not a good idea for a lot of the intervening time period?
  - jleader 14y ago
    The common wisdom at Burroughs when I worked there in the 80s was that back in the 60s and 70s, Burroughs often invented something, then 5 years later IBM would "invent" it, and then the industry press would start talking about what a good idea it was. I still have next to my desk a small sign I salvaged from the computer room in the Burroughs Pasadena Development Center when it was being shut down, which reads "Each person having access to this room is cautioned not to discuss the machines or work done here with unauthorized employees or persons outside the company. Premature disclosure of new inventions might void our patent rights here or throughout the world." (signed by the then-president of Burroughs, R. W. Macdonald) I saved it because the irony amused me at the time.
acqq 14y ago
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 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 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 14y ago
  > code and data were distinguished Lisp is not impressed.
waveman 14y ago
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 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.
aufreak3 14y ago
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.

45 points by da02 14y ago

sp332 14y ago

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 https://queue.acm.org/detail.cfm?id=1039523

tedunangst 14y ago
I would love to know what that benchmark is. I feel pretty confident I could cherry pick a benchmark that runs a lot faster than 50x on modern hardware. Some variant of Amdahl's law probably applies here.
- ScottBurson 14y ago
  I'll hazard a guess as to what's going on here. The OP mentions the B5000's use of descriptors. I think it's decoding a descriptor and doing bounds checking on every array access. That would certainly slow down a machine that didn't have hardware support for these operations.
  - tedunangst 14y ago
    That's a fairly trivial optimization for a jit to perform. And a 1000x penalty for bounds checking? No way, that would literally require your bounds check to take a minimum of 1000 instructions, even assuming your inner loop didn't do anything meaningful with the accessed value.
- DanBC 14y ago
  Maybe this email list has some details? (http://lists.canonical.org/pipermail/kragen-tol/2007-March/000850.html http://lists.canonical.org/pipermail/kragen-tol/2007-March/0...) Here's a mildly interesting rant: (http://www.yosefk.com/blog/the-high-level-cpu-challenge.html http://www.yosefk.com/blog/the-high-level-cpu-challenge.html) This post doesn't give any details of the benchmark, but describes another test (boot, load word processor, open document, close wp, shut down) and compares an old mac and a (at the time) modern laptop. (http://tekkie.wordpress.com/2009/08/12/does-computer-science-have-a-future/ http://tekkie.wordpress.com/2009/08/12/does-computer-science...)
  - tedunangst 14y ago
    Thank you. Looks like I'm not the first to ask. Doubt I'll be the first to get an answer. Wrt the last post, I'll note my openbsd laptop can complete that challenge before many other machines have made it past post, so all hope is not lost. And we had wysiwyg HTML editors eons ago. The switch to online markdown editors was a trade off, but it's not like the secrets of the ancients were lost when the library of parc was burned to the ground.
wmf 14y ago
Without details this borders on trolling. If Kay could build a processor that was even 10x faster than Intel he'd be a billionaire.
- sp332 14y ago
  Intel didn't get popular because of speed. They got popular for only two things: people write software for their platform, and they're cheap. Just as one example, the DEC Alpha was never slower but they were cancelled by Compaq who backed Intel's Itanium instead.
  - cbsmith 14y ago
    Alpha was slower for fixed point, particularly if you factor in bang for the buck.
    - sp332 14y ago
      I couldn't quite remember about that, I just knew they had a better architecture for 2+ GHz. Wikipedia's chart shows Alpha and Intel being very close for fixed point as well.
      - cbsmith 14y ago
        AlphaServers were not exactly as inexpensive as the Intel systems in those examples. The Alpha had a huge disadvantage in that low cost motherboards were hard to come by, and those that were available actually did tend to kill its performance. There were certain kinds of benchmarks (including some in SPECcpu) that really favoured CPU's with 64-bit fixed point arithmetic, but if you left those out, it wasn't even a contest. Even when you left them in, the Alpha systems had a hard time justifying themselves for people who weren't doing floating point work.
- acqq 14y ago
  Kay is dear to me, but dearer still is truth: Moore's law has nothing to do with the speed anyway: http://en.wikipedia.org/wiki/Moores_law http://en.wikipedia.org/wiki/Moores_law

ChuckMcM 14y ago

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/unv-de2-board.html?GSA_pos=3&WT.oss_r=1&WT.oss=DE-2 http://www.altera.com/education/univ/materials/boards/de2/un...

lolcraft 14y ago

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.

justin_vanw 14y ago
Oh jeez... I wish I could just assume you were trolling here. Virtual memory: This is used to give every process a flat and consistent address space. It is not just a synonym for 'swapping', and it will be around forever. String instructions: Seriously, are you just making it up as you go along? http://www.strchr.com/strcmp_and_strlen_using_sse_4.2 http://www.strchr.com/strcmp_and_strlen_using_sse_4.2 Custom opcodes: Usually done via API's that have an emulation or compatability function, DirectX, OpenGL for examples. LOCK existed: The article describes an atomic compare and write, not just a LOCK. In fact, MUTEX is implemented with the compare and exchange instruction in most OS's. http://marc.info/?t=113443157800005&r=1&w=2 http://marc.info/?t=113443157800005&r=1&w=2 I believe the no execute bit is a very recent addition to AMD64, and is not available at all on x86. Vector operations and such: Have you not heard of MMX, SSE or even graphics cards? Either I'm feeding a troll here, or you have no clues available to you.

jleader 14y ago

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 http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html)

wglb 14y ago

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.

ableal 14y ago

[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")

bcantrill 14y ago

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 http://queue.acm.org/detail.cfm?id=1454462

joshu 14y ago
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 14y ago
  (Hey Joshua!) Assuming that you're referring to the linked article and not to mine, I emphatically agree. ;)
  - joshu 14y ago
    Yes, I meant the linked article.
cbsmith 14y ago
Interesting... A lot of the "ahead of its time" features were those that have only made sense as various other factors in computing have matured... including multiprocessing. Is it possible that these features that were essentially not a good idea for a lot of the intervening time period?
- jleader 14y ago
  The common wisdom at Burroughs when I worked there in the 80s was that back in the 60s and 70s, Burroughs often invented something, then 5 years later IBM would "invent" it, and then the industry press would start talking about what a good idea it was. I still have next to my desk a small sign I salvaged from the computer room in the Burroughs Pasadena Development Center when it was being shut down, which reads "Each person having access to this room is cautioned not to discuss the machines or work done here with unauthorized employees or persons outside the company. Premature disclosure of new inventions might void our patent rights here or throughout the world." (signed by the then-president of Burroughs, R. W. Macdonald) I saved it because the irony amused me at the time.

acqq 14y ago

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 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 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 14y ago
> code and data were distinguished Lisp is not impressed.

waveman 14y ago

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

aufreak3 14y ago

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.