M implies Zmmul

[nick-knight]

Zmmul is defined to be a subset of M. It follows that M implies Zmmul. This closes #869. It also resolves a question raised in the Toolchains SIG: riscv-non-isa/riscv-asm-manual#91 (comment).

This PR adds this implication to a table in the "ISA Naming Conventions" chapter. (EDIT: and also in the M chapter.)

[aswaterman]

Can we also clean up the text in the Zmmul section in the M chapter to make the implication clear?

[nick-knight]

I welcome feedback on how to better clean up the M chapter. I just added a sentence.

[topperc]

This potentially breaks using a new clang with an old gnu assembler if the old assembler doesn't know about zmmul. That's why I was hesitant to make the implication in the tools.

[nick-knight]

@topperc will this same problem arise in the future when we define a subset of an existing standard extension, making the superset imply the subset? (This seems unfortunate.)

[aswaterman]

I don't want to break the new compiler + old assembler combo (unless perhaps we are checking at compiler build/install time that it's compatible with the installed assembler).

But maybe this is an indication that it's inadvisable to retcon implication relationships. I'm really not sure; I want to do whatever's most pragmatic.

[nick-knight]

In the issue associated with this PR, #869, @kasanovic stated:

Zmmul is implied by M - it is a proper subset of the instructions in M.

If there is debate about this, perhaps we should move the discussion back to that issue.

[allenjbaum]

Actually, I'm not sure if that is the case or not. M is disabled by MISA.M. If Zmmul is implied by M, it would be disabled if MISA.M is cleared, and I don't believe that is the case. The spec simply says that "The Zmmul extension implements the multiplication subset of the M extension... [with] The encodings are identical to those of the corresponding M-extension instructions. You could argue that this implies that it must also be enabled by MISA.M, but that's a bit of a stretch to me.

…

On Wed, Sep 13, 2023 at 5:26 PM Nick Knight ***@***.***> wrote: In the issue associated with this PR, #869 <#869>, @kasanovic <https://github.com/kasanovic> stated: Zmmul *is* implied by M - it is a proper subset of the instructions in M. If there is debate about this, perhaps we should move the discussion back to that issue. — Reply to this email directly, view it on GitHub <#1121 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJTL2VF7BHF7ONGSFVTX2JFM3ANCNFSM6AAAAAA4T4IUOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[nick-knight]

Hi Allen, are you reiterating the comment you made 14 months ago over at #869 ? If so, do you have a response to Krste's response to you?

Taking a step back, I was filing this PR to clean up what I perceived as technical debt. Clearly there is more debate to be had over at #869 . I didn't mean to fragment the discussion.

[allenjbaum]

Yes, exactly. I don't agree that M implies Zmmul. I agree (pedantically, as I said in #869) that M implies the same mul ops as Zmmul. I have no opinion about whether the behavioral difference affects toolchains or not, but I suspect not. And that may be all that really matters for this.

…

On Wed, Sep 13, 2023 at 10:33 PM Nick Knight ***@***.***> wrote: Hi Alan, are you reiterating the comment you made 14 months ago over at #869 <#869> ? If so, do you have a response to Krste's response to you? — Reply to this email directly, view it on GitHub <#1121 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJWQVOA6IHWGERADBFTX2KJLLANCNFSM6AAAAAA4T4IUOA> . You are receiving this because you commented.Message ID: ***@***.***>

[kito-cheng]

To me, it's part of cannibalization rule we should define clearly, what's the standard rule for those situation? we should have consistent rule.

The question is something like does rv32im_zmmul is equal to rv32im? The answer is yes I believe, but which one is canonicalization form? IMO human and machine can easier to know two arch string are equivalent after canonicalization , but the rule is broken.

It's not human should care in general, but psABI spec do care about this since psABI specify the arch string should canonicalize the arch string before encoding into file, so NO clear canonicalization rule made psABI spec ambiguous.

C and Zca are the same issue IMO.

That's affect toolchain AND how people check a extension, what if user want to check multiplication instructions? user need to check two extension, __riscv_zmmul or __riscv_m rather than just check __riscv_zmmul.

And again, same situation for Zca vs C.

Also the situation is happened between V and Zve* extensions, and spec explicitly say V require/depend on Zve*, why we consider inconsistent behavior for M and Zmmul?

So I strongly support M should implied Zmmul AND C should implied Zca.

[topperc]

My primary concerns with making M imply Zmmul is that LLVM passes all implied extensions through to ELF attributes and probably on to external tools like assembler. Should we canonicalize the string passed on to remove extensions implied by other extensions?

