I’m sure there’s a joke about that being a huge leap in performance for Windows on IA-64 over the past 23 years waiting to be made from this.
VLIW works for single workloads. It works exceptionally well for single workloads with no or explicit cache like DSP. You can trade the footprint and complexity from OoO for a wider execution unit and more SRAM. It works well for HPC, too, for the same reason. But for anything where more than one process exists, it just really doesn’t work, and that’s most modern workload.
Itanium also has a unique set of self inflicted issues due in large part to Intel trying to make a wide variety of cross compatible parts, but IMO even if they’d got it right, it still would have died.
Even the 800lb guerilla Intel had to acknowledge amd64 was the next step, or it could end up a niche use chip like PowerPC.
The moral of the story is usability matters with consumer chip architecture. =3
Key relevant quote:
> In 1994, Intel and HP looked around and saw a wide variety of successful server CPU architectures like Alpha, MIPS, SPARC, and POWER. This annoyed them and they decided to make a new CPU that no one would want to use.
It’s the product of companies bent on doing all the wrong things.
Taking for granted that hardware backcompat (Itanium had this, too!) was a starting requirement…
I was working for a large bank and it was all windows, including production. We used to run WebSphere Application Server on Windows. I was looking for a dev server to run unit tests on, including integration tests which required an actual WebSphere instance. The infrastructure team said they had “a box” going spare and it turned out to be IA64 on Windows.
If my memory serves me correctly WebSphere only ran on windows for IA-64 up to 6 and we were running on 7.
I had to do a bit of hacking but I did manage to get it working using the dlls from the 6 version. It was fine for running integration tests and a pretty fast box considering.
Superficially it sounds a little crazy, but it's probably a lot less crazy than far more mainstream antipatterns (e.g. 'lets have our CI download all the dependencies from npm over the internet each time the build runs')!
Did running the unit tests on IA-64 ever flush out genuine issues that were 'working by accident' on x86?
EDIT: It looks like it might be this one: https://github.com/syunnPC/qemu-system-ia64
> Images for the Virtual Server for VPC (s390x architecture) are deprecated. Starting 28 February 2026, you can't create new instances from s390x images. Existing instances are supported until 20 February 2027. Any instances that remain after that date are deleted.
gcc maintained the ia64 target a long time for unclear reasons, but it was also still inefficient on other platforms. The FOSS compiler worked, but that was its only performance metric that counted for many users. =3
Not sure why you think the Intel compilers were a myth, as they are still around working far better than gcc in many use-cases:
"An Overview of the Intel® IA-64 Compiler"
https://webdocs.cs.ualberta.ca/~amaral/courses/605/papers/In...
Very few modern languages handle parallel scaling gracefully, and bodged on CUDA still isn't great either. As Moore's law ends, people have to reevaluate how they approach traditionally monolithic architectural design. =3
One example was "advanced loads" which allowed you to issue a load as soon as you knew the address, even in the face of potential pointer aliasing in the future, and then later complete the load when you actually hit a data dependency that requires it. https://devblogs.microsoft.com/oldnewthing/20150805-00/?p=91...
Another example is "speculative loads" which lets you issue a load before you even know if it's valid, such as unrolling a loop for an array that you don't know if is a multiple of the unrolled loop chunk length (and therefore might trap with a page fault if fully resolved). https://devblogs.microsoft.com/oldnewthing/20150804-00/?p=91...
If you're trying to create a compiler that approaches the effectiveness of this statically, you're condemned to do a ton of extra work (you're essentially writing an emulator for your CPU core, and then a compiler that uses that model to produce optimal code - even then, you might not be accounting for nondeterminism on the actual target machine, and some information is simply not accessible to you when you are not on the target machine)
It doesn't require determinism to work. And was designed by people that were quite aware of what the instruction stream looks like to an OoO core as it issues out of the rob.
Itanium had other sins than "magic compiler" woes, or even the inherent unpredictability of memory accesses. Mostly that it, like Cell, and Netburst was designed for a world where dennard scaling didn't end like a brick wall. As well as internal politics of Intel making it so that they were a bit loose and fast with die area.
1. VLIW exposes microarchitectural details, locking them in like an ABI. Updates to the microrachitecture will require changes to the ISA, thereby breaking backwards compatibility with every generation.
2. The dominant programming paradigm is sequential code, often just old C code with heavy pointer aliasing and little compile time extractable parallelism. This reduces static parallelism in the code base and shifts it into a runtime problem. The CPU discovers the dependencies at runtime instead. If you built a programming language that exposes more parallelism (think something like ParaSail), this problem wouldn't be as big as it is for C style programming languages.
Nobody will build a language for architectures that suffer from backwards compatibility problems, so why bother? VLIW is primarily suited for ASIPs and not much else.
It had potential but until you have an easy transition path, few will consider it. Apple figured that out during the 68K > PPC > X86 > ARM transitions.
Apple is an exception as it has always had a walled-garden ecosystem with the OS, so can force shifts in architectures unlike most companies. The M3/M4 Pro series with unified GPUs is probably the best design on the consumer market right now, but people are not leveraging it as much as they would have in other ecosystems.
Have a wonderful day =3
We don’t know what it would look like if Apple had chosen something that ended up like Itanium. It’s quite possible they don’t have the clout to pull it off.
(Maybe they should have gone Intel instead of PPC, but both were significantly better than m68k at that point)
Apple made a few mistakes, but mostly by trying to compete with doomed hype markets like AR/VR.
Some also ponder what the ecosystem would look like today if the Windows NT kernel had stayed on RISC like initially planned.
The "What if __ ?" universe are fun to imagine, but ultimately less important than the "What now?" universe we live in. =3
I was only talking about CPU transitions.
I only bought that Linux Unleashed book in 1995's Summer, because Windows NT wasn't good enough for doing university assignments at home, which used a mix of DG/UX and Solaris on the campus.
It seems more like they have a high willingness to switch architectures.
Predicting which one is better in the year that you do it or the couple of years after isn't that hard. The question is, where is it going to be in a decade or two?
Each time they picked a huge company you wouldn't have expected to fail in that year, first IBM, then Intel. But that's the problem with huge companies, after a few years on top they tend to get complacent and stagnate.
Now Apple itself is the big company, but it remains to be seen if they're not still going to end up on e.g. RISC-V within the next ten years or so.
PPC was significantly faster than m68k. Intel was significantly faster again. Finally ARM was yet again.
(ARM and Intel especially on laptops)
They could pay the emulation price and still come out equal or usually on top. Even when equal there were often other benefits, like reduced heat.
As I remember hearing Itanium was a dog with x86 code. It never got fast enough to compete let alone supplant it during emulation right?
So it wasn’t (meaningfully?) faster on recompiled code or new code. It wasn’t faster on new code. But it cost way more.
Not a winning combination.
Apple succeeds on their hardware transitions exactly because there isn't a clones market.
cbmuser•18h ago
userbinator•18h ago
rbanffy•18h ago
natas•17h ago
anyfoo•15h ago
rbanffy•3h ago
Another thing I want that I haven't figured out is to print to my network printers - they all do lpr and ipp, but Hercules direct to socket approach didn't work for me and I need to do more research on that. Ideally, the line in the config could be a pipe command where I could turn the page into PostScript to be netcat it to the printer. or massage it through a converter that took in an IBM line printer EBCDIC stream and spat out ASCII for a "normal" printer.
qubex•17h ago
pizza234•17h ago
Vibe coded software is the modern equivalent of the shovelware of the 90s.
userbinator•12h ago
I don't think so, especially as the latter was attempting to make a profit but this clearly wasn't done with a for-profit motive in mind.
ColdStream•15h ago
And yet, some folks have come to the battle and have ended up extensively using LLM's to code it. It is wild to see that these things can target such an obscure platform and get some decent results in a very short amount of time.
https://www.youtube.com/watch?v=WPxhuKTltsk
This is something that doesn't have any real economic value but many are more than happy to see happen.
monster_truck•15h ago
It's bone crushingly dry to try and figure this kind of shit out yourself, can do everything right according to every available reference and code comment only to get compiler and linker errors nobody has ever seen or posted about. Weeks and weeks of smashing your face against a wall until it gives. Now anyone can get twice as far in an evening. And that fuckin rules
Hard to not get a little hyperbolic about it... but I can't wait for everyone to exhaust their meme projects/ports and models to get just a bit better. Feels like we're about to have something of a golden age when everyone starts really making the stuff they've always wanted.
MBCook•13h ago
natas•18h ago
rbanffy•17h ago
natas•17h ago
nubinetwork•12h ago
rbanffy•8h ago
nubinetwork•6h ago
ChickeNES•16h ago
It booted Linux fine, was working on booting IPF EFI firmware when I got distracted by life and other projects.