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: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme
Date: Wed, 21 Aug 2019 18:15:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 8/20/19 6:46 PM, David Hildenbrand wrote:
> On 20.08.19 17:37, Richard Henderson wrote:
>> 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)?
>>
> 
> I still think your proposal back then made sense - extract2. Extract a
> 64bit value from a 128bit value.

It is also valid to extract 32bit from 64bit.



reply via email to

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