Thanks for the responses! I'm one of the maintainers of the UDB project, and serving as a mentor for Yash. I've added some comments inline below...
On Wednesday, October 8, 2025 at 11:43:51 AM UTC-5 [email protected] wrote: Hi Yash, Additionally, I'd like to add one more point: V8's backend does not support all RISC-V standard extensions. We only implement those extension instruction sets that can correspond to the machine IR generated after JavaScript and Wasm are lowered within V8. In other words, we only implement the extension instruction sets that help accelerate V8's execution, and there is no need to implement other redundant parts. Therefore, V8's current assembler, disassembler, and simulator do not actually need to handle all extensions. For the corresponding functional modules generated by UDB, is there the possibility of fine-grained selection of which extensions to implement and which not to? Yes. Configurability is built in. Here's a fairly minimal "RV32" configuration as an example: https://github.com/riscv-software-src/riscv-unified-db/blob/main/cfgs/rv32.yaml When new extensions need to be added in the future, will it require overall modifications or just incremental additions? You can just add the new extension to your configuration file. Does UDB have different versions due to its ongoing evolution, which may produce different results? I'd say no. There are efforts to finalize a "1.0" of the underlying schema, but the content is always based on the ratified specification, so the results won't change. The goal is to make adoption painless -- to generate content as close to what you have now as possible. These are all factors we need to consider. 在2025年10月8日星期三 UTC+8 13:52:13<Florian Loitsch> 写道： Hi Yash, I'm currently one of the maintainers of the RISC-V port, but can't speak for the other maintainers, some of whom have worked on the RISC-V port for much longer than me. >From my point of view creating the (dis)assembler sources from the UDB seems like the correct approach, but it's not clear whether changing the current sources is necessary: - the current (dis)assembler works and requires little maintenance effort. It's very rare that we start using a new instruction. - the build system for something that creates sources from a DB automatically becomes more complicated. Few of us like to review build-system code. - I'm worried that just reviewing the new code is more effort than any change we will make to that part of the code in the future. That said; if the CLs (pull requests) are small and easy to review I'm not against it. What we definitely don't want is a huge CL in some weeks that replaces thousands of lines of code with some other thousands of lines of code. I completely understand. I wouldn't want significant (or any) disruption without significant value, either. In the absence of "no", it's on us to produce something for your consideration. We'll take a stab at it and come back. We may have questions as we proceed, but hope to not become a nuisance. -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/bc067c44-c994-40c0-9ebe-1f147abccf7dn%40googlegroups.com.
