[PATCH 06/15] arc: TCG instruction definitions

[Richard Henderson]

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~