[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~
- [Qemu-devel] Proposal for amending TCG interface naming scheme, Aleksandar Markovic, 2019/08/20
- Re: [Qemu-devel] Proposal for amending TCG interface naming scheme, Peter Maydell, 2019/08/20
- Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme, Aleksandar Markovic, 2019/08/20
- Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme, BALATON Zoltan, 2019/08/20
- Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme, Aleksandar Markovic, 2019/08/20
- Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme, David Hildenbrand, 2019/08/20
- Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme, Peter Maydell, 2019/08/20
- Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme, Aleksandar Markovic, 2019/08/20
- Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme, Laurent Vivier, 2019/08/20
- Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme, Aleksandar Markovic, 2019/08/20
- Re: [Qemu-devel] [EXTERNAL]Re: Proposal for amending TCG interface naming scheme, Aleksandar Markovic, 2019/08/20