[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/8] RISC V partial support for 128-bit architecture
From: |
Richard Henderson |
Subject: |
Re: [PATCH 0/8] RISC V partial support for 128-bit architecture |
Date: |
Mon, 30 Aug 2021 22:09:56 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 8/30/21 10:16 AM, Frédéric Pétrot wrote:
This series of patches aims at adding partial 128-bit support to the riscv
target, following the (unratified) RV128I specification, Chapter 7 of
riscv-spec document dated 20191214.
It provides support for all user integer (I) instructions and for an M
extension which follows the definition of the 32 and 64-bit specifications.
So... I think that this patch set ought to coordinate with the patches to support UXL.
Both this and UXL require adjustments to almost every operation, both widening and
narrowing the effects of the operation.
I think that we're going to need to adjust the primary helpers.
E.g. the current
static bool gen_arith(DisasContext *ctx, arg_r *a,
void (*func)(TCGv, TCGv, TCGv))
which supports only one implementation, is going to need to expand to
static bool gen_arith(DisasContext *ctx, arg_r *a,
void (*fn32)(TCGv, TCGv, TCGv),
void (*fn64)(TCGv, TCGv, TCGv),
void (*fn128)(TCGv, TCGv, TCGv
TCGv, TCGv, TCGv))
with the is_32bit, is_128bit check done inside the helper. Similarly with gen_unary, and
possibly gen_shift.
Sometimes the fn32 and fn64 operand will be the same, e.g. add, where the 32-bit to 64-bit
sign-extension is done during the writeback. But sometimes, e.g. mulhu, we will need
separate implementations for each.
We should rename the current helper, with one operand, gen_logical, indicating it is clear
that the operation is bitwise and one tcg function covers all widths.
r~