On 11/6/25 12:48 PM, Conor Dooley wrote:
On Thu, Nov 06, 2025 at 08:20:42AM -0300, Daniel Henrique Barboza wrote:
Hi,
We have an array called isa_edata_arr[] in target/riscv/cpu.c which
needs to be always kept in the RISC-V specification riscv,isa order.
Easier said that done: as more and more extensions are added we're
failing to keep up with the array ordering in the review process.
I have considered changing how we're retrieving riscv,isa to not rely on
the array ordering (in fact I have code that does that). We would sort
the enabled extensions using riscv,is ordering during init time, before
writing it in the DT, ignoring the current isa_edata_arr ordering. When
all was said and done that sounded a bit extreme and I think there's
other stuff we can try first.
FWIW, I have yet to actually see a parser for it in a "real" application
that relied on the ordering. It probably makes a parser more complicated
to write than one where the ordering is ignored. The only time I can really
see ordering mattering is if something has a very simple bit of code and
is looking for "rv##ima" or similar, and using a string comparison
function.
Either way, my point basically is that you shouldn't have to go to any
extreme effort to make sure it is perfect, particularly when it comes to
the multiletter stuff as, at least for devicetree, the binding has never
enforced ordering for multiletter extensions. I know ACPI cites spec
order (and spec definitions, so GL there lol), and there could be relevant
for some ACPI only code where the devicetree parser is not being reused.
Thanks for the insight. Yeah, I haven't seen software caring that much about
the riscv,isa ordering either. In case it exists it would be broken in QEMU
given that we're using the wrong order :D
Thanks,
Daniel
