Linux Looks To Retire Itanium/IA64 Support

[Dawn]

At first I found this confusing - if Itanium was made as recently as 2021, that implies there must have been customers to justify its production in 2020, yet the article suggest there haven't been any. I know there's no modern Windows OS to support it. The BSDs have IA64 support but they seem to struggle just to be fully caught up with x86-64, so I don't see why anyone would run their enterprise on IA64 with BSD. So, I looked it up - apparently the OS is HP-UX, which is some other Unix derivative. I knew HP was really the only reason Itanium was still alive but I didn't think they made their own OS for it. I can't say I'm surprised though - I'm sure Intel didn't want anything to do with it and clearly, nobody from any other market cares, so it was really up to HP to do all the work.


It would also explain why Intel thought they could compete against ARM in the mobile market using x86. So the funny thing is, I'd say Intel has had more reasons not to put all their eggs in the x86 basket than to do so.

HP had three operating systems for it.

HP-UX, the big one, got an abortive x86 port in 2009-2010 that never shipped to customers. NEC also shipped systems running UX (ones that weren't just HP rebadges - Oki, Hitachi, and Mitsubishi Electric rebadged HP's machines for the Japanese market, but NEC did true HP-compatible servers.) Basically all very large HP systems (anything capable of npars, essentially) ran UX, with a few running Windows for the very-large-MSSQL market. Beckton and DL980 made that irrelevant, though, so Microsoft pulled out. UX is still supported until the end of 2025 and a lot of users are in frantic migration mode.

VMS never sold huge volume on IPF and was almost all small systems, but they were very important to the customers who used them, especially industrial control. HP was in the process of euthanizing it when VSI bought the IP and did the x86 port.

Nonstop was low-volume but very profitable, especially in telco and finance (mainly debit.) HP ported it to x86 a while back.

There were also a few third-party systems...

Windows/IPF basically existed for the large MSSQL market, as mentioned, at a time where a credible 16-or-more-sockets x86 system just didn't exist. It was actually fairly successful in its little niche.

Linux/IPF was used most notably for HPC in the US, via SGI's Altix systems, but had some success in the big-box market, especially in Asia. Inspur was designing new Linux/IPF systems well into the 2010s as part of the PRC's "domestic mainframe" initiative. Fujitsu and Hitachi had limited success, mainly in the Japanese market, with Linux/IPF on their scale-up systems as a mission-critical option somewhere in between conventional RISC/UNIX and commodity.

Secure64 had an Itanium-specific microkernel OS for network appliances with some really neat features.

Bull and NEC both had mainframe operating systems (GCOS 7/8 for Bull, ACOS-4 for NEC) running emulated on IPF systems.

[coder]

This is the end of an era... not a super great era... but still. The Itanium was probably one of the most ambitious and innovated architectures of recent times. Unfortunately its also a cautionary tail of what happens when you let the architecture engineers run over the software engineers. You can make the most exceptional CPU, with all the most amazing features... that cant actually be programmed by known methods.

IMO, the ISA had more potential, but Intel got distracted by competing with AMD in the x86-64 arena.

For instance, people tend to confuse IA64 with VLIW, but it's not. IA64 could employ modern techniques like branch-prediction, speculative execution, and limited out-of-order execution, but these avenues were never explored. Nor did they ever augment the instruction set with vector extensions, like SSE or AVX.

Essentially the same thing happened to the Cell processor...

The Cell really needed a framework like OpenCL to effectively harness the SPEs. Unfortunately, it didn't exist when the PS3 was developed, and Sony got paranoid by the time people were actually experimenting with OpenCL on the PS3.

https://sites.google.com/site/openclps3/blog/geohotandtheps3

Sadly, things didn't turn out too well for poor Geohot.

https://www.cnet.com/home/smart-home/geohot-speaks-out-on-ps3-jailbreak-legal-battle/

No matter how awesome the CPU is, in design... if you cant actually program it with out investing billions in research... its basically a paper weight.

