GCC 14 dropping IA64 support is final nail in the coffin for Itanium architecture
- Reference: 1712917812
- News link: https://www.theregister.co.uk/2024/04/12/gcc_14_sinks_itanic/
- Source link:
Development work on version 14 of GCC is [1]still under way but there's an interesting paragraph in the Caveats section of the latest [2]change notes :
Support for the ia64*-*- target ports which have been unmaintained for quite a while has been declared obsolete in GCC 14. The next release of GCC will have their sources permanently removed.
IA64 is the official sobriquet of Intel's ill-fated Itanium architecture, which is why The Reg FOSS desk prefers it to "x64". x86-64, as invented by AMD and thus sometimes called AMD64, was not the first 64-bit architecture in the greater Intel-compatible family, and as for "x" – well, X [3]could mean anything .
This should not be a big surprise. As we reported while it was still in development, Linux kernel 6.7 [4]accepted a patch to remove IA64 support . There were, predictably, [5]howls of dismay about this but it happened anyway.
As we reported then, celebrated industry diplomat Linus Torvalds – who [6]marked the code orphaned in 2021 – offered a modest proposal for those who wanted to keep the Itanic afloat: maintain it out-of-tree for a year and we'll consider merging it back in again. This didn't happen, and now it won't if the default compiler used to compile the kernel no longer supports generating IA64 binaries.
[7]PumpkinOS carves out a FOSS PalmOS-compatible runtime environment
[8]Virtually and actually, LXC 6 and Incus 6 are here – both LTS versions
[9]VMS Software prunes OpenVMS hobbyist program
[10]Canonical cracks down on crypto cons following Snap Store scam spree
As we discussed when [11]examining Rust support in the kernel , an important angle of Linux kernel development is which compiler you use. The kernel is the largest single FOSS software project in the world, and you can't just throw it at any old compiler and expect a working result.
These days, there are two supported compilers: GCC, on multiple architectures, and Clang, which is based on LLVM, which primarily supports building kernels for x86-64 and Arm. About 20 years ago, you could [12]build the kernel with Intel C [PDF] – but as of 2021, Intel itself [13]switched to LLVM as the basis of its C/C++ compiler.
It's no surprise. Red Hat [14]let its Itanic version sink some 15 years ago. It has been on its way out of the compiler suite for ages as well: it was [15]deprecated in 2019 , and the Linux specialist site Phoronix [16]predicted it would be gone by GCC 11 . It took a little longer, but finally, it is disappearing into the inky abyss.
We thank a Reg reader, who'd prefer to remain anonymous, for the tip. He commented:
I spent much of 1999-2004 porting software to it, which was a prime waste of time and money. I had realised by mid-2001 that it was a turkey.
It looks like this particular [17]EPIC [PDF] is finally over. ®
Get our [18]Tech Resources
[1] https://gcc.gnu.org/pipermail/gcc/2024-March/243407.html
[2] https://gcc.gnu.org/gcc-14/changes.html
[3] https://www.theregister.com/2023/07/26/twitters_new_logo_meaning/
[4] https://www.theregister.com/2023/10/30/linux_kernel_6_7_rundown/
[5] https://www.theregister.com/2023/11/21/saving_linux_on_itanium/
[6] https://www.theregister.com/2021/02/01/linux_pulls_itanium_support/
[7] https://www.theregister.com/2024/04/11/pumpkin_os_foss_palmos/
[8] https://www.theregister.com/2024/04/10/lxc_6_and_incus_6/
[9] https://www.theregister.com/2024/04/09/vsi_prunes_hobbyist_prog/
[10] https://www.theregister.com/2024/03/28/canonical_snap_store_scams/
[11] https://www.theregister.com/2022/09/16/rust_in_the_linux_kernel/
[12] https://community.intel.com/legacyfs/online/drupal_files/article/146679/linuxkernelbuildwhitepaper.pdf
[13] https://www.intel.com/content/www/us/en/developer/articles/technical/adoption-of-llvm-complete-icx.html
[14] https://www.theregister.com/2009/12/18/redhat_rhel6_itanium_dead/
[15] https://gcc.gnu.org/legacy-ml/gcc/2019-06/msg00125.html
[16] https://www.phoronix.com/news/Intel-IA-64-GCC-Deprecation
[17] https://courses.cs.washington.edu/courses/cse471/01au/epic_cgi.pdf
[18] https://whitepapers.theregister.com/
"I want you to compile me like one your x64 programs."
All future Itanic code will have to be written in Rust.
"celebrated industry diplomat Linus Torvalds"
This is clearly some strange new usage of the word "diplomat" I was not previously aware of
Doffs hat to the late, great Douglas Adams
Re: "celebrated industry diplomat Linus Torvalds"
brought a smile to my face too!
Itanic
Glug.
Glug.
(silence)
Rolling rolling rolling ... rawhide
Love that EPIC ILP concept (thanks for the link!). Itanic may have been ahead of its time with it (and under-invested?) leading to a lack of buoyancy against alternative icebergs. Still, in 32-bit ARM, and in RISC-V with compressed instructions, compilers can generate a mix of 32-bit and 16-bit instructions, where the shorter ones can be read two-at-a-time from memory, and executed in parallel if sufficient execution ports exist, and there is no dependency hazard (or branch). I can imagine the same thing going with 64-bit or 128-bit instructions (aka 4-wide and 8-wide relative to 16-bits), with potential speed-up relative to uniform 32-bit ISAs.
Vector processing instructions that are so useful in HPC and AI/ML are already longer than 32-bits, and so standardizing on larger instruction widths, within the perspective of EPIC ILP, may just be where we end up heading anyways. Much as FP64, FP32, FP16, FP8, and FP4 are used in MxP and AI/ML, one could imagine EX128, EX64, EX32, and EX16 as "scalable" instruction formats in 128-bit compute (needed beyond Exascale, and good for vectors too). Itanic sunk, but the useful parts of the underlying concepts should certainly be fruitfully recycled into the next arch advancements IMHO.
RISC-V, in particular, seems to have quite a bit of room to expand instruction widths beyond 32-bits, making it a good potential test-bed for this (which could well solve its 1W2R design limitation in 32-bit).
Unloved & unmissed, even by it's parent
Worked for a company who had one of the early Intel Itanium dev boxes. One of our devs spent 6 months porting the viewer part of our product to it. We demoed the viewer at our world user conference to great indifference. We assumed there was even less interest in running our main product on Itanium. Shortly after that, the project was canned and the dev box was put into a cupboard. Fast forward a few years and the sysadmin was having a clear out. He contacted Intel about returning the dev box and was told they didn't want it back and to keep it. He offered it around the office but there were no takers.
> I spent much of 1999-2004 porting software to it, which was a prime waste of time and money. I had realised by mid-2001 that it was a turkey.
That makes me feel a little better for my year or so of Silverlight work.
Itanic?
Given the choice of coding IA64 or drowning, Jack would have thrown himself off that door even if there was space
I do wonder if IA-64 could become an open ISA along with so many others. And if so, Intel could use its foundry services to offer hobbyists a single board computer based on the ISA. It would be a massive comeback! And cheaper than trying to buy their way into RISC-V by acquiring Si-Five as they considered a few years back.
This is discussed in the linked post. The Reg has always had an unhealthy obsession with Itanium - mostly with dissing it - so if you fancy publishing it as an article, please knock yourselves out!
https://heartofwalesbikes.wordpress.com/2024/04/12/raise-the-itanic-could-intel-revive-ia-64/
Allegedly much of the design was inspired by the Russian Elbrus project.
https://www.theregister.com/2002/05/24/elbrus_the_itanium_slayer_returns/
https://www.theregister.com/2004/05/24/intel_elbrus_deal/
I think there are still VLIW chips selling in Russia. It's also quite popular in the DSP market, I learned last time around.
But this one? No.
The Titanic Architecture. Only sinking a bit slower than the other name-fellow.