On Tue, 22 Nov 2022 07:20:15 PST (-0800), jeffreya...@gmail.com wrote:
On 11/20/22 18:36, Kito Cheng wrote:
So the idea here is just to define the extension so that it gets defined
in the ISA strings and passed through to the assembler, right?
That will also define arch test marco:
https://github.com/riscv-non-isa/riscv-c-api-doc/blob/master/riscv-c-api.md#architecture-extension-test-macro
Sorry I should have been clearer and included the test macro(s) as well.
So a better summary would be that while it doesn't change the codegen
behavior in the compiler, it does provide the mechanisms to pass along
isa strings to other tools such as the assembler and signal via the test
macros that this extension is available.
IMO the important bit here is that we're not adding any compatibility
flags, like we did when fence.i was removed from the ISA. That's fine
as long as we never remove these instructions from the base ISA in the
software, but that's what's suggested by Andrew in the post.
If so I think that it meets Andrew's requirements and at least some of
those issues raised by Jim. But I'm not sure it can address your
concern WRT consistency. In fact, I don't really see a way to address
that concern with option #2 which Andrew seems to think is the only
reasonable path forward from an RVI standpoint.
I'm at a loss for next steps, particularly as the newbie in this world.
It's a super weird one, but there's a bunch of cases in RISC-V where
we're told to just ignore words in the ISA manual. Definitely a trap
for users (and we already had some Linux folks get bit by the counter
changes here), but that's just how RISC-V works.
