From 6d9cfea160f1b18cac6d448b25d7d71d548a3c6e Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Wed, 2 Jan 2019 10:05:55 +0000 Subject: [PATCH] 009 update --- updates/009_register_overwrites.mdwn | 29 +++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/updates/009_register_overwrites.mdwn b/updates/009_register_overwrites.mdwn index e89e0c5..03e2fc3 100644 --- a/updates/009_register_overwrites.mdwn +++ b/updates/009_register_overwrites.mdwn @@ -149,6 +149,10 @@ left and a pair of unary encoders on the right. {{6600_q_table.png}} +The plan is, therefore, to add effectively *multiple* Q-Tables +(or, multiple entries), recording the "history" of which *prior* +Function Units had any given register as its destination. + Now we have exactly the information needed to "roll back", should an exception occur. Like many augmentations and enhancements to the 6600 Scoreboard system, it's kind-of obvious in retrospect. However the *real* @@ -160,7 +164,9 @@ instructions could potentially hit an exception. Why is that important? It's because it's not enough to know that the down-stream (dependent) instructions have all initiated (read the FU's dest latch and taken it as a forwarded src operand). If **even one** -of those instructions throws an exception, the "nameless" FU is hosed. +of those instructions throws an exception, the "nameless" FU from which that +value came is hosed, as it has nowhere to put its result. + So, firstly: the "nameless" FU absolutely has to wait until its dependencies are clear of exceptions (and then **and only** then may it safely drop (throw away) the data (without writing it to the Register File); and secondly, @@ -169,3 +175,24 @@ the "nameless" FU absolutely has to know that it can "roll back" from instructions does indeed throw an exception. This is where the "History" Q-Table Entries come into play. +So there's a few potential ways to go about this: + +* Using the Historical Q-Table Entries, in chronological and Dependency + Order, store all "Nameless" Registers (using the "history" to determine + where), even if they are going to get overwritten in the next cycle. +* After triggering the "Go\_die" wire from the Exception, and all + dependent instructions have been removed (including their Destination + Register Reservations), use the "history" information to work out + which (formerly nameless) Function Unit(s) now actually have the + Destination Reservation for all "vacated" Register. +* Any remaining "nameless" Registers, if their results are available, + are likewise either stored or trigger their shadow (dependent) + instructions to die (even if it's the original exception). +* Once the dust settles, carry on. + +Realistically, this is going to need to be investigated with simulations. +It's quite complicated, however the payoff is a significant reduction in +the workload on the register file. It basically means the difference between +12 GFLOPs and 6 GFLOPs when doing 32-bit FMACs, at 800mhz (quad-core), +and still being able to keep to a "standard" 2R1W register file. +So it's a big deal! -- 2.30.2