Re: [PATCH 06/15] arc: TCG instruction definitions

[Cupertino Miranda]

Hi Richard,

Thanks for your quick reply, and again, thanks for the reviews.
We have already started to make very significant changes to the port
based on your comments. ;-)

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.

I believe that I can in relative short time isolate the TCG generator
and prepare a tool to process those comments and update the respective
TCG definitions.
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.

Thanks,
Cupertino


On Thu, Dec 3, 2020 at 4:08 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 12/2/20 6:55 AM, Cupertino Miranda wrote:
> > I totally understand your concerns with generated code.
> >
> > To explain our decision, we have an internal database that we are able
> > to describe the architecture and map encoding with hw semantics, and
> > for the sake of saving us debug time generating each and every
> > instruction, we use it to generate both the TCG and instruction
> > decoding tables that you have already reviewed.
> > This tool is not only used in QEmu but through all our tools code,
> > allowing us to cross validate the content of the database.
> >
> > Considering our situation and current state of the port, what would
> > you think is a reasonable compromise?
>
> In some respects you're in the same situation as the hexagon target that's
> currently in flight on the list -- both of you are wanting to generate tcg 
> from
> a company-specific canonical source.
>
> In the case of hexagon, the target/hexagon/imported/ subdirectory contains a
> bunch of stuff exported from Qualcomm's specification.  It's not fantastically
> readable, but it's not bad.  These files are then massaged in various ways to
> produce either (1) out-of-line helpers or (2) inline tcg stuff.
>
> Without knowing what form the Synopsys database takes, how easy would it be to
> export something mostly human-readable, which could then be processed by a 
> tool
> that is included in the qemu source?
>
> Future qemu maintainence is thus on the tool, and not on the auto-generated
> code.  There's also clear separation on what needs tcg review and what's 
> simply
> a spec update.
>
>
> r~