> This is great, except for that existing CPUs don't stall after issuing a load. Scoreboarding + prefetch are together capable of more than this "deferred load,

> This is great, except for that existing CPUs don't stall after issuing a load. Scoreboarding + prefetch are together capable of more than this "deferred load," and require less work from the compiler. If you have independent instructions following a load, any existing architecture worth its salt will notice that and execute them while the load is in progress. <Citation needed>. BTW, deferred loads were rediscovered as "decoupled load" (http://people.duke.edu/~bcl15/documents/huang2016-nisc.pdf http://people.duke.edu/~bcl15/documents/huang2016-nisc.pdf) and achieved a respectable 8.4% avg speedup. > It's potentially a neat idea to include the number of cycles until load retire in the instruction, but it's a joke to pretend that it's higher performance than what x86 does and will get you back all the performance lost by not speculating. That's not at all what's claimed. The entire idea is that you try to approximate OoO performance, not beat OoO performance. > I can't help but think that the mill architecture gets a lot of hype from a lot of people that don't know very much about computer architecture. There have been lots of great ideas that didn't pan out for general purpose computing, and I'm not sure that this vaporware architecture deserves to be thought about. I mean, it's been discussed as a valid idea by people on the P6 team (one of the first commercial OoOs), but what would they know? ¯\_(ツ)_/¯