From d5cf4acfdbb76d98f8d3fec988eb446857f7f866 Mon Sep 17 00:00:00 2001 From: Paul Mackerras Date: Wed, 13 Jan 2021 19:45:57 +1100 Subject: [PATCH] execute1: Update comments about XER forwarding This deletes some commentary that is now out of date and replaces it with a simple statement about the XER common bits being forwarded from the output of execute1 to the input. The comment being deleted talked about a hazard if an instruction that modifies XER[SO] is immediately followed by a store conditional. That is no longer a problem because the operands for loadstore1 are sent from execute1 (and therefore have the forwarded value) rather than decode2. This was in fact fixed in 5422007f83bf ("Plumb loadstore1 input from execute1 not decode2", 2020-01-14). Signed-off-by: Paul Mackerras --- execute1.vhdl | 34 +++++----------------------------- 1 file changed, 5 insertions(+), 29 deletions(-) diff --git a/execute1.vhdl b/execute1.vhdl index f9b46c1..3c1d9d3 100644 --- a/execute1.vhdl +++ b/execute1.vhdl @@ -356,35 +356,11 @@ begin v.f.redirect := '0'; fv := Execute1ToFPUInit; - -- XER forwarding. To avoid having to track XER hazards, we - -- use the previously latched value. - -- - -- If the XER was modified by a multiply or a divide, those are - -- single issue, we'll get the up to date value from decode2 from - -- the register file. - -- - -- If it was modified by an instruction older than the previous - -- one in EX1, it will have also hit writeback and will be up - -- to date in decode2. - -- - -- That leaves us with the case where it was updated by the previous - -- instruction in EX1. In that case, we can forward it back here. - -- - -- This will break if we allow pipelining of multiply and divide, - -- but ideally, those should go via EX1 anyway and run as a state - -- machine from here. - -- - -- One additional hazard to beware of is an XER:SO modifying instruction - -- in EX1 followed immediately by a store conditional. Due to our - -- writeback latency, the store will go down the LSU with the previous - -- XER value, thus the stcx. will set CR0:SO using an obsolete SO value. - -- - -- We will need to handle that if we ever make stcx. not single issue - -- - -- We always pass a valid XER value downto writeback even when - -- we aren't updating it, in order for XER:SO -> CR0:SO transfer - -- to work for RC instructions. - -- + -- XER forwarding. To avoid having to track XER hazards, we use + -- the previously latched value. Since the XER common bits + -- (SO, OV[32] and CA[32]) are only modified by instructions that are + -- handled here, we can just forward the result being sent to + -- writeback. if r.e.write_xerc_enable = '1' then v.e.xerc := r.e.xerc; else