On Fri, 29 Sept 2023 at 14:37, Thomas Huth wrote:
>
> There are a bunch of RISC-V files that are currently not covered
> by the "get_maintainers.pl" script. Add them to the right sections
> in MAINTAINERS to fix this problem.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Philipp Tomsich
as trans_xventanacondops.c.inc.
Reviewed-by: Richard Henderson
Signed-off-by: Philipp Tomsich
---
(no changes since v3)
Changes in v3:
- Don't downgrade to "Odd Fixes", but rather to "Maintained" (we are
not being paid to look after this, but will look after it
nonetheless).
Ch
this
via gen_logic and 2 helper functions (effectively partial closures).
Reviewed-by: Richard Henderson
Signed-off-by: Philipp Tomsich
---
Changes in v5:
- fix a rebase artifact
- drop the 'inline' specifiers (as per review comments)
Changes in v4:
- rebase onto master
Changes in v3:
- don't add
After the original Zicond support was stuck/fell through the cracks on
the mailing list at v3 (and a different implementation was merged in
the meanwhile), we now refactor Zicond and then reuse it in
XVentanaCondOps.
Philipp Tomsich (2):
target/riscv: refactor Zicond support
target/riscv
Alistair,
On Mon, 6 Mar 2023 at 05:53, Alistair Francis wrote:
>
> On Wed, Feb 8, 2023 at 12:40 AM Philipp Tomsich
> wrote:
> >
> > This implements the Zicond (conditional integer operations) extension,
> > as of version 1.0-draft-20230120 as an experimental exten
this
via gen_logic and 2 helper functions (effectively partial closures).
Signed-off-by: Philipp Tomsich
---
Changes in v4:
- rebase onto master
Changes in v3:
- don't add this to MAINTAINERS, as it is an official extension
Changes in v2:
- gates availability of the instructions through
as trans_xventanacondops.c.inc.
Signed-off-by: Philipp Tomsich
---
(no changes since v3)
Changes in v3:
- Don't downgrade to "Odd Fixes", but rather to "Maintained" (we are
not being paid to look after this, but will look after it
nonetheless).
Changes in v2:
- Calls into the gen_cze
On Mon, 27 Feb 2023 at 10:04, Ivan Klokov wrote:
>
> The decoding of the slli_uw currently contains decoding
> error: shamt part of opcode has six bits, not five.
>
> Fixes 3de1fb71("target/riscv: update disas.c for xnor/orn/andn and slli.uw")
>
> Signed-off-by: Iva
nload/v1.0-draft-20230120/riscv-zicond_1.0-draft-20230120.pdf
for the (current version of the) Zicond specification and usage details.
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- don't add this to MAINTAINERS, as it is an official extension
Changes in v2:
- gates availability of the inst
as trans_xventanacondops.c.inc will not see
active maintenance from here forward.
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- Don't downgrade to "Odd Fixes", but rather to "Maintained" (we are
not being paid to look after this, but will look after it
nonetheless).
Ch
On Thu, 2 Feb 2023 at 18:35, Richard Henderson
wrote:
>
> On 2/2/23 04:30, Philipp Tomsich wrote:
> > On the second pass over these patches, here's how we can use gvec
> > support for both vror and vrol:
> >
> > /* Synthesize a rotate-right from a negate(shift-amoun
On Thu, 2 Feb 2023 at 15:13, Philipp Tomsich wrote:
>
> On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
> wrote:
> >
> > From: Dickon Hood
> >
> > Add an initial implementation of the vrol.* and vror.* instructions,
> > with mappings between the RIS
On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
wrote:
>
> From: Nazar Kazakov
>
> Signed-off-by: Nazar Kazakov
> ---
> target/riscv/helper.h | 9 +
> target/riscv/insn32.decode | 3 +++
> target/riscv/insn_trans/trans_rvzvkb.c.inc | 5 +
>
On Thu, 2 Feb 2023 at 15:23, Philipp Tomsich wrote:
>
> On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
> wrote:
> >
> > From: Nazar Kazakov
> >
> > Signed-off-by: Nazar Kazakov
>
> You might want to squash this onto the patch that first introduces th
On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
wrote:
>
> From: Nazar Kazakov
>
> Signed-off-by: Nazar Kazakov
You might want to squash this onto the patch that first introduces the property.
Reviewed-by: Philipp Tomsich
> ---
> target/riscv/cpu.c | 2 ++
> 1 file
On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
wrote:
>
> From: Nazar Kazakov
>
> Signed-off-by: Nazar Kazakov
> ---
> target/riscv/helper.h | 4
> target/riscv/insn32.decode | 1 +
> target/riscv/insn_trans/trans_rvzvkb.c.inc | 1 +
>
On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
wrote:
>
> From: William Salmon
>
> Co-authored-by: Kiran Ostrolenk
> Signed-off-by: Kiran Ostrolenk
> Signed-off-by: William Salmon
> ---
> include/qemu/bitops.h | 32 +
> target/riscv/helper.h
On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
wrote:
>
> From: Dickon Hood
>
> Add an initial implementation of the vrol.* and vror.* instructions,
> with mappings between the RISC-V instructions and their internal TCG
> accelerated implmentations.
>
> There are some missing ror helpers, so I've
On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
wrote:
>
> Signed-off-by: Lawrence Hunter
> ---
> target/riscv/helper.h | 1 +
> target/riscv/insn32.decode | 1 +
> target/riscv/insn_trans/trans_rvzvkb.c.inc | 1 +
> target/riscv/vcrypto_helper.c
On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
wrote:
>
Please split off the refactoring.
See below for more comments.
> Co-authored-by: Kiran Ostrolenk
> Co-authored-by: Nazar Kazakov
> Signed-off-by: Kiran Ostrolenk
> Signed-off-by: Nazar Kazakov
> Signed-off-by: Lawrence Hunter
> ---
>
On Thu, 2 Feb 2023 at 13:42, Lawrence Hunter
wrote:
>
Given that this is a non-trivial change, the commit message seems a bit brief?
> Co-authored-by: Nazar Kazakov
> Co-authored-by: Kiran Ostrolenk
> Co-authored-by: Max Chou
> Signed-off-by: Max Chou
> Signed-off-by: Kiran Ostrolenk
>
On Mon, 23 Jan 2023 at 02:29, Alistair Francis wrote:
>
> On Sat, Jan 21, 2023 at 12:36 PM Philipp Tomsich
> wrote:
> >
> > The Zicond standard extension implements the same instruction
> > semantics as XVentanaCondOps, although using different mnemonics and
On Mon, 23 Jan 2023 at 02:28, Alistair Francis wrote:
>
> On Sat, Jan 21, 2023 at 12:36 PM Philipp Tomsich
> wrote:
> >
> > This implements the Zicond (conditional integer operations) extension,
> > as of version 1.0-draft-20230120 as an experimental exten
nload/v1.0-draft-20230120/riscv-zicond_1.0-draft-20230120.pdf
for the (current version of the) Zicond specification and usage details.
Signed-off-by: Philipp Tomsich
---
Changes in v2:
- gates availability of the instructions through a REQUIRE_ZICOND
macro (these were previously always enable
as trans_xventanacondops.c.inc will not see
active maintenance from here forward.
Signed-off-by: Philipp Tomsich
---
Changes in v2:
- Calls into the gen_czero_{eqz,nez} helpers instead of calling
trans_czero_{eqz,nez} to bypass the require-check and ensure that
XVentanaCondOps can be enabled/disabled
as trans_xventanacondops.c.inc will not see
active maintenance from here forward.
Signed-off-by: Philipp Tomsich
---
MAINTAINERS| 2 +-
.../insn_trans/trans_xventanacondops.c.inc | 18 +++---
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git
nload/v1.0-draft-20230120/riscv-zicond_1.0-draft-20230120.pdf
for the (current version of the) Zicond specification and usage details.
Signed-off-by: Philipp Tomsich
---
MAINTAINERS | 7
target/riscv/cpu.c | 4 ++
ta
of
interpreting this as an immediate
This commit updates the instruction descriptions to use the
appropriate decoding/printing formats.
Signed-off-by: Philipp Tomsich
---
disas/riscv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/disas/riscv.c b/disas/riscv.c
index
On Mon 19. Dec 2022 at 04:19, Alex Bennée wrote:
> Philipp I assume I'm correct that the QEMU work should be shown as a
> corporate contribution?
Indeed.
Signed-off-by: Alex Bennée
> Cc: Philipp Tomsich
Reviewed-by: Philipp Tomsich
> ---
> contrib/gitdm/domain-map
On Thu, 8 Sept 2022 at 11:25, Alistair Francis wrote:
>
> On Fri, Aug 12, 2022 at 4:19 PM Philipp Tomsich
> wrote:
> >
> > Happy to lower it back into the decode file.
> > However, I initially pulled it up into the trans-function to more
> > closely match the ISA
2 Aug 2022 at 15:21, Peter Maydell wrote:
>
> On Fri, 12 Aug 2022 at 14:17, Philipp Tomsich
> wrote:
> >
> > Our decoding of fence-instructions is problematic in respect to the
> > RISC-V ISA specification:
> > - rs and rd are ignored, but need to be 0
>
On Fri, 12 Aug 2022 at 16:01, Andrew Jones wrote:
>
> > Update the decode pattern to reflect the specification.
>
> I got hung-up on this for a bit since there isn't any "must-be-0" fields,
Please refer to '“Zifencei” Instruction-Fetch Fence, Version 2.0' in
the specification.
The encoding
The RISC-V specification specifies imm12, rs1 and rd to be all-zeros,
so we can't ignore these bits when decoding into fence.i.
Update the decode pattern to reflect the specification.
Signed-off-by: Philipp Tomsich
---
target/riscv/insn32.decode | 2 +-
1 file changed, 1 insertion(+), 1
) to
determine whether a reserved instruction is specified.
While the specification allows UNSPECIFIED behaviour for reserved
instructions, we now always raise an illegal instruction exception.
Signed-off-by: Philipp Tomsich
---
target/riscv/insn32.decode | 2 +-
target/riscv/insn_trans
On Thu, 2 Jun 2022 at 17:07, Richard Henderson
wrote:
>
> On 6/2/22 06:40, Christoph Muellner wrote:
> > diff --git a/target/riscv/insn_trans/trans_rvzawrs.c.inc
> > b/target/riscv/insn_trans/trans_rvzawrs.c.inc
> > new file mode 100644
> > index 00..38b71d0085
> > --- /dev/null
> > +++
On Tue, 1 Mar 2022 at 02:28, Vineet Gupta wrote:
> Hi Alistair,
>
> On 2/3/22 16:59, Alistair Francis wrote:
> > On Fri, Feb 4, 2022 at 1:42 AM Philipp Tomsich
> wrote:
> >>
> >> While changing to the use of cfg_ptr, the conditions for
> REQUIRE_ZB[A
wrote:
>
> From: Philipp Tomsich
>
> The Zb[abcs] support code still uses the RISCV_CPU macros to access
> the configuration information (i.e., check whether an extension is
> available/enabled). Now that we provide this information directly
> from DisasContext, we can acc
to a single comment
> - Rebase on top of github-alistair23/riscv-to-apply.next plus the
> Priv v1.12 series from github-atishp04/priv_1_12_support_v3
>
> v2:
> - Fix overlapping instruction encoding with LQ instructions
> - Drop CSR related changes and rebase on Priv 1.12 pat
.
Fixes: 718143c126 ("target/riscv: add a MAINTAINERS entry for XVentanaCondOps")
Signed-off-by: Philipp Tomsich
---
We may want to squash this onto the affected commit, if it hasn't made
it beyond the next-tree, yet.
target/riscv/insn_trans/trans_rvb.c.inc | 8
1 file
Alistair,
there's a fix for a regression (inverted condition) caused by the changes
to the REQUIRE_ZB[ABCS] heading your way.
Thanks,
Philipp.
On Wed, 2 Feb 2022 at 07:36, Alistair Francis wrote:
> On Wed, Feb 2, 2022 at 2:03 PM Philipp Tomsich
> wrote:
> >
> >
> &g
The Zb[abcs] support code still uses the RISCV_CPU macros to access
the configuration information (i.e., check whether an extension is
available/enabled). Now that we provide this information directly
from DisasContext, we can access this directly via the cfg_ptr field.
Signed-off-by: Philipp
to copying the fields into DisasContext).
While not a performance problem today, we can always (shallow) copy
the entire structure into the DisasContext (instead of putting a
pointer to it) if this is ever deemed necessary.
Signed-off-by: Philipp Tomsich
Reviewed-by: Alistair Francis
Suggested
ble into XVentanaCondOps.decode
- Wire up XVentanaCondOps in the decoder-table
Philipp Tomsich (7):
target/riscv: refactor (anonymous struct) RISCVCPU.cfg into 'struct
RISCVCPUConfig'
target/riscv: riscv_tr_init_disas_context: copy pointer-to-cfg into
cfg_ptr
target/riscv: access configurat
a guard-function (has_XVentanaCondOps_p)
and the decoder function to the table of decoders, enabling the
support for the XVentanaCondOps extension.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
Changes in v6:
- add the 'vt' prefix to gen_condmask
Signed-off-by: Philipp Tomsich
Reviewed-by: Alistair Francis
Suggested-by: Richard Henderson
Reviewed-by: Richard Henderson
---
(no changes since v4)
Changes in v4:
- use a typedef into 'RISCVCPUConfig' (instead of the explicit
'struct RISCVCPUConfig') to comply with the coding standard
The XVentanaCondOps extension is supported by VRULL on behalf of the
Ventana Micro. Add myself as a point-of-contact.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
(no changes since v3)
Changes in v3:
- add a MAINTAINERS entry
The implementation in trans_{rvi,rvv,rvzfh}.c.inc accesses the shallow
copies (in DisasContext) of some of the elements available in the
RISCVCPUConfig structure. This commit redirects accesses to use the
cfg_ptr copied into DisasContext and removes the shallow copies.
Signed-off-by: Philipp
and the table, allowing for
the easy addition of additional decoders in the future.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
Reviewed-by: Alistair Francis
---
(no changes since v4)
Changes in v4:
- add braces to comply with coding standard (as suggested by Richard)
- merge
On Tue, 1 Feb 2022 at 04:22, Alistair Francis wrote:
>
> On Mon, Jan 31, 2022 at 9:23 PM Philipp Tomsich
> wrote:
> >
> > This adds the decoder and translation for the XVentanaCondOps custom
> > extension (vendor-defined by Ventana Micro Systems), which is
&
and the table, allowing for
the easy addition of additional decoders in the future.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v4)
Changes in v4:
- add braces to comply with coding standard (as suggested by Richard)
- merge the two if-statements to reduce
The XVentanaCondOps extension is supported by VRULL on behalf of the
Ventana Micro. Add myself as a point-of-contact.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- add a MAINTAINERS entry for XVentanaCondOps
MAINTAINERS | 7
a guard-function (has_XVentanaCondOps_p)
and the decoder function to the table of decoders, enabling the
support for the XVentanaCondOps extension.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- rename to trans_xventanacondops.c.inc (i.e
The implementation in trans_{rvi,rvv,rvzfh}.c.inc accesses the shallow
copies (in DisasContext) of some of the elements available in the
RISCVCPUConfig structure. This commit redirects accesses to use the
cfg_ptr copied into DisasContext and removes the shallow copies.
Signed-off-by: Philipp
n't make CPURISCVState* visible to these predicate functions
- add a MAINTAINERS entry for XVentanaCondOps
Changes in v2:
- (new patch) iterate over a table of guarded decoder functions
- Split off decode table into XVentanaCondOps.decode
- Wire up XVentanaCondOps in the decoder-table
Philipp Tomsich
The Zb[abcs] support code still uses the RISCV_CPU macros to access
the configuration information (i.e., check whether an extension is
available/enabled). Now that we provide this information directly
from DisasContext, we can access this directly via the cfg_ptr field.
Signed-off-by: Philipp
Signed-off-by: Philipp Tomsich
Suggested-by: Richard Henderson
Reviewed-by: Richard Henderson
---
(no changes since v4)
Changes in v4:
- use a typedef into 'RISCVCPUConfig' (instead of the explicit
'struct RISCVCPUConfig') to comply with the coding standard
(as suggested in Richard's
to copying the fields into DisasContext).
While not a performance problem today, we can always (shallow) copy
the entire structure into the DisasContext (instead of putting a
pointer to it) if this is ever deemed necessary.
Signed-off-by: Philipp Tomsich
Suggested-by: Richard Henderson
Reviewed
On Mon, 31 Jan 2022 at 09:25, Richard Henderson
wrote:
>
> On 1/31/22 10:57, Philipp Tomsich wrote:
> >
> > In adding our first X-extension (i.e., vendor-defined) on RISC-V with
> > XVentanaCondOps, we need to add a few instructure improvements to make
> > it easier
The XVentanaCondOps extension is supported by VRULL on behalf of the
Ventana Micro. Add myself as a point-of-contact.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- add a MAINTAINERS entry for XVentanaCondOps
MAINTAINERS | 7
The implementation in trans_{rvi,rvv,rvzfh}.c.inc accesses the shallow
copies (in DisasContext) of some of the elements available in the
RISCVCPUConfig structure. This commit redirects accesses to use the
cfg_ptr copied into DisasContext and removes the shallow copies.
Signed-off-by: Philipp
Signed-off-by: Philipp Tomsich
Suggested-by: Richard Henderson
---
Changes in v4:
- use a typedef into 'RISCVCPUConfig' (instead of the explicit
'struct RISCVCPUConfig') to comply with the coding standard
(as suggested in Richard's review of v3)
Changes in v3:
- (new patch) refactor
The Zb[abcs] support code still uses the RISCV_CPU macros to access
the configuration information (i.e., check whether an extension is
available/enabled). Now that we provide this information directly
from DisasContext, we can access this directly via the cfg_ptr field.
Signed-off-by: Philipp
a guard-function (has_XVentanaCondOps_p)
and the decoder function to the table of decoders, enabling the
support for the XVentanaCondOps extension.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- rename to trans_xventanacondops.c.inc (i.e
to copying the fields into DisasContext).
While not a performance problem today, we can always (shallow) copy
the entire structure into the DisasContext (instead of putting a
pointer to it) if this is ever deemed necessary.
Signed-off-by: Philipp Tomsich
Suggested-by: Richard Henderson
and the table, allowing for
the easy addition of additional decoders in the future.
Signed-off-by: Philipp Tomsich
---
Changes in v4:
- add braces to comply with coding standard (as suggested by Richard)
- merge the two if-statements to reduce clutter after (now that the
braces have been added
der functions
- Split off decode table into XVentanaCondOps.decode
- Wire up XVentanaCondOps in the decoder-table
Philipp Tomsich (7):
target/riscv: refactor (anonymous struct) RISCVCPU.cfg into 'struct
RISCVCPUConfig'
target/riscv: riscv_tr_init_disas_context: copy pointer-to-cfg into
cfg_
and the table, allowing for
the easy addition of additional decoders in the future.
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- expose only the DisasContext* to predicate functions
- mark the table of decoder functions as static
- drop the inline from always_true_p, until the need arises (i.e
to copying the fields into DisasContext).
While not a performance problem today, we can always (shallow) copy
the entire structure into the DisasContext (instead of putting a
pointer to it) if this is ever deemed necessary.
Signed-off-by: Philipp Tomsich
Suggested-by: Richard Henderson
---
Changes
ble into XVentanaCondOps.decode
- Wire up XVentanaCondOps in the decoder-table
Philipp Tomsich (7):
target/riscv: refactor (anonymous struct) RISCVCPU.cfg into 'struct
RISCVCPUConfig'
target/riscv: riscv_tr_init_disas_context: copy pointer-to-cfg into
cfg_ptr
target/riscv: access configuration thro
a guard-function (has_XVentanaCondOps_p)
and the decoder function to the table of decoders, enabling the
support for the XVentanaCondOps extension.
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- rename to trans_xventanacondops.c.inc (i.e. with the '.c')
- (in MATERIALISE_EXT_PREDICATE) don't
The implementation in trans_{rvi,rvv,rvzfh}.c.inc accesses the shallow
copies (in DisasContext) of some of the elements available in the
RISCVCPUConfig structure. This commit redirects accesses to use the
cfg_ptr copied into DisasContext and removes the shallow copies.
Signed-off-by: Philipp
The Zb[abcs] support code still uses the RISCV_CPU macros to access
the configuration information (i.e., check whether an extension is
available/enabled). Now that we provide this information directly
from DisasContext, we can access this directly via the cfg_ptr field.
Signed-off-by: Philipp
The XVentanaCondOps extension is supported by VRULL on behalf of the
Ventana Micro. Add myself as a point-of-contact.
Signed-off-by: Philipp Tomsich
---
Changes in v3:
- add a MAINTAINERS entry for XVentanaCondOps
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git
Signed-off-by: Philipp Tomsich
Suggested-by: Richard Henderson
---
Changes in v3:
- (new patch) refactor 'struct RISCVCPUConfig'
target/riscv/cpu.h | 76 --
1 file changed, 39 insertions(+), 37 deletions(-)
diff --git a/target/riscv/cpu.h b/target
On Wed, 19 Jan 2022 at 12:30, Philippe Mathieu-Daudé wrote:
>
> On 13/1/22 21:20, Philipp Tomsich wrote:
> > To split up the decoder into multiple functions (both to support
> > vendor-specific opcodes in separate files and to simplify maintenance
> > of orthogonal e
On Wed, 19 Jan 2022 at 12:17, Philippe Mathieu-Daudé wrote:
>
> On 13/1/22 21:20, Philipp Tomsich wrote:
> > This adds the decoder and translation for the XVentanaCondOps custom
> > extension (vendor-defined by Ventana Micro Systems), which is
> > documented at
Thanks for taking the time to write this up!
On Wed, 19 Jan 2022 at 02:30, Alistair Francis wrote:
>
> On Wed, Jan 19, 2022 at 11:19 AM Alistair Francis
> wrote:
> >
> > On Wed, Jan 19, 2022 at 9:22 AM Philipp Tomsich
> > wrote:
> > >
> > > Alist
The cbo.* mnemonics share their opcode space with lq for those cases where
rd == 0 ("brownfield" encodings).
"Major opcode" refers to inst[6:0] according to chapter 26.
In overlapping multi-group syntax, this would look like:
> {
>
> # *** RV32 Zicbom Standard Extension ***
>
> cbo_clean
, 18 Jan 2022 at 23:53, Alistair Francis wrote:
>
> On Fri, Jan 14, 2022 at 6:22 AM Philipp Tomsich
> wrote:
> >
> > This adds the decoder and translation for the XVentanaCondOps custom
> > extension (vendor-defined by Ventana Micro Systems), which is
> >
and the table, allowing for
the easy addition of additional decoders in the future.
Signed-off-by: Philipp Tomsich
---
Changes in v2:
- (new patch) iterate over a table of guarded decoder functions
target/riscv/translate.c | 38 --
1 file changed, 32 insertions
a guard-function (has_XVentanaCondOps_p)
and the decoder function to the table of decoders, enabling the
support for the XVentanaCondOps extension.
Signed-off-by: Philipp Tomsich
---
Changes in v2:
- Split off decode table into XVentanaCondOps.decode
- Wire up XVentanaCondOps in the decoder-table
On Thu, 13 Jan 2022 at 06:07, Alistair Francis wrote:
>
> On Thu, Jan 13, 2022 at 1:42 AM Philipp Tomsich
> wrote:
> >
> > Alistair,
> >
> > Do you (and the other RISC-V custodians of target/riscv) have any opinion
> > on this?
> > We can go either w
Alistair,
Do you (and the other RISC-V custodians of target/riscv) have any opinion
on this?
We can go either way — and it boils down to a style and process question.
Thanks,
Philipp.
On Mon, 10 Jan 2022 at 12:30, Philippe Mathieu-Daudé
wrote:
> On 1/10/22 12:11, Philipp Tomsich wr
On Mon, 10 Jan 2022 at 11:03, Philippe Mathieu-Daudé
wrote:
> On 1/10/22 10:52, Philipp Tomsich wrote:
> > For RISC-V the opcode decode will change between different vendor
> > implementations of RISC-V (emulated by the same qemu binary).
> > Any two vendors may reuse the s
is a natural and obvious next step,
though.
Philipp.
On Mon, 10 Jan 2022 at 10:52, Philipp Tomsich
wrote:
> For RISC-V the opcode decode will change between different vendor
> implementations of RISC-V (emulated by the same qemu binary).
> Any two vendors may reuse the same opcode spac
having a AMP in one emulation setup (e.g. application
cores having one extension and power-mangement cores having a
different one — or even a conflicting one).
Cheers,
Philipp.
On Mon, 10 Jan 2022 at 10:43, Philippe Mathieu-Daudé wrote:
>
> Hi Philipp,
>
> On 1/9/22 21:56, Philipp T
.
On Mon, 10 Jan 2022 at 10:39, Philippe Mathieu-Daudé
wrote:
> Cc'ing Richard & Eric for dubious compiler warning.
>
> On 1/9/22 21:57, Philipp Tomsich wrote:
> > Compiling with gcc version 11.2.0 (Ubuntu 11.2.0-13ubuntu1) results in
> > a (spurious) warning:
> >
>
cc1: all warnings being treated as errors
This change helps that version of GCC to understand what is going on
and suppresses this warning.
Signed-off-by: Philipp Tomsich
---
net/dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dump.c b/net/dump.c
index a07ba62
between vendors, these
are implemented as overlapping patterns and use the newly introduced
predicate-function infrastructure to further qualify the decode.
Signed-off-by: Philipp Tomsich
---
target/riscv/cpu.c| 3 ++
target/riscv/cpu.h| 3
of the emulation target.
At this time, we only support predicates for multi-patterns.
Signed-off-by: Philipp Tomsich
---
docs/devel/decodetree.rst | 7 ++-
scripts/decodetree.py | 24 +---
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/docs/devel
manip Zb[abcs] instructions")
Signed-off-by: Philipp Tomsich
---
target/riscv/cpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 6ef3314bce..e322e729d2 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -640,
ted as a mask-and-shift) to extract the MSB of
each byte into its LSB.
5. Multiply with 0xff to fan out the LSB to all bits of each byte.
Fixes: d7a4fcb034 ("target/riscv: Add orc.b instruction for Zbb, removing
gorc/gorci")
Signed-off-by: Philipp Tomsich
Reported-by: Vincent Palatin
On Wed, 13 Oct 2021 at 18:51, Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 10/13/21 9:20 AM, Vineet Gupta wrote:
> > off topic but relates, for Zb (and similar things in the future) whats
> the strategy for
> > change management/discovery. I understand you can hardcode things for
On Wed, 13 Oct 2021 at 15:44, Vincent Palatin wrote:
>
> On Wed, Oct 13, 2021 at 3:13 PM Philipp Tomsich
> wrote:
> >
> > I had a much simpler version initially (using 3 x mask/shift/or, for
> > 12 instructions after setup of constants), but took up the sugge
.
On Wed, 13 Oct 2021 at 11:36, Vincent Palatin wrote:
>
> On Thu, Oct 7, 2021 at 8:58 AM Alistair Francis
> wrote:
> >
> > From: Philipp Tomsich
> >
> > The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a
> > orc.b instruction (equivalent to
We need to use the newly introduced dup_const_tl in orc.b to legalise
the truncation (to target_long) of the constant generated with dup_const.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v1)
target/riscv/insn_trans/trans_rvb.c.inc | 2 +-
1 file
a similar implementation using 32bit constants.
Signed-off-by: Philipp Tomsich
---
Changes in v2:
- Changed dup_const_tl to enforce the sanity check with
qemu_build_not_reached as requested in the review.
include/tcg/tcg.h | 12
1 file changed, 12 insertions(+)
diff --git
Give the plugins access to the qemu_plugin_insn_symbol helper.
Note that this symbols is today already used by cache.c, which can not
be loaded without it.
Signed-off-by: Philipp Tomsich
---
plugins/qemu-plugins.symbols | 1 +
1 file changed, 1 insertion(+)
diff --git a/plugins/qemu
Richard & Alistair,
On Tue, 28 Sept 2021 at 20:45, Philipp Tomsich wrote:
>
> On Tue, 28 Sept 2021 at 20:45, Richard Henderson
> wrote:
> >
> > On 9/28/21 11:45 AM, Philipp Tomsich wrote:
> > > The dup_const macro is returning an unsigned long long, wh
by casting it to target_long.
Signed-off-by: Philipp Tomsich
---
include/tcg/tcg.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/tcg/tcg.h b/include/tcg/tcg.h
index 44ccd86f3e..8f8a209600 100644
--- a/include/tcg/tcg.h
+++ b/include/tcg/tcg.h
@@ -1272,6 +1272,11 @@ uint64_t
1 - 100 of 274 matches
Mail list logo