qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface namin


From: Richard Henderson
Subject: Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme
Date: Tue, 20 Aug 2019 08:37:18 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 8/20/19 6:49 AM, Aleksandar Markovic wrote:
>> From: Peter Maydell <address@hidden>
>> On Tue, 20 Aug 2019 at 13:50, Aleksandar Markovic
>> <address@hidden> wrote:
>>> The idea is to provide significant "lexicographic" distance between those > 
>>> groups of functions, rather than having the similar name (wiht common root 
>>> > "ext) for all of them.
>>
>> The current naming of the extract/sextract TCG ops is intended to keep
>> them in line with the extract32/sextract32/extract64/sextract64 utility
>> functions in bitops.h. I think those ones are reasonably named. The
>> other ops are a bit more ad-hoc in naming, admittedly...
>>
> 
> How about
> 
> tcg_gen_extract2_i32
> tcg_gen_extract2_i64
> tcg_gen_extract2_tl
> tcg_gen_extrl_i64_i32
> tcg_gen_extrh_i64_i32
> tcg_gen_ext_i32_i64
> tcg_gen_extu_i32_i64
> 
> to
> 
> tcg_gen_gather_i32
> tcg_gen_gather_i64
> tcg_gen_gather_tl

I'm not sure how "gather" applies.  To me this sounds like a vector
scatter/gather operation, where N different addresses are used to load the N
elements of the vector.

When extract2 was named, I was only thinking "extract" because of how the
AArch64 instruction that implements this operation is named (EXTR), and "extr"
itself was already taken.  We did ask for naming suggestions at the time, but
no better ideas were floated...

Would it be clearer to use the x86 instruction name: SHRD (SHift Right 
Doubleword)?

> tcg_gen_pick_l_i64_i32
> tcg_gen_pick_h_i64_i32

Hmm, "pick" doesn't mean anything to me.  Which makes it better than "gather",
but only just.

We do have a couple of related operations: tcg_gen_trunc_i64_tl and
tcg_gen_trunc_tl_i32.  It's easy to see tcg_gen_extrl_i64_i32 as "truncate",
because that's what it does.  But it's harder to see tcg_gen_extrh_i64_i32 as
"truncate high".  Is tcg_gen_shr32_trunc_i64_i32 too unwieldy?

Or perhaps we could leave these alone.  Changing the others gives us the
desired (or at least increased) lexicographic distance.

> tcg_gen_extend_s_i32_i64
> tcg_gen_extend_0_i32_i64

These should not drift too far from the other extension names,

    tcg_gen_ext{8,16}{u,s}_i32
    tcg_gen_ext{8,16,32}{u,s}_i64

What if we use the AArch64 mnemonics: zxt (zero-extend) and sxt (sign-extend)?
 This would give us

    tcg_gen_zxt8_i32
    tcg_gen_sxt8_i32
    (etc)
    tcg_gen_zxt_i32_i64
    tcg_gen_sxt_i32_i64


r~



reply via email to

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