minor correction

diff --git a/updates/003_2018dec04_microarchitecture.mdwn b/updates/003_2018dec04_microarchitecture.mdwn
index b1735c55efcfa253e650600108d6e44a19afd1d4..84bb5b0937ce3c7c7a8ec6c7be977341c23f65bd 100644 (file)
--- a/updates/003_2018dec04_microarchitecture.mdwn
+++ b/updates/003_2018dec04_microarchitecture.mdwn
@@ -83,13 +83,13 @@ and, crucially, some ALUs may take longer than others, and the algorithm
 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

diff --git a/updates/005_2018dec14_simd_without_simd.mdwn b/updates/005_2018dec14_simd_without_simd.mdwn
index fb75a04f0ff941b1e803a17a3a165ed82ec7addc..c6e456c774b7254d90955758fa3f66f41a02c051 100644 (file)
--- a/updates/005_2018dec14_simd_without_simd.mdwn
+++ b/updates/005_2018dec14_simd_without_simd.mdwn
@@ -141,4 +141,10 @@ from *both* FUs.
 The primary focus is on 32-bit (single-precision floating-point) performance
 anyway, for 3D, so if 64-bit operations happen to have half the number of
 Reservation Stations / Function Units, and block more often, we actually
-don't mind so much.  
+don't mind so much.  Also, we can still apply the same "banks" trick on
+the Register File, except this time with 4-way multiplexing on 32-bit
+wide banks, and 4x4 crossbars on the bytes:
+
+{{register_file_multiplexing.jpg}}
+
+