Slashdot Mirror
Happy Birthday! X86 Turns 30 Years Old
javipas writes "On June 8th, 1978 Intel introduced its first 16-bit microprocessor, the 8086. Intel used then "the dawn of a new era" slogan, and they probably didn't know how certain they were. Thirty years later we've seen the evolution of PC architectures based on the x86 instruction set that has been the core of Intel, AMD or VIA processors. Legendary chips such as Intel 80386, 80486, Pentium and AMD Athlon have a great debt to that original processor, and as recently was pointed out on Slashdot, x86 evolution still leads the revolution. Happy birthday and long live x86."
The story is a few days early. I think you may have a rounding bug somewhere.
The demise of the x86 general architecture will not begin until Windows goes out of fashion. It's the only major platform strongly tied to that CPU architecture. x86 CPUs have been emulating the x86 instruction set in hardware for many years now. I guess, if they could, Intel / AMD / VIA and others would happily abandon the concept, because it leads to all sorts of complexities.
I spent over 16 yrs with Intel as a HW engineer. I saw many good decisions and a lot of bad ones too. Same goes for opportunities taken and missed. But their focus on cpu development cannot be faulted - they stumbled a few times but always found their focus again.
The other big success is their constant work on making the entire system architecture better, and basically giving that work to the industry for free. PCI - USB - AGP - all directly driven by Intel.
Its a bizarro place to work but my time their was not wasted
Its not the years, its the mileage
This is a case where just a couple of tweaks to the original x86 architecture might have had a dramatic impact on the industry.
The paragraph size of the 8086 was 16 bytes; that is, the segment registers were essentially multiplied by 16, giving an address range of 1MB, which resulted in extreme memory pressure (that 640K limit) starting in the mid 80s.
If the paragraph size had been 256 bytes, that would have resulted in a 24MB address space. We probably wouldn't have hit the wall for another several years. Companies such as VisiCorp might have succeeded at products like VisiOn, which were bending heaven and earth to cram their products into 640K, it would have been much easier to do graphics-oriented processing (death of Microsoft and Apple, anyone?). And so on.
Things might look profoundly different now, if only the 8086 had had four more address pins, and someone at Intel hadn't thought, "Well, 1MB is enough for anyone..."
Any sufficiently advanced technology is insufficiently documented.
Signed,
your great-great-great grandson,
Pentium
If brevity is the soul of wit, then how does one explain Twitter?
.model small .stack .data .code
message db "Happy Birthday!", "$"
main proc
mov ax,seg message
mov ds,ax
mov ah,09
lea dx,message
int 21h
mov ax,4c00h
int 21h
main endp
end main
My theory is that Itanium was secretly never created to replace x86; rather, it was designed to kill of all competitors to x86. Think about it: Intel managed to convince the vendors of several architectures (PA-RISC, Alpha come to mind) that IA-64 was the future. They proceeded to jump on Itanium and abandon the others. When Itanium failed, those companies (along with the hope of reviving the other arch's) went with it, or jumped to x86 to stay in business. Ta-da! x86 is alone and dominant in the very places IA-64 was designed for. Intel 1, CPU tech 0.
But wait, that's exactly what x86 is. In terms of code density it does pretty well compared to Risc. Modern x86s don't implement it internally, they translate it to Riscy uops on the fly and execute those. And over the years compilers have learned to prefer the x86 instructions that are fast in this sort of implementation. And, thanks to AMD it now supports 64 bit natively in its x64 variant. This is important. 64 bit maybe overkill today, but most architectures die because of a lack of address space (see Computer Architecture by Hennessy and Patterson). But 64 bit address spaces will keep x86/x64 going for at least a while.
http://cache-www.intel.com/cd/00/00/01/79/17969_codeclean_r02.pdf
If you know that the variable does not need to be pointer polymorphic (scale with the architecture), use the following guideline to see if it can be typed as 32-bit instead of 64-bit. (This guideline is based on a data expansion model of 1.5 bits per year over 10 years.)
IIRC 1.5 bits per year address space bloat is from Hennessy and Patterson.
At this point we have 30 unused bits of address space, assuming current apps need 32GB tops. That gives 64 bit x64 another 20 years lifetime!
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Happy birthday and long live, x86.
Oh my god, no ! Die already ! The design is bad, the instruction set is dumb, too much legacy stuff from 1978 still around and making CPUs costly, too complex and slow. Anyone who's written assembler code for x86 and other 32-bit CPUs will surely agree that the x86 is just ugly.
Even Intel didn't want it to live that long. The 8086 was hack, a beefed up 8085 (8-bit, a better 8080) and they wanted to replace it with a better design, but iAPX 432 turned out to be a desaster.
The attempts to improve the design with 80286 and 80386 were not very successful... they merely did the same shit to the 8086 that the 8086 already did to the 8085: double the register size, this time adding a prefix "E" instead of the suffix "X". Oh, and they added the protected mode... which is nice, but looks like a hack compared to other processors, IMHO.
And here we are: we still have to live with some of the limitations and ugly things from the hastily hacked together CPU that was the 8086, for example no real general purpose registers: all the "normal" registers (E)AX, (E)BX, etc. pp. are bound to certain jobs at least for some opcodes. No neat stuff like register windows and shit. Oh, I hate the 8086 and that it became successful. The world could be much more beautiful (and faster) without it. But I rant that for over ten years now and I guess I will rant about it on my deathbead.
Why couldn't the poster wait for June 8th to post this story... its *MY* birthday today dang it... x86 is totally stealing my day....
Jerk.
The 8086 predates the 8088, which was more popular and eclipsed it largely because IBM picked the latter for the original IBM PC. The 8088 is a modified 8086 that talks to the outside world using bytes rather than 16 bit words. It's otherwise completely identical.
PC manufacturers started switching over to the 8086 from around 1986 onwards (the Amstrad PC1512 was one example, dating to 1986) because of the slight performance improvement it offered without being as expensive as the 80286. For real-mode applications, and 8086s running at the same speed as the 80286, there was barely any performance difference between the two chips.
The old joke at the time was that the 8088 was being phased out in 1986-1988 because the '88 in 8088 was the expiry date...
You are not alone. This is not normal. None of this is normal.
Now die, you sputtering son of a whore. :D
I just read Slashdot for the articles.
I wouldn't do that, Dave...
i\hbar\dot{\psi}=\hat{H}\psi
IIRC 1.5 bits per year address space bloat is from Hennessy and Patterson. [...] At this point we have 30 unused bits of address space, assuming current apps need 32GB tops. That gives 64 bit x64 another 20 years lifetime!
Empirically, it hasn't been growing at anywhere near that rate. Ca. 1980 my TRS-80 had a 16-bit address space, and had enough memory to exhaust all of the addresses. Today, I'm using computers that have 1 Gb of memory, which is 30 bits worth of address space. That's less than 0.5 bits per year.
Also, in order to keep the actual used address space growing at a constant number of bits per year, Moore's law would have to continue indefinitely. But most experts are saying it will probably stop in 10 to 30 years. If we keep growing at 0.5 bits per year, starting now at 30 bits, and stop growing at the Moore's law rate in 2038, then we'll only be using 45 bits worth of actual address space.
It's hard to grok how big a 64-bit address space would really be. As a reality check, let's say that I want to own every movie that's ever been listed on IMDB, and store every single one of those in my computer's RAM simultaneously. If each one takes as much storage as a 5 Gb DVD, and IMDB has 400,000 movies listed, then that's a total of 2x10^15 bytes, which is 50 bits. That's 16,000 times smaller than a 64-bit address space.
As another example, the human brain has about 10^11 neurons. Each of those may be connected to 10^4 other neurons, so the total number of connections is about 10^15. That suggests that the total amount of RAM needed for direct, brute-force modeling of a human brain (assuming we knew enough to program such a model, which we don't, and had parallel processors that could run such a simulation, which we don't) might be about 10^15 bytes, which is a 50-bit address space. A 64-bit address space is 16,000 times bigger than that.
I think we're likely to see flying cars, Turing-level AI, and vacations on the moon before we need 128-bit pointers.
Find free books.
x86 succeeded for exactly one reason - volume. If IBM had chosen the 68K over the x86 we'd be using that today.
Back in the 80's it was a lot cheaper to develop a processor. They were considerably simpler and slower. The reason there were so many processor architectures around back them was that it was feasible for a small team to develop a processor from scratch. It was even possible for a small team to build, out of discrete components, a processor that was (significantly) faster than a fully integrated microprocessor, e.g. the Cray-1.
As the semiconductor processes improved and more, faster, transistors could get squeezed onto a chip, the complexity and the speed of microprocessors increased. Where you're at today is that it takes a billion dollar fab and a huge design team to create a competitive microprocessor. x86 has succeeded because there is such a torrent of money flowing into Intel from x86 sales that it is able to build those fabs and fund those design teams.
PowerPC, for example, was a much smaller effort than Intel back in the mid-90's. PowerPC was able, for a short time, to significantly outperform Intel and remained fairly competitive for quite a while even though the design team was much smaller and the semiconductor process was not as sophisticated as Intel's. The reason for that was that the architecture was much better designed than Intel, making it easier to get more performance for fewer $$. Eventually, however, the huge amount of $$ going into x86 allowed Intel to pull ahead.
The question is whether a processor running its native instruction set would be faster. From what I can tell the native instruction format of a modern x86 is wider than the x86 equivalent. Suppose the uops in the pipeline are 48 bit - a 32 bit constant and a 16 bit instruction. That is quite a bit larger than a typical x86 instruction. Wider instructions take more space in Ram and cache. You don't need to decode them, but the extra time fetching them kills the advantage.
And what is native is very implementation dependent. An AMD chip will have a very different uop format from an Intel one. Actually even between chip generations the uop format might change. Essentially Risc chips tried to make the internal pipeline format the ISA. But in the long run that wasn't good. Original Risc had branch delay slots and later superscalar implementations where branch delays work very differently had to emulate the old behaviour because it was no longer at all native. So if you did this you'd get an advantage for one generation but later generations would be progressively disadvantaged. Or you could keep switching instruction sets. But if most software is distributed as binaries that is impossible.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;