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 13:34:40 -0600 [thread overview]
Message-ID: <836f6aed-8f2a-cecc-d796-be7286333160@linaro.org> (raw)
In-Reply-To: <CAHW_Pj+0Ex_PWhUzv_Fkcp2B5yOcD=p31Lu2xH+Xp9M6mAf4Vw@mail.gmail.com>
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
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 13:34:40 -0600 [thread overview]
Message-ID: <836f6aed-8f2a-cecc-d796-be7286333160@linaro.org> (raw)
In-Reply-To: <CAHW_Pj+0Ex_PWhUzv_Fkcp2B5yOcD=p31Lu2xH+Xp9M6mAf4Vw@mail.gmail.com>
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~
next prev parent reply other threads:[~2020-12-03 19:34 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
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 [this message]
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=836f6aed-8f2a-cecc-d796-be7286333160@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.