My other concern is that telling users they can check __riscv_zmmul to detect multiply instructions means their code will only detect multiply instructions when used with a newer compiler that knows about Zmmul and believes Zmmul to be a subset of M. I thought I could suggest undeprecating __riscv_mul but gcc doesn't set it for Zmmul, clang does.

Not compiler related, but if hwprobe supported Zmmul would it return true for a CPU that supports M? Or would that require the DTS to say Zmmul in addition to M? I don't if hwprobe also has to know about implications.

[nick-knight]

I think the architects need to reach a consensus on the definition of "implies", "subset", etc., particularly in the presence of privileged state like misa, mstatus, etc. While this thread concerns M vs. Zmmul, I expect this debate to flare up elsewhere (V vs. Zve*, C vs. Zc*, ...). This is a broader debate than I set out to address in this PR.

Compile-time feature detection obviously cannot handle the possibility of misa, so I think that toolchain folks can ignore this debate, and focus on building things that are useful to software engineers. I think this discussion belongs over at the riscv-non-isa repos.

[allenjbaum]

I agree that we need a precise definition of "implies". If I can write a test that can distinguish between RV32IM and RV32IM_Zmmul, does that still allow Zmmul to be iabelled as implied by M? (spoiler: you can if MISA.M is RW, and can't if it isn't)

…

On Fri, Sep 15, 2023 at 7:56 AM Nick Knight ***@***.***> wrote: I think the architects need to reach a consensus on the definition of "implies", "subset", etc., particularly in the presence of privileged state like misa, mstatus, etc. While this thread concerns M vs. Zmmul, I expect this debate to flare up elsewhere (V vs. Zve*, C vs. Zc*, ...). This is a broader debate than I set out to address in this PR. Compile-time feature detection obviously cannot handle the possibility of misa, so I think that toolchain folks can ignore this debate, and focus on building things that are useful to software engineers. I think this discussion belongs over at the riscv-non-isa repos. — Reply to this email directly, view it on GitHub <#1121 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJS3LEDGCGKVM47DGW3X2RUC5ANCNFSM6AAAAAA4T4IUOA> . You are receiving this because you commented.Message ID: ***@***.***>

[kasanovic]

There has always been clear agreement on what implies/requires means (it means the features within the implied extension must exist if the implying extension is present). M_Zmmul should cause no difference in behavior than saying M on command line, and M is the canonical representation of the union. The issue is not the definition of implies, the issue is with how toolchains can manage the extension name space.

The toolchain problem is that life is simpler if they only have to represent the finest granularity of extension optionality, and not worry that existing extensions will be broken into sub extensions. OTOH, maintaining a feature vector at the granularity of every indivisible ISA feature (e.g., not only a field in a CSR, but an individual settable value of a field in a CSR) is not practical.

To answer @topperc question, all implied extensions should be made visible in any feature vector of "extensions supported" visible to downstream software. When a new sub extension is added, this will add a new feature in the feature vector. old software would only be checking for the old larger extension name (M here), and new software that only cares about the subextension will only check for the new sub-extension flag and should operate correctly if only the larger extension name is present. I don't see how any other behavior would make sense?

The issue with misa.M definition is separate from toolchain command-line option parsing. M/Zmmul specs do not mention misa, so should not read on misa spec. misa is not visible to almost all code ( I know tests might look there, but even nearly all of those shouldn't). 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. But the real problem is that misa was not designed to support fine-grain extensions, and dynamic switching was also not architected to support all use cases.

[topperc]

To answer @topperc question, all implied extensions should be made visible in any feature vector of "extensions supported" visible to downstream software. When a new sub extension is added, this will add a new feature in the feature vector. old software would only be checking for the old larger extension name (M here), and new software that only cares about the subextension will only check for the new sub-extension flag and should operate correctly if only the larger extension name is present. I don't see how any other behavior would make sense?

assembers and compilers reject a -march command line option with unknown extension names. When gcc (or clang in no integrated assembler mode) invoke the assembler they need to pass a -march to the assembler. Since gcc and clang can be upgraded independent of the assembler this can cause an error if the compiler knows M implies Zmmul, but the assembler has never heard of Zmmul.

Maybe you're suggesting the parsing of -march in tools should ignore unknown extension names?

[allenjbaum]

Oh, that is pretty clever, and I'm still on the fence whether you can interpret the spec that way. From MISA spec: When a standard extension is disabled by clearing its bit in misa, the instructions and CSRs defined or modified by the extension revert to their defined or reserved behaviors as if the extension is not implemented. That clearly distinguishes a writable MISA.M being zero from a RdOnly MISA.M being zero. The Zmmul spec says: "The Zmmul extension implements the multiplication subset of the M extension." It adds all of the instructions defined in Section 9.1 This is why lawyers are expensive. You can argue that this adds copies of the multiplication ops, which just happen to have to same encodings and operations as the M-extension, and since they exist separately, the M-versions may no longer work, but these versions do. Or, if on on the other side of the courtroom, you'd argue that no, they are really one and the same, and the fact that MISA.M can be cleared implies that it won't work. Or you can be a Supreme Court justice named Solomon and say you're both right, it is implementation dependent. I don't think it is obvious which way the justices would rule on this, but this is a nuance we will now have to build into the ACTs.... I would have been a lot happier if my suggestion that M and Zmmul be made incompatible with each other and just prohibited the combination had been accepted (you can't depend on it, so why allow it?)

