All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: Cupertino Miranda <cupertinomiranda@gmail.com>
Cc: Claudiu Zissulescu <claziss@gmail.com>,
	qemu-devel@nongnu.org, Shahab Vahedi <shahab.vahedi@gmail.com>,
	Shahab Vahedi <shahab@synopsys.com>,
	Cupertino Miranda <cmiranda@synopsys.com>,
	linux-snps-arc@lists.infradead.org,
	Claudiu Zissulescu <claziss@synopsys.com>
Subject: Re: [PATCH 06/15] arc: TCG instruction definitions
Date: Thu, 3 Dec 2020 10:07:56 -0600	[thread overview]
Message-ID: <1dbd9a59-8e6a-ee80-f7ae-a2990a059b21@linaro.org> (raw)
In-Reply-To: <CAHW_PjKs5LDkrFkqSGEKgw4sL3tuyc3-n6Uo4xYfHa8=376_Ew@mail.gmail.com>

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~

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

WARNING: multiple messages have this Message-ID (diff)
From: Richard Henderson <richard.henderson@linaro.org>
To: Cupertino Miranda <cupertinomiranda@gmail.com>
Cc: Claudiu Zissulescu <claziss@gmail.com>,
	qemu-devel@nongnu.org, Shahab Vahedi <shahab.vahedi@gmail.com>,
	Shahab Vahedi <shahab@synopsys.com>,
	Cupertino Miranda <cmiranda@synopsys.com>,
	linux-snps-arc@lists.infradead.org,
	Claudiu Zissulescu <claziss@synopsys.com>
Subject: Re: [PATCH 06/15] arc: TCG instruction definitions
Date: Thu, 3 Dec 2020 10:07:56 -0600	[thread overview]
Message-ID: <1dbd9a59-8e6a-ee80-f7ae-a2990a059b21@linaro.org> (raw)
In-Reply-To: <CAHW_PjKs5LDkrFkqSGEKgw4sL3tuyc3-n6Uo4xYfHa8=376_Ew@mail.gmail.com>

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~


  reply	other threads:[~2020-12-03 16:08 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-11 16:17 [PATCH 00/15] *** ARC port for review *** cupertinomiranda
2020-11-11 16:17 ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 01/15] arc: Add initial core cpu files cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-12-01 19:06   ` Richard Henderson
2020-12-01 19:06     ` Richard Henderson
2020-11-11 16:17 ` [PATCH 02/15] arc: Decoder code cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 03/15] arc: Opcode definitions table cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-12-01 20:22   ` Richard Henderson
2020-12-01 20:22     ` Richard Henderson
2021-01-15 17:11     ` Cupertino Miranda
2021-01-15 17:11       ` Cupertino Miranda
2021-01-15 19:52       ` Richard Henderson
2021-01-15 19:52         ` Richard Henderson
2020-11-11 16:17 ` [PATCH 04/15] arc: TCG and decoder glue code and helpers cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-12-01 21:35   ` Richard Henderson
2020-12-01 21:35     ` Richard Henderson
2021-01-15 17:11     ` Cupertino Miranda
2021-01-15 17:11       ` Cupertino Miranda
2021-01-15 20:31       ` Richard Henderson
2021-01-15 20:31         ` Richard Henderson
2021-01-15 21:48         ` Cupertino Miranda
2021-01-15 21:48           ` Cupertino Miranda
2021-01-15 21:53           ` Richard Henderson
2021-01-15 21:53             ` Richard Henderson
2021-01-15 22:06             ` Cupertino Miranda
2021-01-15 22:06               ` Cupertino Miranda
2021-01-15 21:28     ` Shahab Vahedi
2021-01-15 21:28       ` Shahab Vahedi
2021-01-15 21:51       ` Richard Henderson
2021-01-15 21:51         ` Richard Henderson
2020-11-11 16:17 ` [PATCH 05/15] arc: TCG instruction generator and hand-definitions cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-12-01 22:16   ` Richard Henderson
2020-12-01 22:16     ` Richard Henderson
2021-01-15 17:11     ` Cupertino Miranda
2021-01-15 17:11       ` Cupertino Miranda
2021-01-15 20:17       ` Richard Henderson
2021-01-15 20:17         ` Richard Henderson
2021-01-15 21:38         ` Cupertino Miranda
2021-01-15 21:38           ` Cupertino Miranda
2020-11-11 16:17 ` [PATCH 06/15] arc: TCG instruction definitions cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-12-01 23:09   ` Richard Henderson
2020-12-01 23:09     ` Richard Henderson
2020-12-02 12:55     ` Cupertino Miranda
2020-12-02 12:55       ` Cupertino Miranda
2020-12-03 16:07       ` Richard Henderson [this message]
2020-12-03 16:07         ` Richard Henderson
2020-12-03 16:54         ` Cupertino Miranda
2020-12-03 16:54           ` Cupertino Miranda
2020-12-03 19:34           ` Richard Henderson
2020-12-03 19:34             ` Richard Henderson
2020-12-03 19:51             ` Cupertino Miranda
2020-12-03 19:51               ` Cupertino Miranda
2021-01-15 17:11     ` Cupertino Miranda
2021-01-15 17:11       ` Cupertino Miranda
2020-11-11 16:17 ` [PATCH 07/15] arc: Add BCR and AUX registers implementation cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 08/15] arc: Add IRQ and timer subsystem support cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 09/15] arc: Add memory management unit (MMU) support cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 10/15] arc: Add memory protection unit (MPU) support cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 11/15] arc: Add gdbstub and XML for debugging support cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 12/15] arc: Add Synopsys ARC emulation boards cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 13/15] arc: Add support for ARCv2 cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 14/15] tests/tcg: ARC: Add TCG instruction definition tests cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:17 ` [PATCH 15/15] tests/acceptance: ARC: Add linux boot testing cupertinomiranda
2020-11-11 16:17   ` cupertinomiranda
2020-11-11 16:43 ` [PATCH 00/15] *** ARC port for review *** no-reply
2020-11-11 16:43   ` no-reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1dbd9a59-8e6a-ee80-f7ae-a2990a059b21@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=claziss@gmail.com \
    --cc=claziss@synopsys.com \
    --cc=cmiranda@synopsys.com \
    --cc=cupertinomiranda@gmail.com \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shahab.vahedi@gmail.com \
    --cc=shahab@synopsys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.