> Except, you know, the whole point of VLIW It's really indicative of the problem I'm talking about that so many people think the options are either a standard

> Except, you know, the whole point of VLIW It's really indicative of the problem I'm talking about that so many people think the options are either a standard, Intel Core-style OoO or Itanium-style VLIW. Not only is VLIW a massive range of potential things, and Itanium is not the natural implementation of it, but I never even said we should go with VLIWs! I'm personally more enamoured with CG-OoO style hierarchical reordering, though were rewriting the world possible I'd do something that exposed more of that to software (probably microthread style). > Provide real examples of how Itanium could have been done better. Although Itanium seems like a dead-end strategy to me, three things it got really wrong were: * software data misprediction recovery, * overly large register files, * compiler target locks in uarch decisions. (Please mind that it's been a while since I looked at the Itanium ISA.) The Mill is sort of what Itanium would be with all the rough edges sanded over, though it's sort of a moot point since the Mill will never exist outside of talks. Again, static schedules aren't the approach I'd advocate for, since there are some things they just can't do.