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. Patch 2 in this series is a python script I put together to, hopefully help us identify if we're messing up the isa_edata_arr ordering and fix it before pushing changes upstream. I used it to validate the changes I did in patch 1 (the usual 'fix isa_edata_arr ordering' patch) and I can tell that the script picked up *way* more ordering errors that I was able to identify on my own. I didn't made any CI related changes w.r.t this new script but it is something to consider - if changes in target/riscv/cpu.c are made, run this script to validate the array again. Patches based on alistair/riscv-to-apply.next. Daniel Henrique Barboza (2): target/riscv/cpu.c: isa_edata_arr[] ordering fixes scripts: RISC-V python script to check isa_edata_arr[] scripts/riscv-isaedata-check.py | 164 ++++++++++++++++++++++++++++++++ target/riscv/cpu.c | 17 ++-- 2 files changed, 174 insertions(+), 7 deletions(-) create mode 100755 scripts/riscv-isaedata-check.py -- 2.51.1
