[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 4/5] [RISCV_PM] Support pointer masking for RISC-V for i/c
From: |
Richard Henderson |
Subject: |
Re: [PATCH v2 4/5] [RISCV_PM] Support pointer masking for RISC-V for i/c/f/d/a types of instructions |
Date: |
Thu, 15 Oct 2020 10:00:40 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 10/15/20 8:21 AM, Alexey Baturo wrote:
> Signed-off-by: Alexey Baturo <space.monkey.delivers@gmail.com>
> ---
> target/riscv/insn_trans/trans_rva.c.inc | 3 +++
> target/riscv/insn_trans/trans_rvd.c.inc | 2 ++
> target/riscv/insn_trans/trans_rvf.c.inc | 2 ++
> target/riscv/insn_trans/trans_rvi.c.inc | 2 ++
> target/riscv/translate.c | 14 ++++++++++++++
> 5 files changed, 23 insertions(+)
Looks ok.
It does occur to me to wonder how this is intended to work with unaligned
addresses, or large memory operations such as with RVV.
Without changes in the generic tcg code, an unaligned memory op that crosses
the mask will not wrap the second half. E.g.
upmbase = 0
upmmask = 0xffff
address = 0xfffe
size = 8
will read [0x10005 : 0xfffe] and not
[0x0005 : 0x0000] | [0xffff : 0xfffe] as a true wrapping would lead you do
believe.
r~
[PATCH v2 3/5] [RISCV_PM] Print new PM CSRs in QEMU logs, Alexey Baturo, 2020/10/15
[PATCH v2 4/5] [RISCV_PM] Support pointer masking for RISC-V for i/c/f/d/a types of instructions, Alexey Baturo, 2020/10/15
- Re: [PATCH v2 4/5] [RISCV_PM] Support pointer masking for RISC-V for i/c/f/d/a types of instructions,
Richard Henderson <=
[PATCH v2 5/5] [RISCV_PM] Implement address masking functions required for RISC-V Pointer Masking extension, Alexey Baturo, 2020/10/15