SoylentNews is people
SoylentNews
Today, we've decided to revisit some of the worst CPUs ever built. To make it on to this list, a CPU needed to be fundamentally broken, as opposed to simply being poorly positioned or slower than expected. The annals of history are already stuffed with mediocre products that didn't quite meet expectations but weren't truly bad.
Note: Plenty of people will bring up the Pentium FDIV bug here, but the reason we didn't include it is simple: Despite being an enormous marketing failure for Intel and a huge expense, the actual bug was tiny. It impacted no one who wasn't already doing scientific computing and the scale and scope of the problem in technical terms was never estimated to be much of anything. The incident is recalled today more for the disastrous way Intel handled it than for any overarching problem in the Pentium micro-architecture.
We also include a few dishonourable mentions. These chips may not be the worst of the worst, but they ran into serious problems or failed to address key market segments. With that, here's our list of the worst CPUs ever made.
- Intel Itanium
- Intel Pentium 4 (Prescott)
- AMD Bulldozer
- Cyrix 6×86
- Cyrix MediaGX
- Texas Instruments TMS9900
Which CPUs make up your list of Worst CPUs Ever Made?
(Score: 0) by Anonymous Coward on Thursday April 23 2020, @04:31PM (13 children)
Intel had the 8086/8088 pc market, but the market wanted more memory space.
So they built a new 80286 cpu with an mmu to provide more memory but unfortunately in a manner incompatible with existing PC s/w.
The 386 had a whole different, but compatible mmu.
(Score: 2) by isj on Thursday April 23 2020, @04:52PM (2 children)
Please elaborate.
The 8086/8088/80186/80188 had 16-bit segment:offset addressing and "all" programs assumed that the segments were overlapping with 16 bytes offset. There were no way out of that without either breaking compatibility, or virtualizing memory. The 80286 introduced protected mode where the segments were treated as selectors and memory could be moved around and a program could address a whopping 16MB. I don't think virtualizing the whole thing was feasible at that time (1982) due to complexity.
(Score: 1, Informative) by Anonymous Coward on Thursday April 23 2020, @08:36PM (1 child)
>Please elaborate.
At the time, most code needing more than 64k did arithmetic assuming the segment regs were 16x the offset regs. That gave 1M - what IBM took leaving 640k.
Intel decided that this was evil and that they 'owned' the architectural definition of the segment registers. They made the 286 with a 'beautiful' architecture which existing compiled code could not use. About the only folks happy about this was Mot with the 68k.
I remember when Intel came by to try to sell their 286 in the early 80's. As soon as they described the MMU, we had a talk about compatibility and they acted as if they had never considered it as a necessity. They were all proud of their beautiful architecture for segments. They had spent extra gates making something that the PC could market could not use. There were plenty of examples of mmu solutions in the minicomputer world and they just blew it. They learned the importance of compatibility and seemed to be more careful in the 386 and even to now.
The PS-AT and clones were about all that used the part. There were Unix variants that used the MMU, but to get back to DOS mode required a reset to the chip. (I think the keyboard process might have been involved.) Really a sad story driven by architectural arrogance causing them to ignore how their parts were being used.
Worst ever is a really high bar. Again, I nominate the 286. There are plenty of examples of processor designs that turned out bad, but this one is special because it started out ok and had a big market share and then went bad on purpose and almost lost the share. A really special case.
(Score: 2) by TheRaven on Monday April 27 2020, @09:04AM
sudo mod me up
(Score: 3, Interesting) by Acabatag on Thursday April 23 2020, @05:08PM
There were proprietary unix boxes that made proper use of the 80286
But the PC clone market barreled forward just using it as a bigger and faster 8088.
I am disappointed in the dominance of x86 processors in the list in the article. What a boring subset of cpus.
No mention of things like the Intersil/Harris 6100, a 12 bit processor that implemented the PDP-8 instruction set, and was done all in static CMOS so it could be clocked town to zero hertz for debugging if you wished.
PC clones are dull.
(Score: 2) by RS3 on Thursday April 23 2020, @05:54PM (8 children)
> So they built a new 80286 cpu with an mmu to provide more memory but unfortunately in a manner incompatible with existing PC s/w.
I'm not following you. By "existing PC s/w" you mean stuff that ran in "real mode", pretty much on DOS, right? Because there was no MMU in the 86/88, therefor there was no MMU s/w in DOS or the apps.
The 286 booted up in real mode, and as far as I know, and having used both for years, I never had any problems running any DOS software.
What I remember of the 286 was its MMU was clumsy, and frankly the IBM AT hw didn't properly handle Intel's design concept. For instance, to go from protected mode back to real mode, the 286 needed reset pin toggled. But that's just doing some internal CPU stuff, and an unconditional jump to the reset vector (address). Main RAM and the rest of the system didn't need to be hard reset (power-up wiped). But IBM hard-wired it to be a "wipe everything, full system reboot". Admittedly Intel's concept was clunky, but could have been done.
IIRC, NMI was something similar- not handled by IBM the way Intel had intended. IBM used it for a RAM parity error flag, but Intel had some other kind of things in mind. IIRC...
And the 286 didn't handle nested exceptions well. But I didn't really get into that level of programming much. I had 1 system running Xenix 286 and it ran well.
386 came out soon after and it was a whole new level of awesomeness, and we're still pretty much on that architecture, extended of course.
(Score: 5, Informative) by bzipitidoo on Thursday April 23 2020, @07:10PM (7 children)
An appendix in an old computer architecture textbook I studied rips the x86 for being a horrible architecture. The x86 part is a fairly sane and common load and execute, execute and store design. Still too many instructions though. Not enough registers, and too much overly specific register functionality. For instance, integer multiplication and division operations all have to go through one register, AL (or AX or EAX, of which AL is the low 8 bits). It's a huge bottleneck for multiplication intensive work, having to shuffle everything in and out of just one register. Then, if you thought the later FDIV bug was bad, how about the embarrassment of the integer DIV operation being so slow that it was often faster to do division with several shifts and add/subtract operations?
The instruction set has a lot of 1970s and 1960s cruft. Like, there are several instructions for working with packed decimal arithmetic. Thought it might be important that computers be able to handle base 10 arithmetic natively at the lowest levels. It's not. The 6502 also has some packed decimal arithmetic. Another very common type of instruction is general stack and call stack specific stuff such as PUSH, POP, CALL, and RETURN. They're just not an efficient way to do subroutine calls. Lose the stack, the CPU can run faster if it doesn't have to update a stack pointer a dozen times in succession. Like, if there are 2 PUSH instructions in a row, you'd really rather add 2 to the stack pointer once, instead of incrementing it twice. But you can't.
More x86 specific shortcut instructions that weren't good ideas was the string manipulation stuff, CMPSB, MOVSB, SCASB, etc. Near worthless for string search. Lots of overhead in pointer updates that may be useless.
The x87 math coprocessor was a real mess. They went with a stack architecture. You'd think, for the sake of consistency at least, they'd stick with a load and store design.
Finally, the support for a multitasking, multiuser operating system was lacking. The 8088/86 didn't have anything at all, of course. As you say, the 286 had to be reset. The 386 was better, but still lacked an easy means of implementing semaphores. No atomic TEST and SET kind of instruction. It could still be done, but it was a pain to implement, and slow. It's why the Linux kernel maintainers dropped support for the 386. The 486 was the first of the x86 series with all the essential ingredients. Intel ought to have implemented such an instruction much earlier, certainly in the 386, if not the 286. But they weren't listening to OS designers.
Even today, virtualization is an issue. We should not need VirtualPC software.
(Score: 3, Interesting) by maxwell demon on Thursday April 23 2020, @07:36PM (3 children)
The reason for the BCD instructions in the 8086/8088 (as well as some other special instructions like LAHF/SAHF) is the goal of a straightforward mechanical translation of 8080 code into 8086 code. Therefore it was essential that all 8080 functionality was either directly available on the 8086 (such as with BCD arithmetic) or there were fixed instruction sequences to achieve that (the 8080 always pushed the 8-bit accumulator together with the flags; this could be emulated on the 8086 with the LAHF/PUSH AX and POPAX/SAHF sequences). Also AFAIK the segmented architecture was for this reason: That way you could use 16-bit addresses in your programs (just as on the 8080), despite being able to access more memory in total.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by RS3 on Friday April 24 2020, @01:09AM (2 children)
I was thinking the BCD stuff was also for very simple systems that had 7-segment displays. Maybe? No?
(Score: 2) by maxwell demon on Friday April 24 2020, @06:57AM (1 child)
In the 8080, that may well be. In the 8086, the question wouldn't arise, since the compatibility restraints meant the support would have to be there anyway.
If Intel expected the 8086 (or the 8088) to be used in such systems, I have no idea. I would have expected embedded systems of that time to still go with 8 bit CPUs.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by RS3 on Friday April 24 2020, @03:19PM
Yes, I have to agree, and the 8085 filled that market nicely. You probably know on the 86/88, the address and data were multiplexed pins, so you needed several glue logic chips just to do anything with the micro. Maybe that was common then? Too lazy to look up other chip pinouts... Look how good we have it now with RAM and ROM and FLASH inside the micro.
(Score: 2) by RS3 on Friday April 24 2020, @03:40PM
Obviously all great points. Please remember, Intel had to sell these new chips to the microprocessor market. A CPU has to satisfy a lot of needs, including programmers. The programmers of the day did a lot of annoying BCD stuff, so having the instructions built in was super attractive. Same with string stuff. Even if it didn't get used a lot, it looked good being in there.
Absolutely agree re: x87 interface. Really don't understand what the thinking was there. Speculating: it allows a variable-length parameter list. Maybe that was it?
Re: push, pop- they're not just changing SP, but actually copy registers to RAM (or RAM to register), and it takes more instructions and clock cycles to do it manually. Even more so with calls and returns.
I'd have to research it, but iirc, especially in protected mode, many simple RAM operations take a huge number of clock cycles, and stack stuff is far fewer, so maybe that's part of the thinking there.
There were surely better CPUs, but IBM had many other considerations, including business competition. Most of us wish they had gone with Motorola. For many maybe even conflicting reasons, IBM went with Intel. Gotta wonder what the world would be like if they had gone with something else, RISC, or ???
(Score: 2) by TheRaven on Monday April 27 2020, @09:15AM (1 child)
That's *very* microarchitecture specific. Remember that the 8086 was not even really a pipelined processor. Up to a simple in-order pipeline, you can do each of those back-to-back and so the dense encoding for push and pop is a win. There was a period when they were slow because the pipelines they were each read-modify-write instructions on the stack pointer and that resulted in pipeline stalls. That period ended about 5-10 years ago and modern x86 processors lazily update the stack pointer (in some microarchitectures, push and pop don't actually store at all in the common case, they just write to a register bank that is only flushed if you explicitly modify the stack pointer or if you write to some locked cache lines holding the top of the stack). Now, push and pop are more efficient than doing stores and then modifying %rsp again.
In terms of encoding density, they're two bytes, which is about the smallest you can make the store of a register. With a general-purpose store you need at least the stack-pointer as the base, the register that you're going to use (you may special-case the stack pointer, but now you've defined a new set of opcodes and burned a lot of opcode space), the offset, and the register that you're storing, so getting that under two bytes is basically impossible. The only architecture that really manages it is AArch32, which has a 32-bit store-multiple instruction, which takes a base register, the increment direction (up or down, one bit) whether it's pre- or post-increment (one bit) and the base register (5 bits) and stores up to 16 registers in a single instruction. This is incredibly hard to implement efficiently on a modern microarchitecture.
sudo mod me up
(Score: 2) by bzipitidoo on Monday April 27 2020, @03:06PM
Lazy stack pointer updates? What changed to make that feasible? One reason for updating the stack pointer every time was in case an interrupt occurred. Interrupts complicate a lazy update policy, but at the current levels of billions of transistors, I guess it's no big deal any more.
I've read that brag before, that x86 is an efficient assembly code that uses a low amount of space for instructions. No, it's not. Data compression can shrink an x86 binary significantly. The move from 32bit to 64bit made matters worse, drove the code density down. It's one reason why many Windows tablets with 64bit hardware often come with 32bit Windows 10. Difference in size between the 2 versions is 2G, and that matters on a device that has only 32G of storage space. And you speak of burning up opcode space? The x86 architecture does that in spades. It's carrying around a lot of baggage. No doubt they would like to dump the decimal arithmetic instructions and reclaim that opcode space. It was so badly done, too. The 6502 has a flag. If it's set, an ADD instruction will treat the data value as a packed decimal number, if it's not set, it will treat the data value as a 2s complement binary number. Same opcode for both cases. The x86, in contrast, wastes opcodes on instructions to "adjust" the value after performing some math. There's an adjustment instruction for each of the four basic arithmetic operations.
And PUSH and POP are still bad ideas. Why? They're a special case MOV instruction, with some pointer manipulation that often is a waste of effort. So, why not just use a MOV instruction? The idea of "passing parameters on the stack", is awful if done with those instructions. PUSH a bunch of parameters, CALL the subroutine. Now the subroutine has to POP the return address that the CALL instruction just put on the stack, and save that somewhere, so it can then POP all the parameters, Same problem with passing a return value on the stack. POP the return address, PUSH the return value, PUSH the return address back on top of the stack, then do a RETURN. To avoid that, the subroutine is instead designed to just work directly with the values below the top of the stack, so that the return address need not be disturbed, and that can't be done with the POP and PUSH instructions. A program that does a lot of recursion can exhaust the stack space. The amount of stack space implicit in that system is just too inflexible. Could be wasting a lot of memory on stack space that is never used if it's too much, or forced to do some awkward stack space extension if it's not enough.