[Top][All Lists]

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]