Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
posted by hubie on Thursday October 24, @09:17PM   Printer-friendly

Arthur T Knackerbracket has processed the following story:

Intel had a solution ready to add 64-bit features to the "classic" 32-bit x86 ISA, but the company chose to push forward with the Itanium operation instead. A new snippet of technology history has recently emerged from a year-old Quora discussion. Intel's former "chief x86 architect," Bob Colwell, provides a fascinating tidbit of previously unknown information.

AMD engineer Phil Park was researching the history behind the x86-64 transition, when he discovered the conversation. Colwell revealed that Intel had an inactive internal version of the x86-64 ISA embedded in Pentium 4 chips. The company's management forced the engineering team to "fuse off" the features.

The functionality was there, but users could not access it. Intel decided to focus on the 64-bit native architecture developed for Itanium instead of x86-64. The company felt that a 64-bit Pentium 4 would have damaged Itanium's chances to win the PC market. Management allegedly told Colwell "not once, but twice" to stop going on about 64-bits on x86 if he wanted to keep his job.

The engineer decided to compromise, leaving the logic gates related to x86-64 features "hidden" in the hardware design. Colwell bet that Intel would need to chase after AMD and quickly implement its version of the x86-64 ISA, and he was right. Itanium CPUs had no native backward compatibility with 16-bit and 32-bit x86 software, so the architecture was one of the worst commercial (and technology) failures in Intel's history.

[...] Bob Colwell made significant contributions to Intel's history, managing the development of popular PC CPUs such as Pentium Pro, Pentium II, Pentium III, and Pentium 4 before retiring in 2000. Meanwhile, today's x86 chips marketed by Intel and AMD still retain full backward hardware compatibility with nearly every program developed for the x86 architecture.


Original Submission

 
This discussion was created by hubie (1068) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by owl on Friday October 25, @03:07AM (3 children)

    by owl (15206) on Friday October 25, @03:07AM (#1378580)

    Well, unless they had the feature available and fused before the Prescotts... But that seems rather far fetched. No?

    It's possible they did have it. But given that at the time Intel was neck deep in the Itanium swamp as the official Intel blessed path to 64-bit processing, it seems unlikely. And if they secretly did, keeping the feature fused off would have been to prevent their x86 chips from (in their mind) cannibalizing sales of the Itanium.

    What is more likely is that up until AMD released the x86-64 spec, Intel had zero plans to move x86 to 64-bit (as that path was supposed to be by going Itanium) and they may have stuffed it into a P4 revision after the spec. was released but left it fused off (again, to prevent cannibalizing Itanium) while they waited to see what the reaction would be when AMD did finally release a chip. I.e., cover their bets. If 64 bit x86 took off, they could "unfuse" in a new P4 release and be able to offer a chip. If 64 bit x86 fell like a lead balloon, they could just leave it fused off and no one would be the wiser, and Itanium would still be the official "64-bit path".

    Starting Score:    1  point
    Moderation   +3  
       Insightful=2, Interesting=1, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 3, Touché) by JoeMerchant on Friday October 25, @11:37AM (2 children)

    by JoeMerchant (3937) on Friday October 25, @11:37AM (#1378602)

    I realize that 640k is all the RAM that normal users will ever need, but by the early 2000s it was pretty obvious, even without video applications, that 32 bits of address space was only sufficient for normal users because of the (falling) current price of RAM.

    Like 16 bits before it, once more than 2GB of RAM came down to mainstream price points, the pressure to expand 32 bit addressing would soon become overwhelming.

    At least we didn't have to endure a 286 like paged addressing mode as an interim step on the way from 32 to 64 bits.

    --
    🌻🌻 [google.com]
    • (Score: 2) by owl on Saturday October 26, @09:04PM (1 child)

      by owl (15206) on Saturday October 26, @09:04PM (#1378847)

      All true. But at the time Intel very much desperately wanted you to migrate to Itanium for 64-biit addressing in a CPU. If they (Intel) had wanted to expand x86 to 64-bits they could easily have done so themselves, likely well before AMD released their extension (which is the one we are all using today in x86 powered systems). Intel had no difficulty going from 8-bit (8080) to 16-bit (8086) to 32-bit (80386). They certainly could have made a 32->64 bit jump on their own.

      But Itanium was what was distracting them at the time (just like the iAPX432 before distracted them and is why there was even a 8086 in the first place). And that rabid attachment to Itanium let AMD one-up them in producing a 64-bit x86 extension.

      • (Score: 2) by JoeMerchant on Saturday October 26, @09:49PM

        by JoeMerchant (3937) on Saturday October 26, @09:49PM (#1378851)

        I think I was intel marketing hubris, trying to segment 32/64 as a consumer/professional demarcation.

        Problem is the consumer market is spear headed by budget performance enthusiasts who weren't going to settle for 32 bit for long.

        I wonder how much of the "32 bit is faster" press flak at the time was intel backed to push that concept

        --
        🌻🌻 [google.com]