[libre-riscv-dev] [Bug 319] New: POWER9 setting carry (and other) XER flags

[libre-riscv-dev] [Bug 319] New: POWER9 setting carry (and other) XER flags

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=319

            Bug ID: 319
           Summary: POWER9 setting carry (and other) XER flags
           Product: Libre-SOC's first SoC
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: CONFIRMED
          Severity: enhancement
          Priority: ---
         Component: Source Code
          Assignee: lkcl@lkcl.net
          Reporter: lkcl@lkcl.net
                CC: libre-riscv-dev@lists.libre-riscv.org
   NLnet milestone: ---

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 319] POWER9 setting carry (and other) XER flags

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=319

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 319] POWER9 setting carry (and other) XER flags

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=319

--- Comment #2 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 319] POWER9 setting carry (and other) XER flags

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=319

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
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)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 319] POWER9 setting carry (and other) XER flags

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=319

Luke Kenneth Casson Leighton <lkcl@lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|lkcl@lkcl.net               |mtnolan2640@gmail.com

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 319] POWER9 setting carry (and other) XER flags

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=319

--- Comment #5 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
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;

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 319] POWER9 setting carry (and other) XER flags

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=319

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(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"

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 319] POWER9 setting carry (and other) XER flags

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=319

Luke Kenneth Casson Leighton <lkcl@lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.libre-soc.org/
                   |                            |show_bug.cgi?id=333

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev