add register file mux

diff --git a/images/regfile.jpg b/images/regfile.jpg
new file mode 100644 (file)
index 0000000..c958408
Binary files /dev/null and b/images/regfile.jpg differ

diff --git a/images/register_file_multiplexing.jpg b/images/register_file_multiplexing.jpg
new file mode 100644 (file)
index 0000000..cc0ad81
Binary files /dev/null and b/images/register_file_multiplexing.jpg differ

diff --git a/updates/005_2018dec14_simd_without_simd.mdwn b/updates/005_2018dec14_simd_without_simd.mdwn
index 69f19aff4eb18fd413b77a6432fb0fb977a8b9f6..fb75a04f0ff941b1e803a17a3a165ed82ec7addc 100644 (file)
--- a/updates/005_2018dec14_simd_without_simd.mdwn
+++ b/updates/005_2018dec14_simd_without_simd.mdwn
@@ -99,6 +99,8 @@ So in fact, it's actually quite simple, and this "cascade" is simply and
 easily propagated down to the Function Unit Dependency Matrices, stopping
 32-bit operations from overwriting 8-bit and vice-versa.
 
+# Virtual Registers
+
 The fourth part is the grid in green, in the top left corner.  This is
 a "virtual" to "real" one-bit table.  It's here because the size of
 these matrices is so enormous that there is deep concern about the line
@@ -117,6 +119,8 @@ if this table is not high enough (not enough IRs), the processor has to
 stall until an instruction is completed, so that one register becomes
 free.  Again, another thing to keep an eye on, in simulations.
 
+# Refinements
+
 The second major concern is the purple matrix: the FU-to-FU one.  Basically
 where previously we would have FU1 cover all ADDs, FU2 would cover all MUL
 operations, FU3 covers BRANCH and so on, now we have to multiply those
@@ -124,3 +128,17 @@ numbers by **four** (64-bit ops, 32-bit ops, 16-bit and 8), which in turn
 means that the size of the FU-to-FU Matrix has gone up by a staggering
 **sixteen** times.  This is not really acceptable, so we have to do something
 different.
+
+So the refinement is based on an observation that 16-bit operations of
+course may be constructed from 8-bit values, and that 64-bit operations
+can be constructed from 32-bit ones.  So, what if we skipped the
+cascade on 64 and 16 bit, and made the cascade out of just 32-bit and 8-bit?
+Then, very simply, the top half of a 64-bit source register is allocated
+to one Function Unit, the bottom half to the one next to it, and when it
+comes to actually passing the source registers to the relevant ALU, take
+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.