Seems perfectly doable, no objections. It will probably take me longer to integrate it in the build system then to get the scripts ready. I will start by placing the ruby tool and documentation there, and later on, integrate it in the build system.
Hope that you get re-motivated to review our patches. No pressure though ;-) Very valuable comments, lots of improvements happening here. On Thu, Dec 3, 2020 at 7:34 PM Richard Henderson <richard.hender...@linaro.org> wrote: > > On 12/3/20 10:54 AM, Cupertino Miranda wrote: > > Our generation tool has different levels of verbosity, expressing > > instruction semantics from a pattern level up to what it is shown in > > <semfunc.c> as comments, which is later converted to TCG format. > > For QEMU purposes I would say that input format should be what is > > shown as comments in <semfunc.c> file. > > That seems reasonable. > > > Also, as is, the generator is done in Ruby, and to be honest, would > > not be very easy to redo in some other language. Would this be > > considered a problem if we would include it as Ruby code ? > > IMO execution of these scripts should not be a step of build process > > but rather a development one, such that Ruby does not become a > > requirement to build QEmu. > > It's not ideal -- I would have preferred python or C -- but I won't object. > > At minimum, I would expect build system changes that detects ruby support in > the system, and a manual build rule that rebuilds the generated files. This > build + check-in process would want documenting in target/arc/README or > something. If there are any ruby packages required apart from the base > language, this should be documented as well (I know nothing about ruby myself, > just guessing based on what happens with python and perl). > > Even better would be build system changes that, if ruby is installed runs the > generator, and only fall-back to the checked-in files if ruby is missing. > > In this way, anyone who wants to modify the code generator would merely have > to > install the ruby packages on their system, but they would not be required for > a > non-ARC developer to build. > > > r~
