update

diff --git a/updates/003_2018dec04_microarchitecture.mdwn b/updates/003_2018dec04_microarchitecture.mdwn
index e97788ad4bbe77b2688c49fea3b3ce2a8ad94208..2d6af927aa01f81540e8f0cba6ec55cc4a5b39df 100644 (file)
--- a/updates/003_2018dec04_microarchitecture.mdwn
+++ b/updates/003_2018dec04_microarchitecture.mdwn
@@ -48,10 +48,15 @@ different paradigm from standard vector processors, where a loop allocates
 elements to "lanes", and if a predication bit is not set, the lane
 runs "empty".  By contrast, with the multi-issue execution model, an
 operation that is predicated out means that the element-based instruction
-simply does not make it into the instruction queue.
+does not even make it into the instruction queue.  Thus, unlike in a
+traditional vectore architecture, ALUs may be occupied by elements from 
+other "Lanes", because of the pre-existing decoupling between the multi-issue
+instruction queue and the ALUs.
 
 Simple!
 
+[[reorder_buffer.jpg]]
+
 There are many other benefits to a multi-issue microarchitecture, and
 these are being discussed
 [here](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2018-December/000198.html)
@@ -81,3 +86,26 @@ because, just as with an Exception, the ROB needs to be cleared out
 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:
+
+* 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
+  great 128-entry 64-bit register files.
+* In-order scoreboarding actually *delays* instruction execution (all of it)
+  until such time as the source registers and all other dependencies are
+  ready.  The idea seems to be that the register renaming "should have taken
+  care of" as many of these dependencies as possible, in advance.
+* Unlike Tomasulo with Reorder buffers, there does not appear to be
+  any assistance in dealing with memory LOAD/STOREs.
+* There's no clear way to handle branch prediction, where the Reorder
+  Buffer of Tomasulo handles it really cleanly.
+
+Whilst nothing's firmly set in stone, here, as we have a Charter that
+requires unanimous decision-making from contributors, so far it's leaning
+towards Reorder Buffers and Tomasulo as a good, clean fit.  In part that
+is down to more research having been done on that particular algorithm.
+More as it happens...
+