we need to think through how to set the various XER flags properly.
if we naively have XER as a permanent incoming input (and output),
this will create a permanent sequential (in-order) read-write hazard
on all ALU operations that will light up the DMs covering XER like
a mythbusters christmas tree.
Section 3.2.2 Fixed-Point Exception Register (XER)
32 Summary Overflow (SO)
The Summary Overflow bit is set to 1 when-
ever an instruction (except mtspr and addex)
sets the Overflow bit. Once set, the SO bit
remains set until it is cleared by an mtspr
instruction (specifying the XER). It is not
altered by Compare instructions, or by other
instructions (except mtspr to the XER and
addex with operand CY=0) that cannot over-
flow. Executing an mtspr instruction to the
XER, supplying the values 0 for SO and 1 for
OV, causes SO to be set to 0 and OV to be set
to 1. addex does not alter the contents of SO.
33 Overflow (OV)
The Overflow bit is set to indicate that an over-
flow has occurred during execution of an
instruction. The Overflow bit can also used as
an independent Carry bit by using the addex
with operand CY=0 instruction and avoiding
other instructions that modify the Overflow bit
(e.g., any XO-form instruction with OE=1).
XO-form Add, Subtract From, and Negate
instructions having OE=1 set it to 1 if the carry
out of bit M is not equal to the carry out of bit
M+1, and set it to 0 otherwise.
XO-form Multiply Low and Divide instructions
having OE=1 set it to 1 if the result cannot be
represented in 64 bits (mulld, divd, divde,
divdu, divdeu) or in 32 bits (mullw, divw,
divwe, divwu, divweu), and set it to 0 other-
addex with operand CY=0 sets OV to 1 if there
is a carry out of bit M, and sets it to 0 other-
The OV bit is not altered by Compare instruc-
tions, or by other instructions (except mtspr to
the XER) that cannot overflow.
34 Carry (CA)
The Carry bit is set as follows, during execu-
tion of certain instructions. Add Carrying, Sub-
tract From Carrying, Add Extended, and
Subtract From Extended types of instructions
set it to 1 if there is a carry out of bit M, and
set it to 0 otherwise. Shift Right Algebraic
instructions set it to 1 if any 1-bits have been
shifted out of a negative operand, and set it to
0 otherwise. The CA bit is not altered by Com-
pare instructions, or by other instructions
(except Shift Right Algebraic, mtspr to the
XER) that cannot carry.
44 Overflow32 (OV32)
OV32 is set whenever OV is implicitly set, and
is set to the same value that OV is defined to
be set to in 32-bit mode.
45 Carry32 (CA32)
CA32 is set whenever CA is implicitly set, and
is set to the same value that CA is defined to
be set to in 32-bit mode.
dang. these XER bits really do need to be treated as individual registers
covered by separate DM rows.
if we don't they'll chain together and completely destroy any opportunity
this in turn means we need to define a function which, rather laboriously,
tells us at the instruction *decode* phase, what implicit "registers"
(which fields) are to be written to, and which to be read/write. SO is
definitely on that list.
started documenting the XER fields here:
we really need this as a variant / extension of power_decode:
a set of CSVs that tell us the bits in XER which need setting.
(likewise we need one for which SPRs are needed by which operations)
michael could you convert all the outgoing XER fields to a Data record type? this basically treating them just like spr1 2 3 which are Data type
what can then be done is, in the main_stage.py set the "ok" flag of carry32.ok to 1 to indicate a *desire* to have the output_stage compute cr32 and so on.
each mainstage can then set those ok bits as needed.
some of those flags i think we might get already from the CSV files
ah. right. ok. in alu/output_stage.py the Data ok for cr0 and the XER fields do, ov, ov32, need to be set based on Rc and OE from the instruction.
CR0 (if Rc=1)
SO OV OV32 (if OE=1)
this code shows that the op.carry_out field from op decode is Rc
and that op.oe is likewise OE.
carry_32 := result(32) xor a_inv(32) xor b_in(32);
carry_64 := result_with_carry(64);
if e_in.insn_type = OP_ADD then
if e_in.output_carry = '1' then
set_carry(v.e, carry_32, carry_64);
if e_in.oe = '1' then
calc_ov(a_inv(63), b_in(63), carry_64, result_with_carry(63)),
calc_ov(a_inv(31), b_in(31), carry_32, result_with_carry(31)));
(In reply to Luke Kenneth Casson Leighton from comment #4)
> michael could you convert all the outgoing XER fields to a Data record type?
done, it needs checking.
also, the CR pipeline needs likewise converting so that CROutputData.cr is of
then, the op.input_cr and op.output_cr fields i believe are involved.
op.output_cr should be set to CROutputData.cr.ok to indicate "this instruction
outputs a CR register"