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."
I did wonder how they weren't sure how certain they were. Perhaps they weren't certain how certain they were but were certain how right they were. These guys should be building quantum CPUs by now with such confuddling principles of certainty.
I'm pretty sure x86 processors will still be in use for another 15 years at least. But, how much further will this architecture evolve? When will we see the demise of x86?
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.
Before the 8086 was released, I knew a V.P. of Technology who was extremely excited about it. Every time I saw him, he would tell me the date of release, and how much he was waiting for that date.
On that day, he was very sad. Intel made some horrible design decisions. We've had to live with them every since. Starting with the fact that assembly language programming for the X86 architecture is really annoying.
The docs for the 8086 stated that the interrupts below 20H were reserved, so guess what IBM used for the BIOS. The 8086 documentation was emphatic about not using the non-maskable interrupt for the 8087, and guess what IBM used. OTOH, Tim Paterson did pay attention to the docs and started the interrupt usage at 20H, but he wasn't working for either IBM or Microsoft at the time.
TFA doesn't get into the real reason that the x86 took off, that the BIOS for the IBM PC was cloned at least two or three times which allowed for much cheaper hardware (the original Compaq and IBM 486 machines were going for close to 10K$, where 486 whiteboxes were available a few months late for 2K$).
Actually Intel keeps trying(Itanium?) and AMD uses a compatibility mode.
The problem is as usual MSFT. which only runs on windows. yes I know a decade ago NT 4.0 did run on PowerPC, and even a couple of alpha chips.
Apple with a fraction a of the software guys can keep their OS on two major different style of chips PowerPC, and Intel x86, along with 32bit and 64 bit versions of both. Sun keeps how many versions of Solaris?
Nope but Vista only runs on x86. So X86 will remain around as long as it does.
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.
Yeah, they could move to an architecture with a simple, compact instruction set encoding which makes efficient use of the instruction cache and can be translated to something easier to implement on the fly with extra pipeline stages.
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 [amazon.com]). 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 [intel.com] 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!
Many of the shortest opcodes on modern Intel CPUs are for instructions that are never used. Compare this with ARM, where the 16-bit thumb code is used in a lot of small programs and libraries and there are well-defined calling conventions for interfacing 32-bit and 16-bit code in the same program.
Modern (Core 2 and later) Intel chips do not just split the ops into simpler ones, they also combine the simpler ones into more complex ones. This was what killed a lot of the original RISC archs - that CISC multi-cycle ops became CISC single-cycle ops while compilers for RISC instructions were still generating multiple instructions. On ARM, this isn't needed because the instruction set isn't quite so brain-dead. ARM also has much better handling of conditionals (try benchmarking the cost of a branch on x86 - you'll be surprised at how expensive it is), since conditionals are handled by select-style operations (every instruction is conditional) and which reduces branch penalties and scales much better to superscalar architectures without the cost of huge register files.
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 [imdb.com], 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.
pardon me for being such a math nerd, but I enjoy it so:
Each of those may be connected to 10^4 other neurons, so the total number of connections is about 10^15.
You're counting a lot of connections more than once (see permutations), not to mention your perilous assumption that a neural connection would only consume one byte in the hypothetical model.
If each one takes as much storage as a 5 Gb DVD, and IMDB has 400,000 movies listed [imdb.com], 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.
Firstly, what you mean is GB(bytes) not Gb(bits). 2e15 bytes would need a 51-bit address space, and 16 exabytes is a little over 9223 times 2e15 bytes.
I think we're likely to see flying cars, Turing-level AI, and vacations on the moon before we need 128-bit pointers.
128-bit linear addressing is not so useful, but you can introduce structure into the address so that (for example) the first 64 bits is a network address and the second 64 bits is the address of storage at that network address. This requires distributing the functionality of the MMU across various network elements, but is not especially novel, and from a software perspective is a special case of NUMA. (The special case lends itself to some clever scheduling based on the delay hints available in a further structured network address, especially if you generally organize things such that the XOR of two network addresses is a useful (if not perfect) delay metric from the perspective of an accessor).
This can even be done "in the small" on a non-networked host by allocating "network addresses" in the top 64 bits to local random access storage. You could look at this as a form of segmented memory (MULTICS style) or as an automatic handling of open(2)+mmap(2) based on (for example) a 64 bit encoding of a path name in the MSBs of the addresses. That is, dereferencing computer memory address 0xDEADBEEF00000001 automatically opens and mmaps a file corresponding to 0xDEADBEEF.
The opportunities to abstract away networked file systems without losing (or even while gaining) useful information about objects' characteristics (proximity, responsiveness, staleness) suggests that the address size used at the level of a primitive ISA that uses pseudo-flat addressing is mainly limited by the overhead of hauling around extra bytes per memory access. Pseudo-flat addressing can also in principle steal ideas from X86's various addressing models for dealing with addresses of different lengths.
Ultimately, the difficulty is in the directory problem. That does not go away even if you use radically different "addresses" for objects -- directories are already a pain if you use URLs/URIs for example, or if you use POSIX style filenames, or whatever, and the problem worsens when you have different "addresses" for the same logical object.
(Fun is when you have to figure out race conditions involving a structured set of bytes that is in a file shared out by AFP, SMB, NFS, and WebDAV, as well as being in use locally, with client software responsible for choosing the most appropriate available access method since there is no guarantee that any one of these methods will work for all clients at all times).
One possible approach to this is to insist that any reachable object is a persistent object, with a permanent universal name. If you have the permanent universal name, the object is either available to you or errors out. If you do not have the permanent universal name, you are out of luck unless you have a "locator" that points to it (or points to something that points to something that... points to it). This is in some ways much easier if what is pointed to by a permanent universal name is immutable, and if most such objects are compositions of primitive PUNs, the most primitive and common of which ("well known PUNs") can be cached or recalculated locally.
[cf Church encoding, Morgensen-Scott encoding and normalization in the computer science sense]
That translation of x86 instructions must have some performance cost to it. What Intel should do is expose both sets of instructions, act like an x86 if the OS expects it, or act RISC-like if the OS expects that. Then everyone can have their Windows installed, and it creates an opening for other operating systems. An OS that uses the native instruction set should be a little faster, giving people a reason to use it over windows. That will encourage MS to port windows the the new instruction set, and voila we are free of x86.
Actually Windows NT and its descendents are very portable - they were designed to run on i860, Mips, x86, Alpha and PPC. Even now they run on x86, x64, Itanium and PowerPC (in the XBox 360). All those ports probably made the code quite easy to port to new architectures. It's all the binary application software that isn't. Or rather it probably could be done if you had the source and time to do it, but lots of people have some very old applications that they don't want to buy again. E.g. Photoshop may be portable, but the copy of Photshop CSx I have on my desk isn't. And I don't to use the latest Photoshop version because it's slower and costs a lot of money. It's even worse if the company that made the app is out of business. But I buy a new copy of Windows every couple of years. So your hypothetical dual mode CPU could run Windows 7 natively. Some new apps would be native and some old ones x86. Actually x64 is already like this on Vista on x64 - the kernel is 64 bit and most applications will stay 32 bit, but x64 is no more native to the processor than x86.
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.
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
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.
While I'm sure thats how the script was repeated in Intel, suggesting great generosity ("And we give it away for free!"), what choice did they really have? IBM's whole Micro Channel Architecture fiasco showed what licensing did to adoption of new advances in system architecture and integration.
Hello,
Congrats on working at Intel for 16 years. Might I suggest that you document this period of activity into a small book? It would be great for the historical record.
Typing is a real pain. I suggest using the speech-to-text feature found buried in newer versions of MS Word or the IBM or Dragon speech programs. Train the system by reading a few chapters off the screen. Then sit back and talk about the Intel years, the projects, the personalities, the cubicals, the picnics, the parking lot, the haircuts, the water cooler stories, anything and everything. Don't worry about punctuation and paragraphing, which can be awkward when using speech-to-text systems. It's important to get a text file of recollections from the people who were there. Intel was 'ground zero' for the digital revolution that transformed the world in the last quarter of the 20th century. In fifty to a hundred years from now, people will want to know what it was really like.
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..."
What you're really saying is that "if only the chip had been a little more expensive to produce things might have been different." Adding a few little tweaks to devices was a heck of a lot more expensive in the 80s than it is today. The reality is that had Intel done what you asked, the x86 might not have succeeded this long at all.
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.
But would the extra RAM have been affordable to typical users of these programs at that time?
I remember fighting for expensive upgrades from 4 to 8 MB RAM at my workplace back in the early 90's. At that time PCs had already been able to use more than 1 MB for some years. So the problem you are referring to must have been years earlier where an upgrade from 1 to 2MB might probably have been equally expensive.
Kinda makes you wonder how different things might be or how much farther things might've come had a better architecture become the de facto standard of commodity hardware.
I've heard it said that most of the processing of x86 architectures goes to breaking down complex instructions to two or three smaller instructions. That's a lot of overhead over time. Even if programmers broke down the instructions themselves so that they were only using basically a RISC-subset of the x86 instructions, there's all that hardware that still has to be there for legacy and to preserve compatibility with the standard.
But I'm not a chip engineer, so my understanding may be fundamentally flawed somehow.
What may have been a limitation some time ago might start to be an advantage. I'm under the impression that there's already more than enough transistors to go around per processor, and there's nothing *special* that can be done with them, so it's just cramming more cores and more cache into a single chip. So parsing, splitting and parallelizing complex instructions at the processor may not be very costly after all. OTOH I bet it does reduce the memory bandwidth needed, which definitely is an advantage.
.model small.stack.data message db "Happy Birthday!", "$".code 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
Motorola always had better product, just worse marketing.. If IBM had chosen the 68K in their instruments machine, instead of the 8086/8085 from the Displaywriters, we would have saved ourselves from 3 decades of segmented address space, half a dozen memory models and non-orthogonal cpu architecture.
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 [wikipedia.org] 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.
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.
Perhaps this can be taken as a lesson that it is more fruitful to evolve the same design for the sake of continuity than to start fresh with a new design. The only really successful example I can think of a revolutionary design was OS-X, and even that took two major revisions (10.2) to be fully usable. Meanwhile, Linux still operates based on APIs and other conventions from the 70s, the internet has all this web 2.0 stuff running over HTTP 1.1, which itself runs on TCP -- old, old technology.
The first instinct of the engineer is always to tear it down and build it again, it is a useful function of the PHB (gasp!) that he prevents this from happening all the time.
Nonsense -- it's the LACK of a plural second-person pronoun in "proper" English that is disgusting (and inefficient). "Y'all" is the best hope we have for fixing this bug, and y'all should start using it as much as possible.
Happy Birthday! But do not be alarmed. That flashing red light on your palm is a natural part of our social order. On Lastday, please report to Carousel for termination at your earliest convenience. The computer is your friend. Oh, wait, you ARE the computer...
My first assumption, was tha it was too expensive for average use... but, after some investigating, I foudn that wrong (In my opinion)
June 1979, Intel introduces the 4.77-MHz 8086 microprocessor. It uses 16-bit registers, a 16-bit data bus, and 29,000 transistors, using 3-micron technology. Price is US$360. It can access 1 MB of memory. Speed is 0.33 MIPS.
Not from '78, but the first price I could find... so maybe you are thinking of the 80386, released in '87, not just the 8086...
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...
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.
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 reason PPC was able to beat x86 for a time was that around that time the x86 architecture was moving to being an ISA with the actual code done by a RISCy back end. The decode logic at that time was a significant percentage of the die space available, as process improvements came along that logic remained fairly static as far as total resource usage but that quickly became a smaller and smaller percentage of the available resources and so relative performance went up as the amount of the chip available for useful work rose. Today the more compact instruction density of a CISC front end helps increase cache utilization and thus better hide the huge penalty for accessing main RAM.
Intel's anniversary too (Score:5, Funny)
Nice self-reference double entendre Taco!
Might want to check your FPU (Score:5, Funny)
Re:Might want to check your FPU (Score:5, Funny)
Parent
Re:Might want to check your FPU (Score:5, Funny)
Parent
Re:Might want to check your FPU (Score:5, Funny)
Parent
How Long? (Score:5, Interesting)
Re:How Long? (Score:5, Interesting)
Parent
Intel made some horrible design decisions. (Score:5, Insightful)
On that day, he was very sad. Intel made some horrible design decisions. We've had to live with them every since. Starting with the fact that assembly language programming for the X86 architecture is really annoying.
Parent
And so did IBM with the PC (Score:5, Interesting)
TFA doesn't get into the real reason that the x86 took off, that the BIOS for the IBM PC was cloned at least two or three times which allowed for much cheaper hardware (the original Compaq and IBM 486 machines were going for close to 10K$, where 486 whiteboxes were available a few months late for 2K$).
Parent
Re:How Long? (Score:5, Interesting)
The problem is as usual MSFT. which only runs on windows. yes I know a decade ago NT 4.0 did run on PowerPC, and even a couple of alpha chips.
Apple with a fraction a of the software guys can keep their OS on two major different style of chips PowerPC, and Intel x86, along with 32bit and 64 bit versions of both. Sun keeps how many versions of Solaris?
Nope but Vista only runs on x86. So X86 will remain around as long as it does.
Parent
Re:How Long? (Score:4, Funny)
Parent
Re:How Long? (Score:5, Funny)
Parent
Re:How Long? (Score:5, Interesting)
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 [amazon.com]). 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 [intel.com]
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!
Parent
Re:How Long? (Score:5, Interesting)
Many of the shortest opcodes on modern Intel CPUs are for instructions that are never used. Compare this with ARM, where the 16-bit thumb code is used in a lot of small programs and libraries and there are well-defined calling conventions for interfacing 32-bit and 16-bit code in the same program.
Modern (Core 2 and later) Intel chips do not just split the ops into simpler ones, they also combine the simpler ones into more complex ones. This was what killed a lot of the original RISC archs - that CISC multi-cycle ops became CISC single-cycle ops while compilers for RISC instructions were still generating multiple instructions. On ARM, this isn't needed because the instruction set isn't quite so brain-dead. ARM also has much better handling of conditionals (try benchmarking the cost of a branch on x86 - you'll be surprised at how expensive it is), since conditionals are handled by select-style operations (every instruction is conditional) and which reduces branch penalties and scales much better to superscalar architectures without the cost of huge register files.
Parent
Re:How Long? (Score:5, Informative)
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 [imdb.com], 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.
Parent
math fail (Score:5, Informative)
Each of those may be connected to 10^4 other neurons, so the total number of connections is about 10^15.
You're counting a lot of connections more than once (see permutations), not to mention your perilous assumption that a neural connection would only consume one byte in the hypothetical model.
If each one takes as much storage as a 5 Gb DVD, and IMDB has 400,000 movies listed [imdb.com], 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.
Firstly, what you mean is GB(bytes) not Gb(bits). 2e15 bytes would need a 51-bit address space, and 16 exabytes is a little over 9223 times 2e15 bytes.
I like the direction of your ideas though.
Parent
Re:How Long? (Score:5, Interesting)
128-bit linear addressing is not so useful, but you can introduce structure into the address so that (for example) the first 64 bits is a network address and the second 64 bits is the address of storage at that network address. This requires distributing the functionality of the MMU across various network elements, but is not especially novel, and from a software perspective is a special case of NUMA. (The special case lends itself to some clever scheduling based on the delay hints available in a further structured network address, especially if you generally organize things such that the XOR of two network addresses is a useful (if not perfect) delay metric from the perspective of an accessor).
This can even be done "in the small" on a non-networked host by allocating "network addresses" in the top 64 bits to local random access storage. You could look at this as a form of segmented memory (MULTICS style) or as an automatic handling of open(2)+mmap(2) based on (for example) a 64 bit encoding of a path name in the MSBs of the addresses. That is, dereferencing computer memory address 0xDEADBEEF00000001 automatically opens and mmaps a file corresponding to 0xDEADBEEF.
The opportunities to abstract away networked file systems without losing (or even while gaining) useful information about objects' characteristics (proximity, responsiveness, staleness) suggests that the address size used at the level of a primitive ISA that uses pseudo-flat addressing is mainly limited by the overhead of hauling around extra bytes per memory access. Pseudo-flat addressing can also in principle steal ideas from X86's various addressing models for dealing with addresses of different lengths.
Ultimately, the difficulty is in the directory problem. That does not go away even if you use radically different "addresses" for objects -- directories are already a pain if you use URLs/URIs for example, or if you use POSIX style filenames, or whatever, and the problem worsens when you have different "addresses" for the same logical object.
(Fun is when you have to figure out race conditions involving a structured set of bytes that is in a file shared out by AFP, SMB, NFS, and WebDAV, as well as being in use locally, with client software responsible for choosing the most appropriate available access method since there is no guarantee that any one of these methods will work for all clients at all times).
One possible approach to this is to insist that any reachable object is a persistent object, with a permanent universal name. If you have the permanent universal name, the object is either available to you or errors out. If you do not have the permanent universal name, you are out of luck unless you have a "locator" that points to it (or points to something that points to something that
[cf Church encoding, Morgensen-Scott encoding and normalization in the computer science sense]
Parent
Re:How Long? (Score:5, Insightful)
maybe that will finally be enough to run vista at a decent speed.
[/bashing joke]
Parent
Re:How Long? (Score:5, Insightful)
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.
Parent
Doing it right -- mostly (Score:5, Interesting)
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
Re:Doing it right -- mostly (Score:5, Insightful)
While I'm sure thats how the script was repeated in Intel, suggesting great generosity ("And we give it away for free!"), what choice did they really have? IBM's whole Micro Channel Architecture fiasco showed what licensing did to adoption of new advances in system architecture and integration.
Parent
Re:Doing it right -- mostly (Score:5, Interesting)
Congrats on working at Intel for 16 years. Might I suggest that you document this period of activity into a small book? It would be great for the historical record.
Typing is a real pain. I suggest using the speech-to-text feature found buried in newer versions of MS Word or the IBM or Dragon speech programs. Train the system by reading a few chapters off the screen. Then sit back and talk about the Intel years, the projects, the personalities, the cubicals, the picnics, the parking lot, the haircuts, the water cooler stories, anything and everything. Don't worry about punctuation and paragraphing, which can be awkward when using speech-to-text systems. It's important to get a text file of recollections from the people who were there. Intel was 'ground zero' for the digital revolution that transformed the world in the last quarter of the 20th century. In fifty to a hundred years from now, people will want to know what it was really like.
Thank you.
Parent
A few tweaks, and... (Score:5, Interesting)
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..."
Re:A few tweaks, and... (Score:5, Insightful)
Parent
Re:A few tweaks, and... (Score:5, Insightful)
But would the extra RAM have been affordable to typical users of these programs at that time?
I remember fighting for expensive upgrades from 4 to 8 MB RAM at my workplace back in the early 90's. At that time PCs had already been able to use more than 1 MB for some years. So the problem you are referring to must have been years earlier where an upgrade from 1 to 2MB might probably have been equally expensive.
Parent
Overcoming Limitations (Score:3, Interesting)
Re:Overcoming Limitations (Score:5, Insightful)
Parent
Happy 29.9999999876547542 (Score:5, Funny)
your great-great-great grandson,
Pentium
Happy Birthday (Score:5, Funny)
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
The scary thing is (Score:4, Interesting)
Parent
not fair, this is too Do$$y (Score:5, Funny)
Parent
Intel has always been a P.O.S. (Score:4, Insightful)
Happy Happy Birthday (Score:4, Funny)
Die already ! (Score:5, Insightful)
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 [wikipedia.org] 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.
Re:Die already ! (Score:5, Insightful)
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.
The first instinct of the engineer is always to tear it down and build it again, it is a useful function of the PHB (gasp!) that he prevents this from happening all the time.
Parent
Re:Die already ! (Score:4, Funny)
Parent
June 8th (Score:5, Funny)
Jerk.
Happy birthday! (Score:5, Funny)
ARM architecture is 25 years old (Score:5, Interesting)
Report to Carousel (Score:5, Funny)
So? (Score:5, Funny)
Wake me up when it turns 32.
Happy Birthday! (Score:5, Funny)
Re:1978?? (Score:5, Interesting)
Parent
Re:1978?? (Score:4, Informative)
Oh, we suffered back then, believe me...
Parent
Re:1978?? (Score:5, Informative)
Parent
Re:1978?? (Score:5, Informative)
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...
Parent
Re:Itanium sank (Score:5, Insightful)
Parent
Re:Itanium sank (Score:5, Insightful)
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.
Parent
Re:Itanium sank (Score:5, Interesting)
Parent
Re:Legendary? (Score:4, Insightful)
I do believe that was first done by an x86 CPU, the NexGen Nx586 (the predecessor to the AMD K6...)
Parent