Not sure what you mean here.

Itanium was a VLIW and the Yale Bulldog compiler solved the VLIW code generation problem with trace scheduling back in the 80s. At this point, that's standard Dragon Book stuff.

Itanium failed to be sure but it wasn't the compiler. However I'll grant that the workload didn't match the EPIC architecture and the compiler. EPIC succeeded at scientific workloads.

As to whether Mill respects the current level of compiler tech a lot more I'd like to know more about that. They need to get their LLVM backend up and running.

Agreed: 'compiler technology' was a marketing promise/excuse over the fact that for any real-world problem, even the best possible code could not come near to the theoretical hardware performance. Intel had previously made the same mistake with the i860 but didn't learn from it.

So the hardware didn't match the workload and they blamed the compiler? That sounds plausible. I think they oversold the use cases for the Itanium though, they made it sound more like a general-purpose server CPU. The Mill might not be general-purpose either but they seem to be more honest about its niche (it's basically a DSP that happens to support general computation). Maybe that will be enough for it not to be a disappointment.

I bet if AMD didn't had come with their 64bit extensions, this laptop would be running on an Itanium processor.

I don't see how the Mill has any less reliance on modified compilers than Itanium. Instead, it seems to require more.

The Mill's history may be different because compilers actually advanced a lot since Itanium's launch, because it brings some arguably improvement over Itanium, or because the Mill's team is trying to write those compiler improvements, instead of making a partnership with Microsoft.

> I don't see how the Mill has any less reliance on modified compilers than Itanium. Instead, it seems to require more.

I don't know, some of the novelties in the Mill arch would seem to simplify compilers. For instance, no need for complex register allocation.

Other optimizations applicable to traditional CPUs either may not apply to the Mill CPU, or may need significant tweaking to work properly.

I got the opinion it would be much more complex, like deciding if saving a value is faster than reordering, and deciding the best place to request a load. It is also a large instruction word architecture, what means it's mostly similar from the compiler point of view.

The one thing that I think makes the Mill simpler is the no-value values mixed with lazy error conditions. I have no idea if those are powerful enough to compensate the rest.

Those issues are pretty easy.

For spilling: if a desired argument is less than one belt-length away then we directly reference it; between one and two away we reorder; and more than two we spill.

We place a load as soon as the address arguments are statically available. The compiler doesn't have to deal with aliasing, which is a large and bug-ridden part of compiling for other targets.

Lazy-error (aka NaR) means that there are no error dependencies in arithmetic expressions. Current compilers for other targets simply ignore such dependencies, relying on the "undefined behavior" rule. Mill is designed to not produce nasal demons :-)

Hm. I'd say Mill requires an even more ambitious compiler than Itanium. Itanium's large number of registers, for example, was friendly for existing compilers, while I don't know how compilers will handle the whole belt thing.

Incidentally, I don't think the Itanium compiler tech never materialized, it just materialized late. Itanium had a lot of other problems, but the later Itanium models really flew for certain workloads (SQL Server, in particular). After the first one (which was quite a dud and killed Itanium's reputation), Itanium was definitely not slow. The x86 emulator was slow, and AMD64 absolutely stole Itanium's lunch.