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.
signature.asc
Description: PGP signature
