add lanes, add instruction insight
authorLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Sat, 14 Apr 2018 09:48:55 +0000 (10:48 +0100)
committerLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Sat, 14 Apr 2018 09:48:55 +0000 (10:48 +0100)
alt_rvp.mdwn
simple_v_extension.mdwn

index c920137c4ac1fa25febda07190adf22d57721a32..afe6d38205f4530ce3199ea626d07c7d2c0992e2 100644 (file)
@@ -1,5 +1,7 @@
 # Lanes
 
+The term "Lanes" is borrowed from Hwacha.
+
 Register table
 
 | reg num | Lane 0 | Lane 1 | Lane 2 | Lane 3 |
index e1715844ddfba7f513552af8ba3e2def5e01ef45..88cc9ed1db0a1d7d5feca1414298ac1fa2f2eefb 100644 (file)
@@ -1087,6 +1087,18 @@ be achieved by *actually* splitting the regfile into 64 virtual 32-bit
 registers such that a 64-bit FP scalar operation is dropped into (r0.H
 r0.L) tuples.  Implementation therefore hidden through register renaming.
 
+Instructions "ADD r2 r4 r4" would result in three instructions being
+generated and placed into the FIFO: ADD r2 r4 r4; ADD r2 r5 r5;
+ADD r2 r6 r6;
+
+Implementations intending to introduce VLIW, OoO and parallelism
+(even without Simple-V) would then find that the instructions are
+generated quicker (or in a more compact fashion that is less heavy
+on caches).  Interestingly we observe then that Simple-V is about
+"consolidation of instruction generation", where actual parallelism
+of underlying hardware is an implementor-choice that could just as
+equally be applied *without* Simple-V even being implemented.
+
 # Analysis of CSR decoding on latency <a name="csr_decoding_analysis"></a>
 
 It could indeed have been logically deduced (or expected), that there