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
<> 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~

linux-snps-arc mailing list

Reply via email to