FP instructions that depend on rounding mode

[pdonahue-ventana]

This didn't get much traction on the tech-unprivileged mailing list (other than someone who agreed that the spec isn't clear) so I'm posting here:

The F extension says: "The behavior of floating-point instructions that depend on rounding mode when executed with a reserved rounding mode is reserved, including both static reserved rounding modes (101–110) and dynamic reserved rounding modes (101–111)." How does the specification specify which FP instructions "depend on rounding mode"?

For example: The F extension says: "Note FCVT.D.W[U] always produces an exact result and is unaffected by rounding mode" and "FCVT.D.S will never round." In a casual sense, that means that those two instructions do not depend on rounding mode. In a more formal sense, the table in section 14.3 does not list frm as a source register for either of those instructions which also hints that these instructions do not depend on rounding mode (or at least are allowed to not depend on rounding mode).

If an implementation executes one of these instructions either with a reserved value in the rm field or with rm=111 and a reserved value in the frm CSR, is an implementation allowed to raise an illegal instruction exception or must implementations ignore the rm field and the frm CSR on those instructions?

[allenjbaum]

IMHO, ideally those would be "reserved" opcodes in the RM field (so you can't depend on what they may do) just to both remain backwards compatible and enable them to be used as new standard ops in the future. In that case either behavior is allowed, as is going off into the weeds... Second best is to trap with illegal op exception, but that may not be backwards compatible (though from a practical standpoint, it might be)

On Tue, Oct 13, 2020 at 5:35 PM Paul Donahue notifications@github.com wrote:

This didn't get much traction on the tech-unprivileged mailing list (other than someone who agreed that the spec isn't clear) so I'm posting here:

The F extension says: "The behavior of floating-point instructions that depend on rounding mode when executed with a reserved rounding mode is reserved, including both static reserved rounding modes (101–110) and dynamic reserved rounding modes (101–111)." How does the specification specify which FP instructions "depend on rounding mode"?

For example: The F extension says: "Note FCVT.D.W[U] always produces an exact result and is unaffected by rounding mode" and "FCVT.D.S will never round." In a casual sense, that means that those two instructions do not depend on rounding mode. In a more formal sense, the table in section 14.3 does not list frm as a source register for either of those instructions which also hints that these instructions do not depend on rounding mode (or at least are allowed to not depend on rounding mode).

If an implementation executes one of these instructions either with a reserved value in the rm field or with rm=111 and a reserved value in the frm CSR, is an implementation allowed to raise an illegal instruction exception or must implementations ignore the rm field and the frm CSR on those instructions?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/603, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJUML76PXONMGHKTOKLSKTW4XANCNFSM4SP5HBWQ .

[kasanovic]

We will provide a better general definition of "reserved encodings", to include instructions whose operation depends on additional control state. To be added to manual intro.

[pdonahue-ventana]

Can guidance be added for these particular encodings? We're using a random test generator which is poking in this area and we are unsure about whether 0x42031ad3 (which is ostensibly fcvt.d.s f21, f6, rtz) must be decoded as a legal instruction or a reserved instruction.

It appears that the GNU assembler does not accept a rounding mode argument for fcvt.d.s. Given that and Allen's comment, should this be reserved?

[nick-knight]

Not an answer to your question, but a related comment (that may have been made before, elsewhere):

The F extension (Vol. I, Sec. 11.2) does say:

Some instructions, including widening conversions, have the rm field but are nevertheless unaffected by the rounding mode; software should set their rm field to RNE (000).

So I think the assembler is justified in rejecting this instruction.

EDIT: the following comment by @aswaterman changes my perspective: this appears to be another "should vs. shall" issue that the language lawyers should litigate. Now, I think the assembler should be fixed (after the spec has been clarified).

[aswaterman]

There are many legal instructions the GNU assembler can't assemble (FENCE with a null predecessor set comes to mind).

Doing some archaeology on the spec, I see that, at the time we wrote the relatively weak statement "software should set their rm field to RNE", we would have used much stronger language if we intended to reserve the opcodes. For example, at that time, we wrote things like "For RV32I, SLLI, SRLI, and SRAI generate an illegal instruction exception if imm[5] != 0." This was also discussed a few years ago here https://github.com/riscv/riscv-isa-manual/issues/279 and the conclusion was the same: that "should" is the appropriate verb here, not "shall".

Note also that in the instruction-encoding table at the back of the spec, FCVT.D.W has the rm field, rather than having 000 in its place, as would be the case if the nonzero values were reserved. (FMV.W.X, by comparison, does have 000 in that field.)

So, it's pretty clear that the intent was that these instructions should treat the rm field the same way as instructions that do round: i.e., for these, rm=0..4 are valid, rm=5..6 are reserved, and for rm=7, frm=0..4 are valid and frm=5..7 are reserved. The spec should be clarified accordingly.