simply does not care. In addition, there may be a really simple way to
extend the Reorder Buffer tags to accomodate SIMD-style characteristics.
-We also may need to have simple Branch Prediction, because some of the
-loops in [Kazan](https://salsa.debian.org/Kazan-team/kazan/) are particularly
-tight. A Reorder Buffer can easily be used to implement Branch Prediction,
-because, just as with an Exception, the ROB can to be cleared out
-(flushed) if the branch is mispredicted. As it is necessary to respect
-Exceptions, the logic has to exist to clear out the ROB: Branch Prediction
-simply uses this pre-existing logic.
+We also may need to have simple Branch Prediction, because some of
+the loops in [Kazan](https://salsa.debian.org/Kazan-team/kazan/)
+are particularly tight. A Reorder Buffer (ROB) can easily be used
+to implement Branch Prediction, because, just as with an Exception,
+the ROB can to be cleared out (flushed) if the branch is mispredicted.
+As it is necessary to respect Exceptions, the logic has to exist to
+clear out the ROB: Branch Prediction simply uses this pre-existing logic.
The other way in which out-of-order execution can be handled is called
scoreboarding, as well as explicit register renaming. These schemes
seem to have significant disadvantages and complexities when compared
-to Reorder Buffers:
+to Reorder Buffers (however, see later updates: the disadvantages are down
+to a complete failure of the academic literature to fully comprehend
+the design of the CDC 6600):
* Explicit Register renaming needs a global register file quite a bit larger
than the "actual" one. The Libre RISC-V SoC already has two whopping
* Scoreboarding does not provide a means to do multi-issue (the ROB
does: you just put more than one entry per cycle into the buffer)
+(*Note: in later updates, we find that, fascinatingly, these things are
+just not true.*)
+
# Next step
The project is being run along ethical lines. That in particular means