allenjbaum
commented
2 weeks ago Originally, I wrote the Zmmul spec to say Zmmul was incompatible with M - but that was rejected because it was pointed out that if misa.M was writable, and Zmmul was implemented, then the effect would be to disable divide/remainder (whose opcodes become reserved), and that should be legal. There was no discussion that it would have different behavior when misa.M was writable or not, just what its value was. (There was also no discussion of why anyone would want to dynamically disable just divide instructions, leaving multiply enabled.
The interpretation that multiply ops are implementation defined in the case where Zmmul is implemented, and misa.M is writable and clear- sees inconsistent. The meaning shouldn't change depending on how the misa.M bit was configured, just what its value is.
(It gets more interesting since it is legal for all of misa to be RdOnly0)
Zmmul Misa.M meaning 0 RO1 mul/div ops are legal 0 RO0 mul/div ops are reserved 0 RW0 mul/div ops are reserved 1 RO1 mul/div ops are legal 1 RO0 mul ops are legal, div/rem ops are reserved 1 RW0 mul ops are legal, div/rem ops are reserved
On Tue, Nov 5, 2024 at 8:06 AM Tim Hutt @.***> wrote:
From this comment https://github.com/riscv/riscv-isa-manual/pull/1121#issuecomment-1721892829 :
misa spec requires that if M is set, then M is available. If only Zmmul is present misa.M should be clear. If misa.M is writable and M is cleared, the specs say that the hart behaves as if M not present, where behavior includes the opcodes being "reserved". Whether Zmmul is still usable when misa.M is clear is implementation-defined; misa allows the behaviors to be "reserved" in this case - so Zmmul if still available, it acts as a standard extension. This I believe is the only way to have a consistent view of misa behavior matching the ratified specifications.
To avoid spec-by-github-issue please can we add that information to the actual spec? It is not obvious.
I think it is correct though since it matches the B extension and its sub-extensions. The C extension/sub-extensions work differently.
Ideally a whole section would be added to misa explaining how the sub-extensions are supposed to work for M, B, C, etc.
— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/1711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJX2YCMJFJPDAEC3EMLZ7DUHJAVCNFSM6AAAAABRG4TCW2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZTKOBXHE4DIMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Timmmm
From this comment:
To avoid spec-by-github-issue please can we add that information to the actual spec? It is not obvious.
I think it is correct though since it matches the B extension and its sub-extensions. The C extension/sub-extensions work differently.
Ideally a whole section would be added to
misaexplaining how the sub-extensions are supposed to work for M, B, C, etc.