From: "Alex Bennée" <alex.bennee@linaro.org>
To: Robert Foley <robert.foley@linaro.org>
Cc: qemu-devel@nongnu.org, cota@braap.org,
aaron@os.amperecomputing.com,
Peter Puhov <peter.puhov@linaro.org>,
kuhn.chenqun@huawei.com, robhenry@microsoft.com,
Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <Alistair.Francis@wdc.com>,
Sagar Karandikar <sagark@eecs.berkeley.edu>,
Bastian Koppelmann <kbastian@mail.uni-paderborn.de>,
"open list:RISC-V TCG CPUs" <qemu-riscv@nongnu.org>
Subject: Re: [PATCH v1 4/5] target/riscv: progressively load the instruction during decode
Date: Fri, 07 Feb 2020 16:47:30 +0000 [thread overview]
Message-ID: <87blqa73a5.fsf@linaro.org> (raw)
In-Reply-To: <CAEyhzFuaDk6CCO72UD0vE9j+Eo=StnoEpWEg5iqOubGhdzXxag@mail.gmail.com>
Robert Foley <robert.foley@linaro.org> writes:
> Hi,
> On Fri, 7 Feb 2020 at 10:01, Alex Bennée <alex.bennee@linaro.org> wrote:
>> -static void decode_RV32_64C0(DisasContext *ctx)
>> +static void decode_RV32_64C0(DisasContext *ctx, uint16_t opcode)
>> {
>> - uint8_t funct3 = extract32(ctx->opcode, 13, 3);
>> - uint8_t rd_rs2 = GET_C_RS2S(ctx->opcode);
>> - uint8_t rs1s = GET_C_RS1S(ctx->opcode);
>> + uint8_t funct3 = extract32(opcode, 13, 3);
>
> We noticed that a uint16_t opcode is passed into this function and
> then passed on to extract32().
> This is a minor point, but the extract32() will validate the start and
> length values passed in according to 32 bits, not 16 bits.
> static inline uint32_t extract32(uint32_t value, int start, int length)
> {
> assert(start >= 0 && length > 0 && length <= 32 - start);
> Since we have an extract32() and extract64(), maybe we could add an
> extract16() and use it here?
Yeah - I did consider if it would be worth adding a extract16 helper.
There are a fair number of places in the code base where uint16_t is
silently promoted to a uint32_t (and a couple where it is downcast).
I guess 16 bit instruction words are common enough we should support
them in the utils.
--
Alex Bennée
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Robert Foley <robert.foley@linaro.org>
Cc: Alistair Francis <Alistair.Francis@wdc.com>,
"open list:RISC-V TCG CPUs" <qemu-riscv@nongnu.org>,
Sagar Karandikar <sagark@eecs.berkeley.edu>,
Bastian Koppelmann <kbastian@mail.uni-paderborn.de>,
qemu-devel@nongnu.org, robhenry@microsoft.com,
aaron@os.amperecomputing.com, cota@braap.org,
Palmer Dabbelt <palmer@dabbelt.com>,
kuhn.chenqun@huawei.com, Peter Puhov <peter.puhov@linaro.org>
Subject: Re: [PATCH v1 4/5] target/riscv: progressively load the instruction during decode
Date: Fri, 07 Feb 2020 16:47:30 +0000 [thread overview]
Message-ID: <87blqa73a5.fsf@linaro.org> (raw)
In-Reply-To: <CAEyhzFuaDk6CCO72UD0vE9j+Eo=StnoEpWEg5iqOubGhdzXxag@mail.gmail.com>
Robert Foley <robert.foley@linaro.org> writes:
> Hi,
> On Fri, 7 Feb 2020 at 10:01, Alex Bennée <alex.bennee@linaro.org> wrote:
>> -static void decode_RV32_64C0(DisasContext *ctx)
>> +static void decode_RV32_64C0(DisasContext *ctx, uint16_t opcode)
>> {
>> - uint8_t funct3 = extract32(ctx->opcode, 13, 3);
>> - uint8_t rd_rs2 = GET_C_RS2S(ctx->opcode);
>> - uint8_t rs1s = GET_C_RS1S(ctx->opcode);
>> + uint8_t funct3 = extract32(opcode, 13, 3);
>
> We noticed that a uint16_t opcode is passed into this function and
> then passed on to extract32().
> This is a minor point, but the extract32() will validate the start and
> length values passed in according to 32 bits, not 16 bits.
> static inline uint32_t extract32(uint32_t value, int start, int length)
> {
> assert(start >= 0 && length > 0 && length <= 32 - start);
> Since we have an extract32() and extract64(), maybe we could add an
> extract16() and use it here?
Yeah - I did consider if it would be worth adding a extract16 helper.
There are a fair number of places in the code base where uint16_t is
silently promoted to a uint32_t (and a couple where it is downcast).
I guess 16 bit instruction words are common enough we should support
them in the utils.
--
Alex Bennée
next prev parent reply other threads:[~2020-02-07 16:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-07 15:01 [PATCH v1 0/5] plugins/next Alex Bennée
2020-02-07 15:01 ` [PATCH v1 1/5] docs/devel: document query handle lifetimes Alex Bennée
2020-02-07 16:38 ` Robert Foley
2020-02-09 18:20 ` Richard Henderson
2020-02-07 15:01 ` [PATCH v1 2/5] plugins/core: add missing break in cb_to_tcg_flags Alex Bennée
2020-02-11 17:56 ` Richard Henderson
2020-02-07 15:01 ` [PATCH v1 3/5] tests/plugin: prevent uninitialized warning Alex Bennée
2020-02-11 17:57 ` Richard Henderson
2020-02-07 15:01 ` [PATCH v1 4/5] target/riscv: progressively load the instruction during decode Alex Bennée
2020-02-07 15:01 ` Alex Bennée
2020-02-07 16:33 ` Robert Foley
2020-02-07 16:33 ` Robert Foley
2020-02-07 16:47 ` Alex Bennée [this message]
2020-02-07 16:47 ` Alex Bennée
2020-02-11 18:00 ` Richard Henderson
2020-02-11 18:00 ` Richard Henderson
2020-02-07 15:01 ` [PATCH v1 5/5] tests/plugins: make howvec clean-up after itself Alex Bennée
2020-02-10 19:34 ` Robert Foley
2020-02-11 18:01 ` Richard Henderson
2020-02-07 20:55 ` [PATCH v1 0/5] plugins/next no-reply
2020-02-07 21:27 ` 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=87blqa73a5.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Alistair.Francis@wdc.com \
--cc=aaron@os.amperecomputing.com \
--cc=cota@braap.org \
--cc=kbastian@mail.uni-paderborn.de \
--cc=kuhn.chenqun@huawei.com \
--cc=palmer@dabbelt.com \
--cc=peter.puhov@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=robert.foley@linaro.org \
--cc=robhenry@microsoft.com \
--cc=sagark@eecs.berkeley.edu \
/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.