From ae22d8d29669e490b8236929cb4ff6f8572145aa Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sun, 15 Apr 2018 14:59:25 +0100 Subject: [PATCH] add register bank cache schemes --- simple_v_extension.mdwn | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/simple_v_extension.mdwn b/simple_v_extension.mdwn index b21b396e4..030667d26 100644 --- a/simple_v_extension.mdwn +++ b/simple_v_extension.mdwn @@ -1214,6 +1214,26 @@ pluses: parallel ALUs) is only equal to one ("virtual" parallelism), or is greater than one, should not be underestimated. +# Appendix + +# Reducing Register Bank porting + +This looks quite reasonable. + + +The main details are outlined on page 4.  They propose a 2-level register +cache hierarchy, note that registers are typically only read once, that +you never write back from upper to lower cache level but always go in a +cycle lower -> upper -> ALU -> lower, and at the top of page 5 propose +a scheme where you look ahead by only 2 instructions to determine which +registers to bring into the cache. + +The nice thing about a vector architecture is that you *know* that +*even more* registers are going to be pulled in: Hwacha uses this fact +to optimise L1/L2 cache-line usage (avoid thrashing), strangely enough +by *introducing* deliberate latency into the execution phase. + + # References @@ -1238,3 +1258,4 @@ pluses: * Zero-overhead loops * Multi-ported VLIW Register File Implementation * Fast context save/restore proposal +* Register File Bank Cacheing -- 2.30.2