riscv-isa-manual
riscv-isa-manual copied to clipboard
riscv
Use a defined architectural term since "reserved" behavior is not defined
Changed the language to not preclude this change from ever being ratified.
As I wrote on the other issue, I think it would be better to use the word “reserved”, then separately explain what happens when a reserved encoding is used. But I’ll leave this to @kasanovic
It still uses uses the word reserved for reserved encodings since "reserved encodings" is a defined term. My proposal is to say that once you hit one of these reserved encodings then the behavior is UNSPECIFIED rather than reserved. UNSPECIFIED behaviors are defined in 1.7. What is "reserved behavior"? Absent a definition, I assume that if reserved encodings are encodings that you're generally supposed to avoid then reserved behavior is behavior that you're not supposed to exhibit. It doesn't make sense to say that when seeing a reserved encoding that implementations are supposed to behave in ways that they shouldn't behave.
To be clear: The way that I read the sentence and the way that I think it was intended is that "of floating-point instructions that depend on rounding mode when executed with a reserved rounding mode" is a long prepositional phrase so this sentence says "the behavior of <something> is reserved" but my contention is that it should say "the behavior of <something> is UNSPECIFIED."
And I'm completely fine that the previous requirement to trap has been removed since I think it makes the architecture more self-consistent. That was my goal in bringing it up to start with: go one way or the other but don't sometimes go halfway for no obvious reason.
@aswaterman @kasanovic Not sure what to do with this one. I can easily add to adoc version of the ISA guide, but not sure what the final decision is. Let me know if I should be moving to ASCIIdoc. If this is a topic that requires more discussion, then maybe we should take it back to an issue and discuss there.
I also notice that the current specification of Ssstrict doesn't seem to require an illegal instruction exception when the instruction specifies dynamic rounding and the frm CSR is 101-111. Maybe it should say that an instruction encoding with frm of 101-110 has UNSPECIFIED behavior and that an instruction encoding with frm=111 while the frm CSR is 101-111 is treated the same as if a reserved encoding had been encoded in the instruction itself (i.e. UNSPECIFIED by default or illegal instruction if you have Ssstrict). I believe that this would be backward compatible as long as it's done before Ssstrict is ratified.
@kersten1 It's an ongoing technical discussion about what behaviors are allowed, or should be allowed, when a reserved encoding is used. Replacing "reserved" with "unspecified" isn't the right resolution: not because it's untrue, but because it loses some of the meaning. I'll close the PR and create an issue in its place.