Live data from Hacker News

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

raymii.org

81–83 of 83 posts

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

#81
post #20

Earlier quoted context omitted.

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,…

Honestly, you're conflating two things. 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 p…

I don't think I'm really conflating anything, and I don't agree with your thesis even though I agree with individual points.

1) Yes, unless you add abstraction at the ABI/ISA level in hardware or microcode, which then defeats the point of VLIW to some extent. I mention this in my comment; Itanium in particular was hamstrung by trying to patch over this. This is one of the "sliders" you're dragging with VLIW; trading floor plan for cross compatibility.

2) Well, kind of, but this is just the Mythical Compiler I discussed in my own parent comment, regardless of language, and I find this argument tangental to the core issue. Yes, C makes things bad by encouraging both aliasing and pointer-chasing, but one can also argue that a sufficiently advanced compiler can discover the intra-program hazards and prefetch accordingly (see monocasa's discussion); this is moving where the parallelism is expressed, but isn't patching the fundamental issue.

Overall, I don't think the issue is that nobody will build a language or compiler for an architecture with compatibility problems. We see good compilers and lots of language research in this space for DSP and AI workloads. I still believe that the fundamental issue is that VLIW is not suited for general purpose computing workloads due to cache residency issues caused by context switching.

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

#82

Earlier quoted context omitted.

Yes, I'm pointing out the fact that the programmer is expected to manage the ALAT, and that these machines do not automatically recover from cases where your advanced loads are incorrect. That process is expected to be part of the instruction stream, and [we have collectively learned that] that's an expensive feedback loop. Yes, it doesn't require determinism to work, but it means that your performance is especially…

You didn't generally need to manage the ALAT as a programmer. You can, in the same way that you can manually manage reservation station port residency as a programmer in an OoO core to get maximum throughput, but neither of those are required in normal programming.

Sorry, when talking about things from the hardware's point of view, I'm in the habit of using the word "programmer" to also mean "the compiler"!

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

#83

This is much harder problem than most CPU emulators as IA-64 isn't really just another ISA. EPIC most significantly allows the RE which seems like the main implementation challenge. Does the emulator model the RSE or are there shortcuts for Windows compatibility? Also, which Windows model is booting?

What do you mean by RE and RSE, please?

Reverse Execution comes to mind, but I hardly believe that to be the case here.

Post reply on HN