> 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" [...] Except existing CPU's spend a lot of die space and power budget on doing speculative execution to hide the stall, the point of a deferred load is you don't need all this hardware to extract the same performance. > and require less work from the compiler. [...] Three words: static single assignment. If you can work out the dataflow of a function you already have everything you need to order loads in the most efficient way possible, this is why all of Mill Computing's work has been around LLVM because LLVM IR forces SSA by design. Hell, your compiler doesn't even need to think about the ordering if it relies on LLVM to do the native code generation, because the Mill backend is supposed to do all of this for you. > 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. Deferred loads alone aren't there to beat x86 in terms of performance, they're there to avoid needing all the costly out-of-order hardware while avoiding memory stalls that previous statically scheduled/in-order machines incur. There's other features in the architecture to bring better performance, but that's all around the VLIW-like design.