Itanium launched in 2001 (per Wikipedia); if anything, I'd say they overestimated how readily they could ditch x86. Of course, it might be that replacing x86 was a good idea and it was just that Itanium sucked (I'd accept that possibility, given the whole "needs a smarter compiler than exists" thing). But I do agree with the general feeling that Intel and MS both overestimated how solid/entrenched they were.
However, when AMD released AMD64 it killed this strategy. You could now buy a chip that natively ran x86 32 bit at full speed, plus be able to run code that could address more than 4 GB of RAM.
Once AMD64 came out, Itanium was a dead architecture.
[0] https://devblogs.microsoft.com/oldnewthing/20150727-00/?p=90...
This means that there is some hardware that checks condition that will not happen during normal course of events - compiler won't generate such code and write to register that reads zero is harmless.
That hardware stays there, occupies space (does not matter how little) and drains energy (no matter how little).
This part of hardware is utterly meaningless and shows how priorities were skewed during design phase. It also shows why Itanium was such a bad chip - features were piled up instead of being cut down.
RISC-V did cut down on features first (compare division overflow in RISC-V and OpenRISC) and has a process to add them. This is why RISC-V is easy to implement even in OoO variant and why it is being picked up by everyone and their dog.
You mean 64 GB limitations? 32-bit x86 could handle that much, and I'm sure it would have without AMD64.
All in all, not ideal, but I'm sure we would have managed with it a bit longer.
[0]: https://en.wikipedia.org/wiki/Address_Windowing_Extensions
The downfall of the Itanium had several reasons. They went beyond RISC with EPIC, a technology which had great theoretical promises, but had not been shown to yield those results in practise. Also, the project suffered from bad management and delays. Finally AMD pushed x86 just far enough forward to be a viable alternative.
In the beginning, the Itanium was an expensive, power-hungry monster, but it did perform quite well for heavy computations. It could have had a much better future, if Intel had not abandoned it - the software situation could have been much better, if for example Linux boards had been made available to all interested. The latest version only made it to a 32nm process, the transistor count being smaller than in a modern iPhone. So just redoing the same design in a cutting-edge process would make for a very interesting processor.
Intel misjudged both sides, for phones x86 compatibility was never necessary, for business machines, it absolutely is (for the largest number of customers, there have been exceptions).
HP saw the disaster coming and designed their own McKinley Itanium, but a bit later, and HP obviously didn't want Dell to have it.
The compiler support was not good outside HP-UX, if I remember correctly.
And then AMD64 happened, and Microsoft told Intel that there would be no further 64-bit PC instruction sets, and the market would choose between AMD and Itanium.
Cue the guillotine.
Non trivial amount of know-how and - if rumours to be belied[1] - direct design then went from Alpha team at Compaq to AMD, though Intel retained some of it (AMD already had been doing cooperation with Alpha, leading to the funky case of "jig it enough and an Athlon-MP motherboard might just run an Alpha and Athlon at the same time").
[1] - Once heard from semi-reputable source that an early K8 changelog entry contained "dropping support for VAX floating point formats". Unverifiable unless someone somehow publishes those docs, but it did fit with "That opteron looks suspiciously similar to EV7"
it sounds interesting
Intel should have known this, but you buy processors because they are faster or cheaper. These days the third rail is energy but it’s basically the same, if you pay more you want a lot more and “Different” costs. Itaniums where a whisker faster than their ia32 offerings at the time, they cost a lot more though, and they were different. Beyond that, it was like a geek designed the specs with out a market story, risc chips were coveted by x86 dorks because they had 32 registers to the x86’s 5 or 6, well ia64 had 128... If you’re just doing simple stack frame compiler work without full program optimization, how many functions need 32 registers? Let alone 128? everyone could see that you wanted to simplify things in order to put silicon where it mattered for longer term performance, mid to late 90s reordering conditionals for branch prediction was sort of hot in compiler dork and low level circles, well Merced fixed that by adding a lot of complex logic to take both branches and retire the wrong one. IBM, HP and Sun needed different reliability and serviceability features on their high end systems too, from the big enterprise metal perspective they were toy parts for PCs, but they cost more, didn’t run your existing software and weren’t 2x faster or anything like that. They didn’t take a holistic market view as they made it. Rather than work with ibm, sun and hp on those high end issues, they just went back to the lab and told them when the first parts would be out.
Not really sure what goes on inside intel, they have a lot of brilliant people. I suspect that they cannibalize themselves because nothing will ever be as successful as the x86 was when they owned every aspect of the part and package and things are decided to be a failure before they ship. With ia64 nobody asked why. Xeon phi, they gpu and machine learning stuff reflects that too.
As I understand it, these were influenced by SuperH, a 32-bit RISC design that uses 16-bit instructions, so two are always executing at once.
The busybox-armv7m Thumb2 binary is the smallest of all the compiled architectures.
Thumb2 appears to have been much more practical.
Actually their judgement there was correct. There dominance absolutely was tied to monopoly power, via "particular interfaces". Working on alternatives would have undermined the monopoly.
They error was thinking the monopoly wouldn't have eventually been undermined anyways. They upped the risk for more reward, and got bit.
This incidentally is another reason why monopolization is bad: even when it doesn't last indefinitely, it makes for shitty companies that refuse or cannot adapt, and will be stubbornly stick to their ways until more sudden failure. Stagnation and then a jolt is less growth, and irrespective of growth bad for society. No government should want this.
> In fact, Intel pointed out to me in the wake of the article’s publication that it possesses an ARM architectural license, the highest level of relationship with the British intellectual property (IP) licensing firm, which Intel retained when it sold its communications product line to Marvell in 2006.
Given the resulting impact (Intel being far behind in the smartphone market), it might qualify as the costliest Excel error of all time.
>At the end of the day, there was a chip that they were interested in that they wanted to pay a certain price for and not a nickel more and that price was below our forecasted cost. I couldn't see it. It wasn't one of these things you can make up on volume. And in hindsight, the forecasted cost was wrong and the volume was 100x what anyone thought."
https://www.theatlantic.com/technology/archive/2013/05/paul-...
If Intel managed to convince Apple to go x86, and they had low power chips competitive with ARM at the time, then that would be a different story.
You could even argue that it was a happy accident; Intel providing a high performance ARM core may have forced mobile competitors to react, producing high performance ARM chips of their own, and sped up the erosion of the x86 monopoly we're finally witnessing today by several years.
I doubt TSMC would have been able to afford to catch up to Intel without their current high volume business.
Apple pursued custom silicon very aggressively from the start, with the acquisition of PA Semi less than a year after the launch, and the first custom chip coming in the iPad in 2010.
Although with an Intel chip they wouldn't have needed to do this for performance reasons, Intel's fat gross margins would have been equally compelling.
If Intel was willing to design the chips and take TSMC sized margins on them, I guess they could have kept the iPhone business for years, but that isn't in their DNA.
I can't see Intel ARM iPhone chips as anything other than a shortly lived oddity.
By sending all that business to TSMC and Samsung, they were financing their rival's R&D.
If they were willing to do that, I totally buy in to your scenario. It would have been the right play with the benefit of hindsight.
But it would have represented the biggest shift in their business model since they dropped DRAM. Just agreeing to fab the iPhone 1 CPU wouldn't have been nearly enough.
>It was the only moment I heard regret slip into Otellini's voice during the several hours of conversations I had with him. "The lesson I took away from that was, while we like to speak with data around here, so many times in my career I've ended up making decisions with my gut, and I should have followed my gut," he said. "My gut told me to say yes."
https://www.theatlantic.com/technology/archive/2013/05/paul-...
Keep in mind that they didn't quit their Xeon Phi strategy until 2017, four years after that interview. The parallels are strong.
It's an equally valuable market to mobile, but they weren't willing to get their hands dirty, build a commodity GPU, and either a CUDA bridge ala ROCm or concerted effort on bringing OpenCL up to speed.
Instead, they tried for a decade to bring x86 to GPGPU, not for any technical advantage, but because if they can make it stick they can be an (at worst) duopolistic vendor.
They started with in order cores little better than a Pentium with massive vector units, and progressively improved them to Atom cores once it became clear how much work you'd have to do to port legacy x86 code on to them, at which point why not just port to CUDA?
Now the Xeon Phi torch will be passed to... absolutely standard Xeons with HBM. And they're building that general purpose GPGPU, but it's going up against a version of CUDA that's had a decade longer to mature and a nVidia with 102% of their market cap, instead of 9.9%.
The reason for this insanity is Intel realized just how profitable monopolies are, and they're willing to make risky (almost stupid) bets in the hope that they'll yield their next one. They're searching for the home runs with little enthusiasm or staying power for anything else.
This is the Intel I know, and it's not the kind of Intel that's willing to take crappy gross margins to fab commodity ARM chips. It's the kind of Intel that's going to try to do everything in its power to cram so very out of place Atom processors in to mobiles in the vein hope they'll catch on through a combination of incentives and temporary consumer insanity.
Which is exactly what they did try instead of the ARM thing, from 2008 to 2016. RIP.
If Intel did make ARM CPU for the original iPhone and other early mobiles, it would have followed the same trajectory as Intel's original SSDs. They'd be years ahead of their competition at launch, but left to stagnate as the rest of the market catches up, once Intel realizes they're actually going to have to work for their money with no sustainable advantage.
- He's probably flat-out lying, poopooing the data driven stuff to come off more human, humble, and sympathetic to the interviewer.
- If the numbers really did say they should stick to their monopoly, huge extra revenue be damned, then this is some model the FTC and "...but consumer prices!" crowd needs to be forced to grapple with.
Even Microsoft proved that they could build a featurific program without .Net, in VSCode. It’s an electron and JavaScript application. And, they were able to make it run everywhere.
Both Intel and Microsoft made some kind of categorical error in 1995-2005 in assuming that their dominance was tied to a particular programming interface. Intel clung to the x86 instruction set while Microsoft operated on a “Windows everywhere” mindset, first pushing Win32 and then .Net.
Wintel seems finally dead, and good riddance.