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 <paulus@ozlabs.org>

diff --git a/execute1.vhdl b/execute1.vhdl
index f9b46c1a62e9db2c07835280bfb2cfba4e5c4bf3..3c1d9d37873fce769705c92a67cb215872c3a7b5 100644 (file)
--- 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