Hi Frédéric,
On 15/3/26 19:55, Frédéric Pétrot wrote:
Hi Phil,
my understanding is that rv128 makes no sense with rv32, and
the user is not expected to run qemu-system-riscv32 with
the -cpu=x-rv128 (it triggers an "unable to find CPU model
'x-rv128'" error).
The rv128 code just relies on XLEN being 128, and assumes
(implicitely I admit) running on a 64-bit host machine, so
with tl = 64.
The code is absolutely erroneous when tl = 32, agreed.
The thing is that, as we want to get rid of the
TARGET_RISCV64/TARGET_RISCV32 defines, the rv128 specific
code still must compile whatever tl, so that qemu can be built.
However, it should never be executed if tl = 32.
Typically, the patches I sent earlier this year to deal
with lq/sq endianness fit into that 'compile only' category
for rv32.
I'd really like to include your patch which fixes the endianness
issue I reported, but unfortunately as reported it doesn't even
build for rv32 builds:
https://lore.kernel.org/qemu-devel/[email protected]/
Which is why I'm trying to restrict RV128 on rv32 binary so
we can apply your other patch.
Anyway, Daniel suggestions to use 'get_xl(ctx) == MXL_RV32'
instead of this ugly TARGET_RISCV32 #ifdef'ry is certainly
the way to go (which is why I posted this as RFC).
Thanks,
Frédéric
On 3/15/26 17:59, Philippe Mathieu-Daudé wrote:
One half of 128-bit registers code is not reachable for CPUs
running in 32-bit mode, while the other half is completely
broken (handled as a pair of 32-bit registers).
Better restrict this code on 32-bit builds until RV128 is
properly implemented.
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
---
More than 1y having issue with the 128-bit code path and
the single binary effort. Fortunately while I dunno how to
test 128-bit I could with 32/64 bits.
---
target/riscv/cpu.h | 2 ++
target/riscv/machine.c | 4 +++
target/riscv/monitor.c | 4 +++
target/riscv/translate.c | 31 +++++++++++++++++++--
target/riscv/insn_trans/trans_rvzacas.c.inc | 2 ++
5 files changed, 41 insertions(+), 2 deletions(-)
