logoalt Hacker News

chasiltoday at 9:06 AM3 repliesview on HN

If I am correct, the Pentium Pro was the first "out of order" design. It specialized in 32-bit code, and did not handle 16-bit code very well.

The original Pentium I believe introduced a second pipeline that required a compiler to optimize for it to achieve maximum performance.

AMD actually made successful CPUs based on Berkeley RISC, similar to SPARC (they used register windows). The AMD K5 had this RISC CPU at its core. AMD bought NexGen and improved their RISC design for the K6 then Athlon.


Replies

twoodfintoday at 10:19 AM

Because of the branding change, history will remember the Pentium (P5). It was really the Pentium Pro (P6) that put Intel leaps ahead on x86 microarchitecture, a lead they’d hold with only a few minor stumbles for two decades.

Bob Colwell (mentioned elsewhere ITT) wrote a fascinating technical history of the P6: The Pentium Chronicles.

show 1 reply
squatertoday at 9:23 AM

Small correction, Pentium Pro was the first OoO microprocessor from Intel. Others like IBM POWER1 came earlier

show 3 replies
dspilletttoday at 11:44 AM

> The original Pentium I believe introduced a second pipeline that required a compiler to optimize for it to achieve maximum performance.

It wasn't a full pipeline, but large parts of the integer ALU and related circuitry were duplicated so that complex (time-consuming) instructions like multiply could directly follow each other without causing a pipeline bubble. Things were still essentially executed entirely in-order but the second MUL (or similar) could start before the first was complete, if it didn't depend upon the result of the first, and the Pentium line had a deeper pipeline than previous Intel chips to take most advantage of this.

The compiler optimisations, and similar manual code changes with the compiler wasn't bright enough, were to reduce the occurrence of instructions depending on the results of the instructions before, which would make the pipeline bubble come back as the subsequent instructions couldn't be started until the current one was complete. This was also a time when branch prediction became a major concern, and further compiler optimisations (and manual coding tricks) were used to help here too, because aborting a deep pipeline because of a branch (or just stalling the pipeline at the conditional branch point until the decision is made) causes quite a performance cost.