Former Intel CPU engineer details how internal x86-64 efforts were suppressed prior to AMD64's success

Intel Pentium 4
(Image credit: Shutterstock)

Earlier today on Twitter, AMD engineer Phil Park identified a curious nugget of PC architectural history from, of all places, a year-old Quora answer posted by former Intel engineer Robert Colwell. The nugget indicates that Intel could have beaten AMD to the x86-64 punch if the former wasn't dead-set on the x64-only Itanium line of CPUs. The historical context of this story and the comments within are fascinating, especially considering today's desktop CPU architectures, where "64-bit" is immediately understood to mean x86-64 — because who wants a computer that can't natively run most applications made for a PC?

To Intel's credit, it isn't that Intel Itanium processors completely did away with x86 software and architecture. However, they were intended to in the long run, especially as a measure of definitively striking down AMD in the marketplace. Unfortunately, this meant that the pure 64-bit architecture of Intel Itanium did not allow 32-bit (x86) applications to run natively, and the emulation solutions performed poorly. As a result, Itanium landed with a thud in the market despite being among the first to the 64-bit punch. Backward compatibility matters a great deal for big software and hardware purchases of any kind, but especially in the PC market. This fact was especially true in the server and enterprise markets where Intel targeted the Itanium CPUs.

As Intel's former chief x86 architect, Colwell knew this to be true, and thus designed the earliest internal versions of Pentium 4 CPUs to be x86-64 instead of mere x86 chips. Unfortunately, this design path was axed by the higher-ups at Intel, who clearly feared it would eat into or harm Itanium (much in the same way that AMD's debut x86-64 chips would end up doing anyway). In the face of repeated firing threats, the knowledgeable Colwell left the gates for 64-bit in Pentium 4, but fused off the functionality to make the inevitable return to x86 easier for Intel when the time came.

However, the story of Intel Itanium doesn't quite end at the launch of AMD64/x86-64 in 2003 despite the obvious chilling effect. Itanium still kept support and was iterated on until February 2017, and shipments didn't completely halt until July 2021. For some fringe scenarios, Itanium was very performant and even ideal.

But as Colwell knew, even back then, backward compatibility is king, especially on the PC, and especially in the enterprise. And don't even get me started on what consumers are willing to do for some good backward compatibility.

TOPICS
Christopher Harper
Contributing Writer

Christopher Harper has been a successful freelance tech writer specializing in PC hardware and gaming since 2015, and ghostwrote for various B2B clients in High School before that. Outside of work, Christopher is best known to friends and rivals as an active competitive player in various eSports (particularly fighting games and arena shooters) and a purveyor of music ranging from Jimi Hendrix to Killer Mike to the Sonic Adventure 2 soundtrack.

  • why_wolf
    Seems like the logical path would have been to release an x86-64 as a bridge alongside a pure 64 Itanium. Instead of trying to force people to be pure 32 bit or pure 64 bit.
    Reply
  • Thunder64
    Doesn't quitte pass the sniff test. It just happened to include a 64 bit version of x86 that was compatible with AMD64?
    Reply
  • AkroZ
    why_wolf said:
    Seems like the logical path would have been to release an x86-64 as a bridge alongside a pure 64 Itanium. Instead of trying to force people to be pure 32 bit or pure 64 bit.
    Itanium was able to execute x86 programs with a bridge to translate instructions for Itanium, but due to that the performances was worst than previous generation of x86 CPU. As all programs where in x86 then peoples doesn't want to buy it, then developers doesn't build programs for Itanium making it a flop.
    AMD was not invited to Itanium conference and licensing seemed unlikely, so they make their one solution.
    On x86-64 (AMD64) AMD added the 64 bits instructions to the 32 bits instruction set meaning the processors remain 100% natively compatibles with x86. Peoples were buying AMD Athlon 64 because they were more powerful than AMD Athlon when Windows for AMD64 was not published and no application were using 64 bits instructions.
    This has taken decades for 64 bits applications to take root (from 2003), in Windows "Program files (x86)" containing 32 bits applications is becoming smaller.
    Reply
  • EzzyB
    AMD was not invited to Itanium conference and licensing seemed unlikely,

    Here is the meat of it. Remember AMD made x86 chips on an old license (and a few court cases). It started way back when Intel couldn't make near enough 8088 processors to satisfy the market in the 80's.

    Intel believed that Itanium, breaking away from the x86 mold, would break AMD's license and thus ability compete going forward. The same license, BTW, had/has a technology sharing agreement. So Intel essentially got AMD 64 for nothing.
    Reply
  • thestryker
    Unsurprising that the x86 side of the company saw the writing on the wall and it was likely due to how far behind schedule Itanium was.

    While it didn't work out for Intel this was probably the best route for client computing. Intel having to use AMD's x86-64 implementation led to the long term licensing agreement between the two companies.
    Reply
  • tommo1982
    thestryker said:
    Unsurprising that the x86 side of the company saw the writing on the wall and it was likely due to how far behind schedule Itanium was.

    While it didn't work out for Intel this was probably the best route for client computing. Intel having to use AMD's x86-64 implementation led to the long term licensing agreement between the two companies.
    I saw Intel scrap numerous projects, precisely because they were dead set on making it Intel exclusive or some other hindrance for everyone else.
    It shows current problems are not a new development. It just cought up with them finally.
    Reply
  • zubeneschamali
    I was working at Intel (BX chipset, for example) during the PPro and P II period. I was personally present at meetings held with respect to the new arrival of the 64-bit architecture and most particularly to the meetings with Phoenix and Intel surrounding the development of a new BIOS and the operating system goals for these projects.

    At the time, Phoenix had two teams present at the table: their 32-bit group which essentially "ran the show" and the newly minted 64-bit group which exhibited far less power.

    In those meetings I personally attended around that time, the 32-bit group wanted the 64-bit group to operate entirely separately from them. The 32-bit group wanted their 32-bit BIOS to not be affected by what the 64-bit group was on about (the 64-bit group was clearly younger and more junior in skills) and as a consequence of that, the 32-bit group proposals were to either boot 32-bit or else boot 64-bit. But they declared that there would be no joint support in the BIOS. They wanted them to be entirely independent of each other and one or the other would be selected at boot.

    There were some serious implications that took some of my heart and enthusiasm away, and I was personally both shocked as well as quite vocal at these meetings. I had no impact.
    Reply
  • frogr
    Thunder64 said:
    Doesn't quitte pass the sniff test. It just happened to include a 64 bit version of x86 that was compatible with AMD64?
    did anyone claim it was AMD64 compatible. Intel may have had slightly different table on 64 bits
    Reply
  • Thunder64
    frogr said:
    did anyone claim it was AMD64 compatible. Intel may have had slightly different table on 64 bits

    It seems to implied it was or at least very close and that it was just "fused off". Seems unlikely.
    Reply
  • truerock
    OMG... year 2000...

    A typical 32-bit HP Windows server cost maybe $5,000
    A comparable 64-bit HPUX server cost $50,000

    Gee, I wonder why Intel and HP worked so hard to kill 64-bit Windows servers?
    Reply