[Libre-soc-isa] [Bug 1087] change pseudocode to prevent output register write only when causing a fp trap and output is in same regfile as input

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Wed May 24 11:16:49 BST 2023


--- Comment #27 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #23)
> (In reply to Luke Kenneth Casson Leighton from comment #22)
> > (In reply to Jacob Lifshay from comment #20)
> > 
> > jacob: i think you keep misunderstanding: RT *is* always written by
> > the simulator.
> i understand that perfectly fine, my proposal has nothing to do with how the
> simulator works, it is to make the pseudocode always write to RT so hw
> doesn't have to mask off writes to CR0 (causes problems for ddff) or read RT
> from the regfile to compute CR0.

no you cannot do that, it entirely breaks how CR-field co-results work.

such a change "in some cases Rc=1 means test the previous value" would
not go down well with the ISA WG.

> this is terrible for hw, it means it neads to read another register just for
> the very rare case when it traps so it can properly calculate CR0 from the
> RT value it read.

but it should not have read RT [in order to do that] as that is totally
the wrong behaviour and a misunderstanding of what CRf co-results actually

co-results are associated with the result being computed by the
hardware (ok pseudocode).

and in the Simulator, the *return* results are what are tested - even
before they're put into the regfile.

that's why handle_condition goes to the trouble of hunting inside the
list of return results, not re-reading the contents of any registers.

> read needed to calculate CR0 when trapping, since then RT is not written

then perform the change to CR0 explicitly, and leave RT alone.
(btw it's perfectly valid to have RT "undefined" and CR0 to be

parser.py is smart enough to spot that the pseudocode contains
CR0, and tell ISACaller *not* attempt to perform the [usual] computation,
because parser.py places CR0 into the list of return results.

there is at least one place where this is done (hence why i had to
add the feature).  oh!  yes - prefix_codes!

    CR0 <- ra_used || (tree_index >= 64) || found || hit_end

yes this would mean that in the *non*-exceptional case you have to
duplicate the functionality of Rc=1.  yes it's a pain.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Libre-SOC-ISA mailing list