From: Luke Kenneth Casson Leighton Date: Sat, 14 Apr 2018 09:48:55 +0000 (+0100) Subject: add lanes, add instruction insight X-Git-Tag: convert-csv-opcode-to-binary~5677 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=465752ceddf74ab2ff8ba03977e1303dae812134;p=libreriscv.git add lanes, add instruction insight --- 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