On the Mill, you tell it the address that you want to read and when you want to read it. So you could issue a load for XYZ as soon as you know what XYZ is and if there's a subsequent store to XYZ that will update the result so when the load returns you have the data that was there when the load returns and not from when the load was issued.
If you issue a load that completes in 5 cycles and it needs to go to RAM for that data then it's going to stall waiting for that data but because you can issue loads sooner than on other architectures you can sort of alleviate some of the problems with stalling on some load.
But as far as I understand and hear, Itanium had sort-of similar capabilities (ALAT and speculative loads) and it didn't work great outside of FP workloads as it is still hard to programmatically schedule load early even if you can ignore RAW hazards. What's unique in the Mill?
Basically they've used their exposed pipeline design and register metadata to fix the things that didn't work well about ALAT. Or at least that's the theory.
EDIT: I think the main problem was that on Itanium issuing a speculative load could potentially trigger a page fault making it potentially dangerous. On the Mill the page fault won't trigger until the load leads to a side effect outside the belt, sort of like it's been wrapped in a Haskell Maybe monad. So if you' have something like
for (int i = 0; i < foo; i++) {
a[i] = a[i]+1;
}
you can speculatively load the a[i+n] while you're working on a[i] even if allocated memory stops at the border of the array allocation.
If you issue a load that completes in 5 cycles and it needs to go to RAM for that data then it's going to stall waiting for that data but because you can issue loads sooner than on other architectures you can sort of alleviate some of the problems with stalling on some load.