to use register 112, for example. One of those could even be changed
to 32-bit operations whilst the other is set to 16-bit element widths.
-Our initial thoughts were to try a standard simple in-order SIMD architecture,
+Our initial thoughts advocated a standard simple in-order SIMD architecture,
with predication bits passed down into the SIMD ALUs. If a bit is "off",
that "lane" within the ALU does not calculate a result, saving power.
-However, a pre-analysis engine is required that re-orders the registers,
-packs lanes of data together so that it fits into one SIMD ALU, and, on
+However, in SV, when the element width is set to 32, 16 or 8-bit, a
+pre-issue engine is required that re-orders *parts* of the registers,
+packing lanes of data together so that it fits into one SIMD ALU, and, on
exit from the ALU, it may be necessary to split and "redirect" parts of the
data to *multiple* actual 64-bit registers. In other words, bit-level
(or byte-level) manipulation is required, both pre- and post- ALU.
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, leaving it free for
+use by following instructions, even in the same cycle, and even if the
+operation is totally different. 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)
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...
+
projects / crowdsupply.git / blobdiff