[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]

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

--- Comment #22 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #20)

jacob: i think you keep misunderstanding: RT *is* always written by
the simulator. i am NEVER going to change the Simulator to stop the
value returned by the pseudocode function from being
written.

*regardless* of what the contents are the contents of FRT
are **ALWAYS** passed to the function ISACaller.do_outregs_nia().

whatever goes in to RT *is* written out back into FPR, period.
this is NEVER going to change.

it is therefore up to you to make a choice in the pseudocode
whether to CHANGE the value of FRT or NOT change the value of
FRT.

but the value regardless of whether it is or is not changed
by the pseudocode WILL ALWAYS BE WRITTEN BACK INTO THE REGISTER.

now, what you *might* be assuming is that "there is a flag
in the operator "<-" which if used on a return result it
indicates to the Simulator to store the result in the register",
this is false: you are likely thinking of *hardware* here
(which is perfectly reasonable).

comments in the unit test such as this are therefore misleading
or at least ambiguous:

+                # FIXME: #1087 proposes to change pseudocode of fcvt* to
+                # always write output, this implements reading RT when output
+                # isn't written, which is terrible

it's not terrible at all for the *Simulator*, it doesn't care.

what you might be thinking of is *hardware* always writing output,
and/or always reading input, which yes that would waste resources
if it was unnecessary.  when writing the HDL it would be one of
the jobs of the implementation to set the "output-enable" bit,
indicating that the register is to be written (or cancelled if
not set).

with the code-reuse from the unit tests it's probably a good
idea to clarify that hardware should watch out for that.
the most important bit there will be if it is extremely easy
(based preferably on immediate-flags and nothing else,
certainly not reading the contents of the register) to
determine if RT needs to be read at all.

also, i have to say, i don't fully understand what you mean
"reading RT when output isn't written" - are you saying that
the instruction has to become a READ-MODIFY-WRITE?  or that
in *hardware* it is necessary to read RT, perform some
checks, and then decide "actually RT need not be written"?
this makes no sense: there really should only be MODIFY-WRITE
(no read)

(there are only a few read-modify-write instructions, they're
 explicitly listed as such in the spec, hence why i ask)

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