3 ms·

They say the M1 may use a validation buffer instead of a re order buffer. This makes it somewhat clear if you know what a re order buffer is. Processors basi

They say the M1 may use a validation buffer instead of a re order buffer. This makes it somewhat clear if you know what a re order buffer is. Processors basically do this: read instructions, execute them out of order to fully use cpu resources, put the instructions back in order along with their results, and then write results to memory. This way the “final state” follows the order of instructions. The “put back in order” step is handled by the re order buffer. It is basically an online sort algorithm. Fully sorting instructions after execution is simple and correct, but in extreme cases may be suboptimal; perhaps it doesn’t matter if the final state is exactly in order or just close to that. I believe the article is saying the M1 may just validate states as they are written rather than fully reordering.

mhh__ 6y ago
It was the distinction between validation and re-order that confused me.
cromwellian 6y ago
The Sun Microsystems Rock processor had I guess, validation? Rather than re-order instructions, you just speculatively execute instructions, issue you memory ops but don't stop and wait, called "hardware scouting". If after everything resolves, you find your prediction was wrong, you rollback. So it's a kind of Transactional Memory approach, and if validation fails, you re-execute the same sequence of instructions, but the branches are different. https://en.wikipedia.org/wiki/Hardware_scout https://en.wikipedia.org/wiki/Hardware_scout
- eru 6y ago
  Interesting. Sounds like even more opportunities for speculative instruction exploits.
StillBored 6y ago
Arm isn't TSO. As long as the internal instruction stream maintains dependency information independent pieces of code could be completed and written back to memory at any time. Basically the whole, "put it back in order" bits only have to happen around memory barriers because the visibility of writes isn't guaranteed otherwise. Whether this matters given large write combining/writeback buffering that queues up early writes until the later writes have completed is one of those decade+ long arguments.

mhh__ 6y ago

It was the distinction between validation and re-order that confused me.

cromwellian 6y ago

The Sun Microsystems Rock processor had I guess, validation? Rather than re-order instructions, you just speculatively execute instructions, issue you memory ops but don't stop and wait, called "hardware scouting". If after everything resolves, you find your prediction was wrong, you rollback. So it's a kind of Transactional Memory approach, and if validation fails, you re-execute the same sequence of instructions, but the branches are different. https://en.wikipedia.org/wiki/Hardware_scout https://en.wikipedia.org/wiki/Hardware_scout

eru 6y ago
Interesting. Sounds like even more opportunities for speculative instruction exploits.

StillBored 6y ago

Arm isn't TSO. As long as the internal instruction stream maintains dependency information independent pieces of code could be completed and written back to memory at any time. Basically the whole, "put it back in order" bits only have to happen around memory barriers because the visibility of writes isn't guaranteed otherwise. Whether this matters given large write combining/writeback buffering that queues up early writes until the later writes have completed is one of those decade+ long arguments.