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~
