A new Intel Itanium (IA-64) emulator that boots Windows

Post by pjmlp » Mon, Jul 20, 2026, 5:37 AM UTC

wmf wrote: post #31

ColdStream wrote: post #23

Earlier quoted context omitted.

Itanium is yet another example of how difficult it is to fight software ecosystem momentum. 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.

Itanium 1 had hardware x86 compatibility and Itanium 2 had software x86 emulation just like Apple. It wasn't enough.

Post by pjmlp » Mon, Jul 20, 2026, 5:41 AM UTC

Joel_Mckay wrote: post #41

MBCook wrote: post #37

Earlier quoted context omitted.

The walled garden is an advantage of some sort, but they’ve also never made a bad call on switching architectures. 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)

>We don’t know what it would look like if Apple had chosen something that ended up like Itanium 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?" uni…

Post by seanmcdirmid » Mon, Jul 20, 2026, 7:23 AM UTC

bri3d wrote: post #20

Joel_Mckay wrote: post #14

Earlier quoted context omitted.

To be fair, most of ia64 performance issues were in the more complicated compilers. The chip itself had potential, but essentially abandoned the DOS/Windows market inertia. =3

No (sorry, I post this every time the Mythical Compiler Myth reappears), the problem with VLIW is that it fundamentally doesn’t work for anything with unpredictable memory access patterns, and modern general purpose computing has moved almost exclusively in this direction. For VLIW to work, you need to either guess correctly what is in cache or not have a cache at all; as soon as you mispredict what has been loaded,…

Post by qubex » Mon, Jul 20, 2026, 8:14 AM UTC

Joel_Mckay wrote: post #52

abbeyj wrote: post #48

Earlier quoted context omitted.

I think they meant EPIC https://en.wikipedia.org/wiki/Explicitly_parallel_instructio... , not EPYC https://en.wikipedia.org/wiki/Epyc .

Indeed, my point was not all chips do well with Desktop application loads. People were bad at handling parallelism with ia64, and still have problems today on better amd platforms with less janky compilers. The fact an $800 chip still can beat a $14000 chip at some tasks probably should tell people something about concurrency scaling overhead. =3

Post by eigenform » Mon, Jul 20, 2026, 8:23 AM UTC

monocasa wrote: post #60

bri3d wrote: post #54

Earlier quoted context omitted.

These worked well for “known” intra-task pointer aliasing situations, but if you don’t know what will be in cache due to preemption of any kind, you still don’t know how many cycles the speculative loads will take, so you get the same stall risks across a dependency hazard.

OoO cores have load stalls too after preemptions. Even something like a Apple M core basically has to stall if the load has to go out to the memory controller. The goal is to move far enough ahead in the stream that you can at least issue the next load, and advaned loads lets you do that. Some Intel cores will occasionally speculatively predict zero for a load, but AFAIK that got turned off as part of the Spectre mit…