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~
