News Focus
News Focus
icon url

wbmw

09/01/03 7:43 PM

#12514 RE: chipguy #12504

Chipguy, I've always liked those articles done by Paul DeMone. I read almost every one that gets posted on the RealWorldTech site. I hope he decides to post more of them. Personally, I think a good followup to MPF2003 might be a good idea. There should be quite a lot of info coming out this year on new processors.
icon url

sgolds

09/02/03 9:58 AM

#12537 RE: chipguy #12504

chipguy, interesting article. I particularly like this explanation -

The one market that RISC never got even a toehold in was the IBM-compatible PC market. Even the most popular RISC processors were manufactured in much smaller quantities than Intel x86 devices and could never effectively reach high volume PC price points without crippling their performance. Even if they could be built as cheaply as x86-based PCs, RISC processors couldn't tap into the huge, non-portable software installed base except under emulation, which more than wiped out the RISC performance advantage. And much credit must go to Intel Corporation. It aggressively invested in both developing complex and innovative new ways of implementing the hopelessly CISC x86 ISA, and ensuring these would be implemented in each new generation of CMOS processes one or two years before any RISC processor. The potent combination was sufficient to ensure that x86 processors were never behind RISC processors in integer performance by a factor of two or more. This was a sufficient factor to ensure the continued loyalty of independent software vendors (ISVs) offering PC-based applications. An uneasy peace settled in between the two solitudes of x86 PCs and RISC high-end servers and workstations until late 1995 when the Intel Pentium Pro (P6) processor appeared.

The launch of the Pentium Pro processor was the computer industry equivalent of a Pearl Harbor type surprise attack directly against the RISC heartland: technical workstations and servers. The Pentium Pro combined an innovative new out-of-order execution superscalar x86 microprocessor with a separate high speed custom SRAM cache chip in a multi-chip module (MCM)-like package. The biggest surprise of all was the fact that the 0.35 um version debuted simultaneously with the expected 0.5 um version and more than six months ahead of Intel's public product roadmap. This allowed the Pentium Pro to reach a clock speed of 200 MHz and integer performance levels that briefly eclipsed the fastest shipping RISC processor, the 0.5 um Alpha 21164.

The Pentium Pro's integer performance lead didn't last long and its floating point performance was still well behind nearly every RISC processor but this didn't reduce the psychological impact. Any hope that RISC microprocessor vendors had of being able to reach PC price points with their much smaller volume chips, while offering a large enough integer performance advantage (x86 processors already provided sufficient floating point for nearly all PC-type applications) to entice the market away from x86 was pretty well extinguished.


That says it a lot better than I could have!

The next page has something interesting, but it misses the point:

At the same time Intel is reaping the benefit of a long-term effort at convincing the marketplace that the difference between RISC and CISC processors was somehow shrinking. This first started when Intel released its i486 processor, and it was widely reported as having a "RISC integer unit". Despite the utter meaninglessness of this claim (does the 486 execute RISC integer instructions?), it was the thin edge of the wedge, and the beginning of a growing period of intellectual laziness within the computer trade press that has largely corrupted the terms RISC and CISC for most of the computer buying populace to this day.

The campaign to obfuscate the clear distinction between RISC and CISC moved into high gear with the advent of the modern x86 processor implementations employing fixed length control words to operate out-of-order execution data paths.


The point isn't that CISC was somehow becoming RISC, but rather that optimizations which, according to many, required RISC in fact did not. RISC was more than reduced instruction set - in fact, that part actually caused larger code sets and slowed down processing. The theory was that it permitted faster execution of simpler instructions and made out-of-order processing feasible. When Intel was able to match speed on CISC and also introduce out-of-order processing, it disproved the very reason for RISC's existance!

icon url

sgolds

09/02/03 11:07 AM

#12546 RE: chipguy #12504

chipguy, I had an opportunity to read the second article, also. It does not address an important point - AMD's 64-bit mode corrects many of the ISA faults in that it expands the register set and drops earlier compatibility modes, depending on the mode chosen. (K8 architecture has those modes when the processor is run in 32-bit mode. In 64-bit long mode, the processor runs as a 64-bit processor, no compatibility. In compatibility long mode, 32-bit and 16-bit legacy code is supported. Legacy mode runs like existing x86-32 processors.)

This means that, going forward, it is 'goodbye segmentation' and hello to a simpler processor, perhaps with even more registers in future generations. This opens up the possibility of future optimizations for 64-bit code which would not be available for 32-bit code run with a compatibility selector. (I suspect that K9 will start introducing such optimizations.) The architecture can grow without many of the older limitations.

When you couple this with the article's conclusion, you see that even this IPF enthusiast gives AMD a long time to establish its own 64-bit solution:

Conclusion: At Best a Long Goodbye

Every military analyst knows that it is far easier to assess the technical and operational capabilities of a secretive entity than its intentions. Intel likely has plans for a number of contingencies, and the replacement of x86 is undoubtedly one them. But if Intel does decide to replace x86 on the desktop with IPF, and the technical scenario I have painted proves accurate, the overwhelming presence of x86 in desktop computing would not start to diminish until 2005 at the earliest and would remain significant during a long period of overlap, perhaps extending even into the next decade.


So there you have it: The beauty of the AMD64 approach is that is does answer the main issues this author addresses while providing full speed compatibility with older applications, and by the author's own timeline, AMD has time to establish their solution.