From ec6e36463935e038e65c9f6285890cb35d540de0 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Tue, 4 Dec 2018 12:44:29 +0000 Subject: [PATCH] update --- updates/003_2018dec04_microarchitecture.mdwn | 30 +++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/updates/003_2018dec04_microarchitecture.mdwn b/updates/003_2018dec04_microarchitecture.mdwn index e97788a..2d6af92 100644 --- 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... + -- 2.30.2