[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
Re: [PATCH v2 4/5] [RISCV_PM] Support pointer masking for RISC-V for i/c/f/d/a types of instructions
Thu, 15 Oct 2020 20:30:51 +0300
That's a great question, but unfortunately, I don't have an answer for it now.
Let me ask it on J WG meeting that would happen next Monday along with extension naming and CSR numbers(hopefuly).
On 10/15/20 8:21 AM, Alexey Baturo wrote:
> Signed-off-by: Alexey Baturo <firstname.lastname@example.org>
> 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(+)
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.
[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
[PATCH v2 5/5] [RISCV_PM] Implement address masking functions required for RISC-V Pointer Masking extension, Alexey Baturo, 2020/10/15