KIto,
Thanks for summarizing this.
As discussed in one of the last psABI meetings, the option best
mirroring the behavior intended by the ISA specifications is "Option
3: use -misa-spec to decide what to do": unfortunately, the different
ISA specification versions define a different "expansion from string
to features" and thus we need to qualify the architecture-string
(i.e., march=) in conjunction with the specification version (i.e.
misa-spec=).
A few more comments inline below.
Given that these CSRs will not be widely accessed (i.e. mainly in
software running at higher privilege modes), we might get away with
breaking backward compatibility in this specific case.
However, this does probably not hold for future changes that may
impact widely visible features — so whatever solution we decide on at
this time, should be generally applicable.
> Option 2: who cares about these details
>
> Make the CSRs always available, even when zicntr or zihpm are not
> specified in the march string. Expose the test macros based on the
> availability of the extension (via march string).
>
> Pros: No compatibility issue.
> Cons: Unexpected behavior (CSRs are available although the compiler
> knows better); potentially harmful (compiler errors are expected to
> prevent unsupported code from being generated);
>
> ## Option 3: use -misa-spec to decide what to do
>
> Additionally to the flag -march=... the tools also have the flag
> -misa-spec to control the behavior of the extension parser. Currently,
> the misa-spec string can be "2.2" | "20190608" | "20191213". That flag
> is also, where would add the new profiles ("rv20" and "rv22").
>
> So for the existing misa-spec strings we would keep the current
> behavior, but for the new "rv20" and "rv22" strings, we would change
> the behavior.
From my understanding this does not entirely reflect the upstream
specification changes: any specification version that qualifies these
as explicitly gated by these new extension names will have to require
the changed behavior (i.e., not just the new profiles). Consider the
profiles as a fancy name (or a macro) expanding to a single well-known
misa-spec= and march= combination: besides using the profiles, users
will still be able to construct different misa-spec/march pairs and we
will need to process them appropriately.
> Pros: we don't try to solve a problem that is not tool-specific but
> ISA-specific; we have an option to get the old functionality back (the
> default misa-spec can be set when building a compiler using
> "--with-isa-spec=...")
> Cons: Users need to be made aware of the issue; more work with
> processing error reports from users
>
> ## Option 4: something else?
>
> The three options above are not the only existing solutions. If you
> are interested in some other solution, please share your thoughts!
>
> # References
>
> [1] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aZhMG7NIVTk/m/hX2BRWsMEQAJ
> [2] https://github.com/riscv/riscv-profiles/issues/43
Thanks,
Philipp.
## Option 3: use -misa-spec to decide what to do
Additionally to the flag -march=... the tools also have the flag
-misa-spec to control the behavior of the extension parser. Currently,
the misa-spec string can be "2.2" | "20190608" | "20191213". That flag
is also, where would add the new profiles ("rv20" and "rv22").
So for the existing misa-spec strings we would keep the current
behavior, but for the new "rv20" and "rv22" strings, we would change
the behavior.
Pros: we don't try to solve a problem that is not tool-specific but
ISA-specific; we have an option to get the old functionality back (the
default misa-spec can be set when building a compiler using
"--with-isa-spec=...")
Cons: Users need to be made aware of the issue; more work with
processing error reports from users
## Option 4: something else?
The three options above are not the only existing solutions. If you
are interested in some other solution, please share your thoughts!
# References
[1] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aZhMG7NIVTk/m/hX2BRWsMEQAJ
[2] https://github.com/riscv/riscv-profiles/issues/43
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CALLt3TjDmJXT-0frrczpA94cCEwBm-J31T1JxBsGNLB7wpUMAg%40mail.gmail.com.
On Thu, May 26, 2022 at 11:19 PM Kito Cheng <kito....@sifive.com> wrote:
Option 2: who cares about these details
Make the CSRs always available, even when zicntr or zihpm are not
specified in the march string. Expose the test macros based on the
availability of the extension (via march string).
Pros: No compatibility issue.
Cons: Unexpected behavior (CSRs are available although the compiler
knows better); potentially harmful (compiler errors are expected to
prevent unsupported code from being generated);The RISC-V architects have long been clear that this is the only answer that we think is sensible. (It almost seems like you are going to these mailing lists because you didn’t like the answer we provided in other forums…)We only approved these specific backwards-incompatible changes on the basis that they will, in fact, “just work” in practice. We wouldn’t have done so for extensions that compilers actually need to target.
On Fri, May 27, 2022 at 6:37 AM Andrew Waterman <and...@sifive.com> wrote:On Thu, May 26, 2022 at 11:19 PM Kito Cheng <kito....@sifive.com> wrote:
Option 2: who cares about these details
Make the CSRs always available, even when zicntr or zihpm are not
specified in the march string. Expose the test macros based on the
availability of the extension (via march string).
Pros: No compatibility issue.
Cons: Unexpected behavior (CSRs are available although the compiler
knows better); potentially harmful (compiler errors are expected to
prevent unsupported code from being generated);The RISC-V architects have long been clear that this is the only answer that we think is sensible. (It almost seems like you are going to these mailing lists because you didn’t like the answer we provided in other forums…)We only approved these specific backwards-incompatible changes on the basis that they will, in fact, “just work” in practice. We wouldn’t have done so for extensions that compilers actually need to target.It is confusing for end users if the compiler handles different ISA extensions in different ways. I think zicntr should work exactly the same as M. If M is enabled, then the assembler accepts multiply instructions, the compiler generates multiply instructions, and the compiler defines __riscv_m so that user code can check if multiply is safe to use in an extended asm in C code or in assembly code. If M is not enabled, then the assembler rejects multiply instructions, the compiler does not generate them, and __riscv_m is not defined so user code knows not to use multiply instructions. zicntr should work exactly the same way.Your argument is that because the compiler can't generate a rdcycle instruction, we don't need the same support.
On Fri, May 27, 2022 at 9:13 AM Jim Wilson <jim.wil...@gmail.com> wrote:On Fri, May 27, 2022 at 6:37 AM Andrew Waterman <and...@sifive.com> wrote:On Thu, May 26, 2022 at 11:19 PM Kito Cheng <kito....@sifive.com> wrote:
Option 2: who cares about these details
Make the CSRs always available, even when zicntr or zihpm are not
specified in the march string. Expose the test macros based on the
availability of the extension (via march string).
Pros: No compatibility issue.
Cons: Unexpected behavior (CSRs are available although the compiler
knows better); potentially harmful (compiler errors are expected to
prevent unsupported code from being generated);The RISC-V architects have long been clear that this is the only answer that we think is sensible. (It almost seems like you are going to these mailing lists because you didn’t like the answer we provided in other forums…)We only approved these specific backwards-incompatible changes on the basis that they will, in fact, “just work” in practice. We wouldn’t have done so for extensions that compilers actually need to target.It is confusing for end users if the compiler handles different ISA extensions in different ways. I think zicntr should work exactly the same as M. If M is enabled, then the assembler accepts multiply instructions, the compiler generates multiply instructions, and the compiler defines __riscv_m so that user code can check if multiply is safe to use in an extended asm in C code or in assembly code. If M is not enabled, then the assembler rejects multiply instructions, the compiler does not generate them, and __riscv_m is not defined so user code knows not to use multiply instructions. zicntr should work exactly the same way.Your argument is that because the compiler can't generate a rdcycle instruction, we don't need the same support.Yes, that’s the extent of my argument. And I stand by it.
It should be noted that defining zicntr and zihpm is _not_ a change to any existing ratified ISA standard, despite the comments to the contrary on this thread. The counters were not part of the base ISA as it was ratified several years ago. (They were part of an earlier non-ratified version.)The error on RVIA’s part is that we neglected to define an extension name to represent the counters. That’s what we fixed recently in defining zicntr and zihpm.
I'm not appreciating the need to reference a version of an ISA spec document. Once an extension is ratified, it does not change from there on in ALL versions of ISA specs. One should be able to look at ANY version of an ISA spec that contains a ratified version of the extension - which is documented up front in the Preface of the document.