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- wise. addex with operand CY=0 sets OV to 1 if there is a carry out of bit M, and sets it to 0 other- wise. 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 for parallelism. 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: https://libre-soc.org/openpower/pipeline_operands/ 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); end if; if e_in.oe = '1' then set_ov(v.e, 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))); end if;
(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 type Data. 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"