…

On Fri, Sep 15, 2023 at 2:42 PM Krste Asanovic ***@***.***> wrote: There has always been clear agreement on what implies/requires means (it means the features within the implied extension must exist if the implying extension is present). M_Zmmul should cause no difference in behavior than saying M on command line, and M is the canonical representation of the union. The issue is not the definition of implies, the issue is with how toolchains can manage the extension name space. The toolchain problem is that life is simpler if they only have to represent the finest granularity of extension optionality, and not worry that existing extensions will be broken into sub extensions. OTOH, maintaining a feature vector at the granularity of every indivisible ISA feature (e.g., not only a field in a CSR, but an individual settable value of a field in a CSR) is not practical. To answer @topperc <https://github.com/topperc> question, all implied extensions should be made visible in any feature vector of "extensions supported" visible to downstream software. When a new sub extension is added, this will add a new feature in the feature vector. old software would only be checking for the old larger extension name (M here), and new software that only cares about the subextension will only check for the new sub-extension flag and should operate correctly if only the larger extension name is present. I don't see how any other behavior would make sense? The issue with misa.M definition is separate from toolchain command-line option parsing. M/Zmmul specs do not mention misa, so should not read on misa spec. misa is not visible to almost all code ( I know tests might look there, but even nearly all of those shouldn't). 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. But the real problem is that misa was not designed to support fine-grain extensions, and dynamic switching was also not architected to support all use cases. — Reply to this email directly, view it on GitHub <#1121 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJXSDSZGXTUIG3WI473X2TDTDANCNFSM6AAAAAA4T4IUOA> . You are receiving this because you commented.Message ID: ***@***.***>

[nick-knight]

I am satisfied with @kasanovic's argument that this PR is compatible with misa behavior, so I'm reopening it.

My perspective remains that this is simply a (non-normative) clarification. If there are ramifications for certain toolchains, that discussion belongs elsewhere.

[a4lg]

@kito-cheng
I was a bit hesitant to make C → Zca implication without clear resolution (so asked everywhere for clarification including riscv-non-isa/riscv-asm-manual#91) because this is far more destructive than M → Zmmul but generally, I think feature == extension is simpler (while I feel that recent decision on the Toolchain SIG ― extension implication should only apply when the specification specifies ― makes sense).

@topperc
I admit that some version compatibility problem (between the compiler and the assembler) exists but I don't think this is a major blocker for this issue because it's hard to imagine that both programs are out of sync so much.

[topperc]

@topperc I admit that some version compatibility problem (between the compiler and the assembler) exists but I don't think this is a major blocker for this issue because it's hard to imagine that both programs are out of sync so much.

That's probably true now that Zmmul has been in tools for a while, but it wasn't true when Zmmul was first added to a compiler. The installed assembler could very easily not have known about it.

We could probably change it in the tools now without much issue. But does that mean for every future subset extension we need some grace period to avoid creating compiler/assembler incompatibility?

I agree this isn't a blocker for this issue.

[kasanovic]

Let me clarify my comment on feature vector. The feature vector is an abstract notion of what exists in the ISA set in some environment. How this is presented to various parts of older software will vary, but if a given piece of software doesn't understand a subset extension there's nothing really to do except update it or force all surrounding software to adapt.

For the specific case that some toolchain components don't yet understand a new subset extension, the components can only continue to use the larger extensions that they do understand. This will mean that a compiler that understands Zmmul should set Zmmul, not M, on assembler command line if only Zmmul is specified on its command line, and the assembler will rightly complain if it doesn't understand Zmmul. If user specified both Zmmul and M, then the canonical expansion will simplify to M, and everything should work. Another workaround when Zmmul is actually intended but not supported is for the user to use M and not Zmmul. Yes, this will incorrectly cause assembler to not warn about non-existent divide instructions but that's the best the toolchain can support. I don't see a simpler alternative path here - the components have to understand the subset extension to use it precisely. The assembler simply needs updating to understand Zmmul. (I'll note from almost all users' perspective, if the assembler in a toolchain doesn't support Zmmul, the compiler doesn't either.)