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. On Mon, Oct 6, 2025 at 9:00 AM Yash Jha <[email protected]> wrote: > Hey v8 devs, > The simulator, the disassembler and many header files in the v8 can > benefit from an automation tool that transforms information from the spec, > RISC-V Unified Database potentially, to the provided format. > Starting with the disassembler, the code > <https://github.com/v8/v8/blob/main/src/diagnostics/riscv/disasm-riscv.cc>, > for example, contains TODOs and might be refactored with macros that can be > reused throughout the code. This refactoring can be easily generated using > the RISC-V Unified Database (UDB), a proven, ongoing effort to unify the > RISC-V specification. > > The new sub-category feature in the unified spec also provides > human-readable generation in the required control flow format. > > Moreover, an automated codegen also proves its realibility with the > development of various RISC-V extensions (AES, Zfa, CMOs, Scalar Crypto. > etc.) The automation pipeline can also expand on the turbofan micro > assembler /codegen for identifying optimization techniques. > > What do you (the developers) think of subsituting some parts of the code > with an automated system? Do you also believe it can this support v8's > motives and its connection with the ecosystem? I can already identify the > countless TODOs > <https://github.com/v8/v8/blob/main/src/diagnostics/riscv/disasm-riscv.cc> > in the disassembler that might help from the UDB. > > I pose this dicussion as a mentee for the Linux Mentorship program. > <https://mentorship.lfx.linuxfoundation.org/project/89bd89b0-8a0e-42ef-9251-c7916b1c1d4b> > Would appreciate your thoughts on this bridge. > With warm regards, > Yash > > -- > -- > 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/f902f493-6138-4f1f-b581-1e9eb66dbb77n%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/f902f493-6138-4f1f-b581-1e9eb66dbb77n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- 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/CA%2B-a-b1dZ2SJ-6jgMRszffroDJ7KyPNGKn0Rv0-ZFgYPhHZkOw%40mail.gmail.com.
