|
|
Subscribe / Log in / New account

EPIC failure (to cancel the project when it was first failing)

EPIC failure (to cancel the project when it was first failing)

Posted Nov 11, 2023 14:27 UTC (Sat) by pizza (subscriber, #46)
In reply to: EPIC failure (to cancel the project when it was first failing) by farnz
Parent article: The push to save Itanium

I'd argue that Itanium was actually an overwhelming success.

It got multiple RISC server vendors to scrap their in-house designs and hitch themselves to Intel's offerings,


to post comments

EPIC failure (to cancel the project when it was first failing)

Posted Nov 11, 2023 15:21 UTC (Sat) by joib (subscriber, #8541) [Link] (15 responses)

Arguably industry consolidation was inevitable anyway due to exponentially increasing chip and process R&D costs, and the clock was ticking for the Unix vendors with their high margin low volume businesses. That Itanium delivered the coupe de grace to several of them was inconsequential, the ultimate winners being x86(-64), Windows and Linux.

One could even argue that without Itanium Intel would have introduced something x86-64-like sooner. Of course a butterfly scenario is what if in this case Intel would have refused to license x86-64 to AMD?

EPIC failure (to cancel the project when it was first failing)

Posted Nov 11, 2023 15:49 UTC (Sat) by pizza (subscriber, #46) [Link] (5 responses)

> Arguably industry consolidation was inevitable anyway

You're still looking at this from a big picture/industry-wide perspective.

The fact that Itanium was a technical failure doesn't mean it wasn't a massive strategic success for Intel. By getting the industry to consolidate around an *Intel* solution, they captured the mindshare, revenue, and economies of scale that would have otherwise gone elsewhere.

EPIC failure (to cancel the project when it was first failing)

Posted Nov 11, 2023 17:01 UTC (Sat) by joib (subscriber, #8541) [Link] (4 responses)

All of them, Itanium included, faded away into near irrelevance. So whether Intel created Itanium or not, the industry would ultimately have consolidated around x86-64/windows/Linux.

Unclear whether Intel profited more from Itanium compared to the alternative scenario where they would have introduced x86-64 earlier.

EPIC failure (to cancel the project when it was first failing)

Posted Nov 12, 2023 9:02 UTC (Sun) by ianmcc (subscriber, #88379) [Link] (3 responses)

If Intel had introduced x86-64 rather than AMD, would Intel have screwed it up?

EPIC failure (to cancel the project when it was first failing)

Posted Nov 13, 2023 12:41 UTC (Mon) by farnz (subscriber, #17727) [Link] (2 responses)

They'd have gone in one of two directions:

  1. Panic-implement x86, but 64-bit. This is basically what AMD did for AMD64, because they needed a 64-bit CPU, but didn't have the money to do a "clean-sheet" redesign; Intel could have done similar.
  2. A "new" ISA, based on IA-64 but built around OoOE instead of explicit compiler scheduling.

It'd be interesting to see what could have been if 1995 Intel had redesigned IA-64 around OoOE instead of EPIC; they'd still want compiler assistance in this case, because the goal of the ISA changes from "the compiler schedules everything, and we have a software-visible ALAT and speculation" to "the compiler stops us from being trapped when we're out of non-speculative work to do".

EPIC failure (to cancel the project when it was first failing)

Posted Dec 1, 2023 12:20 UTC (Fri) by sammythesnake (guest, #17693) [Link] (1 responses)

> Panic-implement x86, but 64-bit. This is basically what AMD did for AMD64, because they needed a 64-bit CPU, but didn't have the money to do a "clean-sheet" redesign

Although I'm sure the cost of a from-scratch design would have been prohibitive in itself for AMD, I think the decision probably had at least as much to do with a very pragmatic desire for backward compatibility with the already near-universal x86 ISA.

History seems to suggest that (through wisdom or luck) that was the right call, even with technical debt going back to the 4004 ISA which is now over half a century old(!) (https://en.m.wikipedia.org/wiki/Intel_4004)

EPIC failure (to cancel the project when it was first failing)

Posted Dec 1, 2023 13:17 UTC (Fri) by farnz (subscriber, #17727) [Link]

There's a lot about AMD64 that is done purely to reuse existing x86 decoders, rather than because they're trying to have backwards compatibility with x86 at the assembly level. They don't have backwards compatibility at the machine code level between AMD64 and x86, and they could have re-encoded AMD64 in a new format, while having the same instructions as they chose to implement.

That's what I mean by "not having the money"; if they wanted assembly-level backwards compatibility, but weren't short on cash to implement the new design, they could have changed instruction encodings so that (e.g.) we didn't retain special encodings for "move to/from AL" (which exist for ease of porting to the 8086 from the 8085). Instead AMD reused the existing x86 encoding, with some small tweaks.

EPIC failure (to cancel the project when it was first failing)

Posted Nov 11, 2023 22:48 UTC (Sat) by Wol (subscriber, #4433) [Link] (4 responses)

> Of course a butterfly scenario is what if in this case Intel would have refused to license x86-64 to AMD?

A butterfly scenario? Don't you mean an alternate reality?

In THIS reality, what would have happened if AMD had refused to licence x86-64 to Intel?

In reality, I think that that couldn't happen - I don't know the details of the intricate licencing deals (which I believe goes back to the Cyrix 686 - yes that long ago), but I think there are licence sharing deals in place that meant Intel could use x86-64 without having to negotiate.

Cheers,
Wol

EPIC failure (to cancel the project when it was first failing)

Posted Nov 12, 2023 7:30 UTC (Sun) by joib (subscriber, #8541) [Link] (3 responses)

> A butterfly scenario? Don't you mean an alternate reality?

It was a reference to the "butterfly effect",

https://en.m.wikipedia.org/wiki/Butterfly_effect

, meaning that seemingly minor details can result in major unforeseen consequences.

(which is one reason why "alternate history" is seldom a usable tool for serious historical research)

> In THIS reality, what would have happened if AMD had refused to licence x86-64 to Intel?

IIRC Intel was making various threats towards AMD wrt licensing various aspects of the x86 ISA. AMD was definitely in a kind of legal underdog situation. Inventing x86-64 put AMD in a much stronger position and forced Intel into a cross licensing arrangement, guaranteeing a long lasting patent peace. Which was good for customers.

EPIC failure (to cancel the project when it was first failing)

Posted Nov 14, 2023 10:12 UTC (Tue) by anselm (subscriber, #2796) [Link] (2 responses)

IIRC Intel was making various threats towards AMD wrt licensing various aspects of the x86 ISA. AMD was definitely in a kind of legal underdog situation. Inventing x86-64 put AMD in a much stronger position and forced Intel into a cross licensing arrangement, guaranteeing a long lasting patent peace. Which was good for customers.

There would have had to be some sort of arrangement in any case, because large customers (think, e.g., US government) tend to insist on having two different suppliers for important stuff.

EPIC failure (to cancel the project when it was first failing)

Posted Nov 15, 2023 13:27 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Wich is why I mentioned the 686. I don't remember the details, but there was some sort of deal (with IBM?) and Cyrix which meant the 686 was legally licenced, and I thought AMD had inherited that. Either way, I'm sure AMD had some sort of grandfather licence deal.

Cheers,
Wol

EPIC failure (to cancel the project when it was first failing)

Posted Nov 15, 2023 14:22 UTC (Wed) by james (subscriber, #1325) [Link]

It largely goes back to the early IBM PC days, when both IBM and AMD acquired second-source licenses so they could make chips up to (and including) the 286 using Intel's designs, including patent cross-licenses.

They weren't the only ones.

When Intel and HP got together to create Merced (the original Itanium), they put the intellectual property into a company they both owned, but which didn't have any cross-license agreements in place, which is why AMD wouldn't have been able to make Itanium-compatible processors except on Intel's (and HP's) terms.

EPIC failure (to cancel the project when it was first failing)

Posted Nov 13, 2023 1:01 UTC (Mon) by marcH (subscriber, #57642) [Link]

> That Itanium delivered the coupe de grace...

Coup: blow, strike, punch, kick, etc. Silent "p".
Coupe: cut (haircut, card deck, cross-section, clothes,...). Not silent "p" due to the following vowel.

So, some "coups de grâce" may have indeed involved some sort of... cut. Just letting you know about that involuntary, R-rated image of yours :-)

According to wiktionary, the two words have only one letter difference but totally different origin.

For completeness:
Grâce: mercy (killing) or thanks (before a meal or in "thanks to you")
Dropping the ^ accent on the â doesn't... hurt much.

EPIC failure (to cancel the project when it was first failing)

Posted Nov 17, 2023 11:10 UTC (Fri) by lproven (guest, #110432) [Link] (2 responses)

> One could even argue that without Itanium Intel would have introduced something x86-64-like sooner.

That's a good point and it's almost certainly true.

> Of course a butterfly scenario is what if in this case Intel would have refused to license x86-64 to AMD?

There is an interesting flipside to this.

There *were* 2 competing x86-64 implementations: when Intel saw how successful AMD's was becoming, it invented its own, _poste haste,_ and presented it secretly to various industry partners.

Microsoft told it no, reportedly with a comment to the effect of "we are already supporting *one* dead-end 64-bit architecture of yours, and we are absolutely *not* going to support two of them. Yours offers no additional improvements, and AMD64 is clearly winning, and so you must be compatible with the new standard."

(This was reported in various forum comments at the time and I can't give any citations, I'm afraid.)

For clarity, the one dead-end arch I refer to is of course Itanium.

Intel was extremely unhappy about this and indeed furious but it had contractual obligations with HP and others concerning Itanium so it could not refuse. Allegedly it approached a delighted AMD and licensed its implementation, and issued a very quiet public announcement about it with some bafflegab about existing mutual agreements -- as AMD was already an x86 licensee, had been making x86 chips for some 20 years already, and had extended this as recently as the '386 ISA. Which Intel was *also* very unhappy about, but some US governmental and military deals insisted that there were second sources for x86-32 chips, so it had to.

My personal and entirely unsubstantiated notion is that UEFI was Intel's revenge on the x86-64 market for being forced to climb down on this. We'd all have been much better off with OpenFirmware (as used in the OLPC XO-1) or even LinuxBios.

EPIC failure (to cancel the project when it was first failing)

Posted Nov 17, 2023 16:24 UTC (Fri) by james (subscriber, #1325) [Link] (1 responses)

This was reported in various forum comments at the time and I can't give any citations, I'm afraid.
I can.

Obviously, neither Microsoft nor Intel have publicly confirmed this, so a quote from Charlie is as good as you're going to get.

(And I can quite see Microsoft's point: the last thing they wanted was FUD between three different 64-bit instruction sets, with no guarantee as to which was going to win, one of them requiring users to purchase new versions of commercial software to get any performance, and the prospect that you'd then have to buy new versions again if you guessed wrong.

It would have been enough to drive anyone to Open Source.)

EPIC failure (to cancel the project when it was first failing)

Posted Nov 17, 2023 17:56 UTC (Fri) by lproven (guest, #110432) [Link]

Oh well done!

I used to write for the Inq myself back then, too. Never got to meet Charlie, though.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds