Maybe-op instructions can't be treated as NOPs

[james-ball-qualcomm]

Small correction for the non-normative text related to Zimop & Zcmop.

It current reads: "Implementations can treat as NOPS. "

This is not consistent with the definition of MOPS in the ASCIIDOC version of the Unpriv ISA manual and my understanding of these instructions. In the Unpriv ISA manual, it says "MOPs are initially defined to simply write zero to x[rd], but are designed to be redefined by later extensions to perform some other action."

I recommend you change the non-normative text to say: "Implementations simply write zero to the destination register unless they support extensions that redefine their behavior"

or something along these lines.

[aswaterman]

I was thinking it might be better just to delete the note altogether, but I see the intent of other notes in this section is to highlight that mandating several of these extensions has only nominal impact on hardware cost. So I think it would better preserve the intent to change it along the lines of what you were suggesting.

[ved-rivos]

I think the note follows following Zcmop bullet and only applies to Zcmop. Unlike the MOPs defined in the Zimop extension, the C.MOP.n instructions are defined to not write any register. Perhaps the note can be updated to "Implementations can treat C.MOP.n as NOPs".

[aswaterman]

It looks to me like the note was trying to refer to both (since it was trying to justify that both extension are cheap). I'll find a way to fix it that's correct for both.

[aswaterman]

I went with:

"Implementations can simply write zero to the destination register (for Zimop) or treat as a NOP (for Zcmop), unless these instructions' behavior is overridden by another extension."

[james-ball-qualcomm]

Wow. That was fast. Thanks for the contributions so quickly. Looks good to me.

[aswaterman]

You're welcome!