The Burroughs B5000 - 20 Years Later and Still Ahead of the Times?
ajwm.net
ajwm.net
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.
(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)
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...)
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.
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.
At this point being "faster" is only a bullet point on a long list of reasons to buy the chip.
AMD didn't invent x86, yet is successful.
ARM isn't compatible with x86, yet is successful.
There are more...
Whatever happened to Transmeta?
AMD lived for years in Intel's shadow and barely scraped by, surviving only because they were willing to price their chips lower than Intel wanted to. Their success came only when Intel fumbled and, to their credit, the Athlon series of chips was in its prime. I'd argue they were only successful at that point because they were better and cheaper than the Intel chips at the time which were unusually under-performing and over-priced. They were only cheaper because they had years of experience in surviving at the bottom end of the market. They also marketed like their life depended on it.
ARM is something of an anomaly. They were as much as left for dead, with conventional wisdom thinking one of Motorola, IBM or even Intel would run them over like a bug on the road. That didn't come to pass because none of those companies ever seriously committed to building a modern but very low power CPU. They squeaked through a hole.
To credit NVidia with the success of 3Dfx is misleading. It was the Voodoo card that was marketed aggressively to consumers which, at the time, cared little for 3D performance. NVidia picked them up at a yard sale when they were run out of the market by more successful companies like ATI and, at the time, Matrox. It was NVidia's acquisition of 3Dfx that showed they were serious about the consumer market and not just ultra high-end applications. Making one GPU for both consumer and professional markets gave them the edge to remain competitive.
All three of these companies got lucky. They say you can engineer your own luck, and with that I can't disagree, but they never had a "better" product until the other guy dropped the ball or they could crack open a new market.
You mean cutting margins to survive while they didn't have the luxury of massive volume pricing? Isn't this exactly what you were arguing can not possibly happen?
> ARM is something of an anomaly. They were as much as left for dead, with conventional wisdom thinking one of Motorola, IBM or even Intel would run them over like a bug on the road.
Which architectures from each of those companies was in competition with ARM in its early days? I don't think that competition came till much later when ARM had already proven itself in the micro-controller market.
> To credit NVidia with the success of 3Dfx is misleading. It was the Voodoo card that was marketed aggressively to consumers which
Nvidia bought them because Nvidia created a part that performed on par or better than the 3Dfx part but also did 2D, which was a flat out revolution in the graphics card market.
> All three of these companies got lucky.
Sorry, that is just an incredibly egotistical comment to make.
They also had the advantage of not betting the house on Itanium or losing their shirt on the doomed Pentium 4 architecture.
In the early days, where ARM was used in the Newton and very little else. Motorola absolutely owned the market. If I was to bet on someone to unseat them I'd have gone with Hitachi and their SH series as used in the Dreamcast.
Like I said, they got lucky, but they also played smart when they did get lucky. Too many companies have been handed the opportunity of the century only to fumble it. It's a credit to each of them they went from underdog to player.
I still don't think this discounts how much money it takes to succeed. It takes a great company with a product that is at least good enough, not necessarily better.
But note that they haven't disrupted {lap,/desk}tops yet, despite having comparable power. The barrier isn't manufacturing scale but compatibility with x86's massive install-base of software. One way around this is an entirely new ecosystem, such as phones/tablets.
It'll be interesting to see if ARM can parlay their near stranglehold on the market now into further dominance into previously desktop-only domains, and possibly even servers.
(Hi Bryan!)
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.
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...
"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.
Lisp is not impressed.
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.
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.
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.
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
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
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.
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.
So when, if ever, are we going to see it disappear? (If disks are always going to be cheaper than RAM?)
Some kernels allow you to disable swapping to disk, and others run quite well without any swap, but this the notion of "swap" still seems tightly integrated into most OS's. And I'm still seeing gimmicks like "Increase your system memory with [some catchy product name, but is actually nothing more than a multi-GB USB stick you plug in to give you more swap]."
Will we ever move beyond the concept of swapping to disk?
Instead what we are talking about is having each process appear to have its own memory address, where virtual addresses are translated to different pages that may or may not be backed to specific physical RAM.
"A single bit in the descriptor can be used to specify whether the array (or other segment) is actually in core or not (the 'presence bit"). Bingo! Virtual memory."
This is really swapping, not virtual memory as we understand it today. While memory protection and translation are essential IMO, I agree with other commenters that swapping is mostly obsolete.
Just trying to understand his comment.
Instead of having to be aware of everything else in memory, and carefully allocating around other things and taking care not to step on each other, it can just assume that nothing else exists, and it has the whole addressable range to put things where it likes.
This isn't really true of course, it's a bit like being given a magical chest-of-drawers in which both you and your friends can use the same drawer, but every time you open it, it only has your own things inside. And behind the scenes, there's a little imp shifting stuff in and out depending on who's pulling the handle.
The virtual addressing part is the sharing of those drawers, the swapping part is if, instead of having only 4 drawers, there are now 8, or 16, or any number. If you open one of these drawers that doesn't actually exist, the imp rummages around in a bigger box in the next room, finds it, and fills whatever is meant to be there. He also sedates you if this happens, so the change appears 'instant' to you.
Because going into the other room is slow for him (and also you, but you might not necessarily notice because you're unconscious) he keeps a bunch of the most recent or most common things around close to hand on his side of the drawers so he can swap them quickly. Every time you need something that isn't nearby, he has to take something out with him to make space, and come back with the new thing.
There's a reasonable argument that this latter part (swapping) can be optional - you don't really have infinite memory like you're pretending, it's still limited to either the amount you can address, or the amount you can store in your secondary storage. And, comparatively, the secondary storage is really damn slow. But, for those occasional times when you just pass the limit, being able to handle that without crashing or the kernel arbitrarily nuking something to make space, it's useful.
Is the sedation COW?
Vector operations are about expressing data parallelism to the processor. Parallelism/concurrency is the only thing that will save us past the end of Moore's Law. It has very little to do with fast MMX/SSE lanes.
x86 has this.
> Virtual memory -- useless with 4 GB of RAM at 30$.
No. This is wrong, even if you do bizarrely assume everyone can afford 4GB of RAM for their systems. There will always be workloads that need it.
> RISC being faster to execute than CISC
You can only prove this through benchmarks.
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")
... ok 'nuff fond reminiscing.