Minor rv64 doc bugs

from the Libera #riscv IRC, posted here as I don’t have any other way to submit bug reports to SiFive

If you look at the s76-mc docs on the SiFive web site, and search for “sign-extend” you can find a few minor errors where it refers to 32-bits instead of 64-bits.

Section 5.2.2 I-Type Integer Instructions
The immediate is always sign-extended to 32-bits before being used in an arithmetic operation.

Section 5.2.3 I-Type Load Instructions
Load Byte, loads 8 bits (1 byte) and sign-extends to fill
destination 32-bit register.
LH and LHU have the same error. LW doesn’t mention sign extension, which it does do. LBU doesn’t mention the target register size so is OK. LWU is missing from the table.

The e76, e76-mc, u74, u74-mc docs have the same problem. I didn’t check other 64-bit docs, there may also be others with the same minor bug.

I noticed an additional problem in the e76 docs.

Section 5.2.2 I-Type Integer Instructions, SLTIU description
Compares the values as unsigned numbers (i.e., the immediate is first
sign-extended to 32-bits then treated as an unsigned number).

This one is OK in the s76 and u74 docs, so maybe the e76 docs just need to be regenerated to get that fix.

In the u74 docs, Appendix C, Floating-Point Unit Instruction Timing, fmv.d.x is 2 cycles, and fmv.x.d is specified as 6 cycles. I think this is wrong, as it doesn’t match gcc, which says fmv.d.x and fmv.x.d have the same latency. Maybe this was accidentally copied from the fcvt docs? I think both should be 2 cycle latency.

In the s76 docs, Appendix C, all of the instructions with 64-bit integer results say N/A. This is correct for a rv32gc target which is missing these instructions, but not correct for a rv64gc target which does have these instructions.

Thanks for the feedback @JimWilson

I’ve created a ticket to track these updates to the documentation.