From 465752ceddf74ab2ff8ba03977e1303dae812134 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sat, 14 Apr 2018 10:48:55 +0100 Subject: [PATCH] add lanes, add instruction insight --- alt_rvp.mdwn | 2 ++ simple_v_extension.mdwn | 12 ++++++++++++ 2 files changed, 14 insertions(+) diff --git a/alt_rvp.mdwn b/alt_rvp.mdwn index c920137c4..afe6d3820 100644 --- a/alt_rvp.mdwn +++ b/alt_rvp.mdwn @@ -1,5 +1,7 @@ # Lanes +The term "Lanes" is borrowed from Hwacha. + Register table | reg num | Lane 0 | Lane 1 | Lane 2 | Lane 3 | diff --git a/simple_v_extension.mdwn b/simple_v_extension.mdwn index e1715844d..88cc9ed1d 100644 --- a/simple_v_extension.mdwn +++ b/simple_v_extension.mdwn @@ -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 It could indeed have been logically deduced (or expected), that there -- 2.30.2