IRIXNetwork

Posted 11-05-2025, 03:34 AM,

I found several articles in publications from the 1990s proving this claim was made via media channels. Keep in mind, Merced was meant to launch in 1998. 

This coupled with my general understanding and research into the Itanium timeline, means that the MIPS R12000 and later iterations were contingency plans for SGI. There is evidence that IRIX was going to run on IA-64 as well. 

In general there was a hell of a lot of hyping for the Itanium. I think it would have done a lot better if it had launched in 98 but in general I still think it would have failed in the long run. SGI's WHIRL opt in MIPSPro didn't seem to do well for Itanium. 

1. https://www.techmonitor.ai/technology/sg...d_mckinley

2. https://www.cnet.com/tech/tech-industry/...ew-server/

3. https://www.hpcwire.com/1998/10/16/mips-...a-sys-y2k/

Posted 11-05-2025, 10:57 AM,

Intel's massive portion of the market share is what keeps them afloat despite their best efforts to self destruct. Let's see what rabbits the Arm and Risc guys can pull out of their hats in the coming weeks/months/years... 

Posted 11-05-2025, 01:58 PM,

I don't care about politicizing Intel. The Itanium system was not designed to replace x86, blame HP for its existence as it was a Fort Collins Design Center concept.

It was a PA-RISC and SPARC replacement, but of course MIPS got rolled into it because SGI couldn't afford to continue MIPS development.

Posted 11-06-2025, 12:27 AM,

(11-05-2025, 01:58 PM)Raion Wrote: I don't care about politicizing Intel. The Itanium system was not designed to replace x86, blame HP for its existence as it was a Fort Collins Design Center concept.

It was a PA-RISC and SPARC replacement, but of course MIPS got rolled into it because SGI couldn't afford to continue MIPS development.

The story I remember, and my recollection could very well be faulty/inaccurate, in fact it probably is - is that there was an internal struggle within Intel between factions hoping Itanium would be a clean slate and factions insisting that it be fully backward-compatible with x86. The workstation/server CPU industry is tough, hence MIPS tiny remaining niche in the embedded market.

Posted 11-06-2025, 01:17 AM,

x86 emulation was a marketing trick. It was never a serious feature.

Posted 11-06-2025, 09:48 AM,

(11-06-2025, 01:17 AM)Raion Wrote: x86 emulation was a marketing trick. It was never a serious feature.

Well then the marketer was probably fired, since Itanium was about as successful as the Titanic...  

Posted 11-06-2025, 01:31 PM,

Itanium failed because it was a 1990s design released in the 2000s that failed to predict the processor trends, and the behavior of Intel alienated many vendors. HP and several Japanese companies were the only volume customers as a result. SGI Itanium was teeny tiny market percentage.

Two major fuckups, one architectural, one strategic:

1. Itanium was an in-order CPU design. This means it cannot execute instructions via branch prediction. It relies solely on the compiler to produce a viable instruction path.

2. Neither Intel nor HP produced a free, open source compiler optimized for Itanium. It didn't have to be a GCC compatible one. It could have been a cut down ICC or something. GCC would never implement its own IR/optimization routines solely for one arch.

Posted 11-06-2025, 07:54 PM,

(11-06-2025, 01:31 PM)Raion Wrote: 2. Neither Intel nor HP produced a free, open source compiler optimized for Itanium. It didn't have to be a GCC compatible one. It could have been a cut down ICC or something. GCC would never implement its own IR/optimization routines solely for one arch.

Yet GCC did; a few optimization passes introduced in gcc 4.2 are specific to Itanium (and do not run on other targets), with significant instruction scheduler changes. Too bad this was in the years 2005-2006 and already too late to save Itanium from drowning.

Posted 11-07-2025, 12:40 AM,

(11-06-2025, 01:31 PM)Raion Wrote:  GCC would never implement its own IR/optimization routines solely for one arch.

The core GCC team won't, that's certainly true, but as is the case with MIPS, FSF will accept code for obscure architectures - They've certainly been known to threaten legal action against organizations that don't bow to the will of the GPL. Or rather, they would if the FSF actually had any GPL attorneys. I don't think they do. Typically all it takes is a little Stallman sword-rattling for any given org to buckle to the will of the FSF. But for those wishing their code to be as freely available as possible, public domain seems like the obvious choice. I put my Julian Braun replica casino blackjack simulation into the public domain...

Posted 11-07-2025, 06:02 AM,

(11-06-2025, 07:54 PM)miod Wrote: Yet GCC did; a few optimization passes introduced in gcc 4.2 are specific to Itanium (and do not run on other targets), with significant instruction scheduler changes. Too bad this was in the years 2005-2006 and already too late to save Itanium from drowning.

My apologies I did not mean to spread misinformation; I had no knowledge of the specific fact. That said, what people smarter than me have told me is that Open64 nor GCC really had the resources or even the architecture to fully incorporate a highly optimized ICC-style intermediate representation and optimizing compiler routine the way that they did. The fact that in 2001 HP nor Intel bothered was a huge blow.

A lot of my information around Itanium has its roots in a certain good friend engineer with a passion for Itanium. They are not particularly unrealistic about the architecture, but they have a specific mission of "people should judge it based on objective grounds"

As they told me:

Scale of 1-10:

Open64: 2
GCC: 4
SGI Pro64 (the commercial version): 3-4.5 on a good day.
Intel ICC: 9
HP's aCC: 9.5

Of course if I am mistaken about any of the above information I am sorry. It is nice to have someone who's a veteran of this who can actually verify and clarify anything that I make a mistake on. Good to see you, miod. Please don't be a stranger.