[Libre-soc-bugs] [Bug 1072] implement fcvt/fmv instructions in ISACaller (ls006)

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Tue May 16 08:53:40 BST 2023


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

--- Comment #26 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #25)
> I added tests for the FPSCR output generated by the JS tests, previously
> FPSCR was completely ignored.
> I fixed fcvttg* FPSCR computation 

super.

> and while I was at it, I changed the
> overflow output to only be set when the result actually overflows rather
> than just rounds -- previously overflow was set whenever the input value
> wasn't equal to the output value, now overflow is set only when the rounded
> (trunc/floor/ceil/etc.) input value isn't equal to the output value.

ah i forgot to mention/advise: search in caller.py for "overflow" then
pay attention to the div_overflow local function parameter.

if you use it, it will go into XER when OE=1.  so you have to watch out
in the CSV file to make sure that oe-en is *off*.

also it may be better to call it "fp_overflow" or something different
so that modifications or special handling in parser.py are not needed.
we don't need that hassle.

if however you *wanted* overflow to be set, *wanted* OE=1 to set XER
then you're doing the right thing in the pseudocode :)

btw i strongly suggest moving the entirety of fcvttg to an Appendix
as a pywriter function.  it is *far* too complex, even to write the
english description needed.  extensive comments - in the spirit
of the "Power ISA english description" associated with each instruction
pseudocode - will have to suffice.

about that: it is 100% imperative to under no circumstances use personal
pronouns in pseudocode code-comments or the english description or
basically anywhere in the spec now that i think about it.

banned words:

    "i we he she you your my our ours their theirs they them" and others

also starting sentences with "this" are generally frowned on.

    "this works because the largest type we try to convert from has
     53 significand bits, "

-->

    "the largest type CONVERTED [below] has 53 significand bits"

this is a style that is crucial to maintain in specifications,
the only other location i have heard of where it is used is in
write-ups of scientific experiments (with the additional rule
not applicable here of always writing scientific experiments in
"past tense").

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


More information about the libre-soc-bugs mailing list