Eh, it wasn't awesome, though. Compile-time scheduling couldn't cover memory latency and even hyperthreading, which they eventually added, wasn't a sufficient band aid.

[stormcrow]

A former employer of mine had an Alpha-based HPC cluster back in the day. When it reached EOL it didn't go on the scrap heap, instead a nuclear power plant bought it for spare parts.

Probably takes that much power to run the Alphas they own

There is one thing going for OpenVMS, though. Almost no one is going to know how to write malware for it! I'm positive it can be done, just there's not enough people out there versed in VMS internals to make it a likely target. There is at least some minor comfort in using an obscure OS from a security standpoint. Script kiddies will never be after you. Only the very highly skilled and resourced.

[coder]

I really wish Itanium started off its life as an open source architecture the way RISC-V is. Its fortunes would've surely been different, as probably would ours.

RISC-V isn't "open source", but "open" and "royalty-free".

Anyway, this is another key point. Intel patented the hell out of the IA64 ISA. Nobody could ever build a clone, like what happened with x86. Now, if you're a big corporate customer, do you really want that degree of vendor-lockin, at least if there are viable alternatives (*ahem* AMD Opteron)?

[Dawn]

RISC-V isn't "open source", but "open" and "royalty-free".

Anyway, this is another key point. Intel patented the hell out of the IA64 ISA. Nobody could ever build a clone, like what happened with x86. Now, if you're a big corporate customer, do you really want that degree of vendor-lockin, at least if there are viable alternatives (*ahem* AMD Opteron)?

A senior figure in the PRC's domestic-server efforts claimed that they did a compatible domestic implementation of IPF silicon at one point. In general, PRC domestic-hardware claims have to be taken with a grain of salt, but I've always found it interesting.

[coder]

Intel is far more diverse than you would first think.

Currently they are bringing up Xe GPUs of all kinds,

Only after Xeon Phi failed, which was my point.

they have bought Altera for their FPGAs

They're not using Altera for the same kinds of things as x86, though. I meant specifically the ISA used by their programmable processors.

and they're in some kind of partnership with SiFive.

This is true. They actually were rumored to attempt an acquisition of SiFive. There could've been multiple strategies behind that. Maybe they saw it as the most credible threat from the RISC-V world, and were hoping to keep it bottled up in the realm of low-power embedded devices.

For now, they're using their partnership with SiFive to help attract business for their foundries. There are no real signs of them partnering to do anything in a market segment that would threaten x86, but that may one day come.

In the past they've probably done it all too, iAPX 432, Itanium, ARM and so forth.

All of those efforts pre-dated Itanium's failure. StrongARM is something they inherited from the DEC acquisition. i860 was promising but I heard Intel cancelled its successor after they realized x86 was far more profitable for them.

[coder]

Damn, 65k lines?! Isn’t it the compiler’s job to port architecture-agnostic code to architecture-specific instructions? Or is all that code just drivers?

It's been well-answered by ryao but I just wanted to add that you're thinking mostly of ISA, but not system architecture. Even if you implement 100% of your code in portable C, you still need to special-case how each different type of system handles booting, shutdown, virtual memory, interrupts, context-switching, sleep, etc. These aren't separate device drivers, but rather form an infrastructure that's used by the kernel and device drivers.

[coder]

There are 3 technologies you don't have the right to feel nostalgic about:
- OS/2 (aka a more retarded version of Windows that can't install itself and is a ploy by IBM to wrestle control from cheaper PC compatibles)

The people I knew who actually used OS/2 liked it! These included the first person I knew who ever ran Linux (back in the pre-1.0 days) and the software development team at my first job.

[jabl]

For now, they're using their partnership with SiFive to help attract business for their foundries.

That, and hurting ARM on the low end is certainly in their interest, as that means ARM has less $$$ to compete with x86 in markets where ARM and x86 overlap (e.g. the nascent ARM server market).

[rmfx]

Yeah time for code shower.