[Qemu-devel] Proposal for amending TCG interface naming scheme

[Qemu-devel] Proposal for amending TCG interface naming scheme

[Aleksandar Markovic]

Hello, all.

I noticed certain barrier and difficulties wrt learning TCG interface by newcomers and to some extent oldcomers too. At least some of them can be attributed to not best choice of names for functions TCG exposes, especially in the area of extract and sextract. I have a quick idea on how to improve it using the following renaming scheme:

tcg_gen_extract_i32
tcg_gen_extract_i64
tcg_gen_extract_tl
tcg_gen_sextract_i32
tcg_gen_sextract_i64
tcg_gen_sextract_tl
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

could become:

tcg_gen_select_i32
tcg_gen_select_i64
tcg_gen_select_tl
tcg_gen_select_s_i32
tcg_gen_select_s_i64
tcg_gen_select_s_tl
tcg_gen_gather_i32
tcg_gen_gather_i64
tcg_gen_gather_tl
tcg_gen_extract_l_i64_i32
tcg_gen_extract_h_i64_i32
tcg_gen_extend_s_i32_i64
tcg_gen_extend_0_i32_i64

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.

What do you think?

Sincerely,
Aleksandar

Re: [Qemu-devel] Proposal for amending TCG interface naming scheme

[Peter Maydell]

On Tue, 20 Aug 2019 at 13:50, Aleksandar Markovic
<amarkovic@wavecomp.com> wrote:
>
> Hello, all.
>
> I noticed certain barrier and difficulties wrt learning TCG interface by newcomers and to some extent oldcomers too. At least some of them can be attributed to not best choice of names for functions TCG exposes, especially in the area of extract and sextract. I have a quick idea on how to improve it using the following renaming scheme:
>
> tcg_gen_extract_i32
> tcg_gen_extract_i64
> tcg_gen_extract_tl
> tcg_gen_sextract_i32
> tcg_gen_sextract_i64
> tcg_gen_sextract_tl
> 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
>
> could become:
>
> tcg_gen_select_i32
> tcg_gen_select_i64
> tcg_gen_select_tl
> tcg_gen_select_s_i32
> tcg_gen_select_s_i64
> tcg_gen_select_s_tl
> tcg_gen_gather_i32
> tcg_gen_gather_i64
> tcg_gen_gather_tl
> tcg_gen_extract_l_i64_i32
> tcg_gen_extract_h_i64_i32
> tcg_gen_extend_s_i32_i64
> tcg_gen_extend_0_i32_i64
>
> 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...

thanks
-- PMM

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

[Aleksandar Markovic]

> From: Peter Maydell <peter.maydell@linaro.org>
> On Tue, 20 Aug 2019 at 13:50, Aleksandar Markovic
> <amarkovic@wavecomp.com> wrote:
> >
> > Hello, all.
> >
> > I noticed certain barrier and difficulties wrt learning TCG interface by
> > newcomers and to some extent oldcomers too. At least some of them can be
> > attributed to not best choice of names for functions TCG exposes, especially
> > in the area of extract and sextract. I have a quick idea on how to improve it
> > using the following renaming scheme:
> >
> > tcg_gen_extract_i32
> > tcg_gen_extract_i64
> > tcg_gen_extract_tl
> > tcg_gen_sextract_i32
> > tcg_gen_sextract_i64
> > tcg_gen_sextract_tl
> > 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
> >
> > could become:
> >
> > tcg_gen_select_i32
> > tcg_gen_select_i64
> > tcg_gen_select_tl
> > tcg_gen_select_s_i32
> > tcg_gen_select_s_i64
> > tcg_gen_select_s_tl
> > tcg_gen_gather_i32
> > tcg_gen_gather_i64
> > tcg_gen_gather_tl
> > tcg_gen_extract_l_i64_i32
> > tcg_gen_extract_h_i64_i32
> > tcg_gen_extend_s_i32_i64
> > tcg_gen_extend_0_i32_i64
> >
> > 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
tcg_gen_pick_l_i64_i32
tcg_gen_pick_h_i64_i32
tcg_gen_extend_s_i32_i64
tcg_gen_extend_0_i32_i64

?

Any idea, please come up...?

Yours,
Aleksandar


> thanks
> -- PMM

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

[Richard Henderson]

On 8/20/19 6:49 AM, Aleksandar Markovic wrote:
>> From: Peter Maydell <peter.maydell@linaro.org>
>> On Tue, 20 Aug 2019 at 13:50, Aleksandar Markovic
>> <amarkovic@wavecomp.com> 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~

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

[Aleksandar Markovic]

On Tue, Aug 20, 2019 at 5:37 PM Richard Henderson <
richard.henderson@linaro.org> wrote:

> On 8/20/19 6:49 AM, Aleksandar Markovic wrote:
> >> From: Peter Maydell <peter.maydell@linaro.org>
> >> On Tue, 20 Aug 2019 at 13:50, Aleksandar Markovic
> >> <amarkovic@wavecomp.com> 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.


gather = come together; assemble or accumulate


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


and "extl" does?


> 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
>
>
Perhaps the whole "extend" front-end segment should be tweaked to be
consistent.

In general, Z/S scheme in these cases looks better than U/S scheme to me.
The prevalent terms are "zero-extend" and "sign-extend", and involving
Unsigned/Signed just widens the semantic gap.

I used "0" and "s" to make the visual distinction easier (it is easier to
spot).

I was hoping we would remove "sextract" (well, it is funny a little bit
definitely, but if there are zillion occurrences, and used everyday, it
just stops being funny, and is somewhat distracting...), however it looks
we will get "sextend", and "sextend2", and "sex_h" and "sex_l"...

Aleksandar


>
> r~
>
>

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

[BALATON Zoltan]

Hello,

Sorry to comment on this without really knowing what is it about but maybe 
my view is not completely useless if this is to be understood by people 
who don't know anything about it. If it is not useful just ignore.

On Tue, 20 Aug 2019, Richard Henderson wrote:
> Would it be clearer to use the x86 instruction name: SHRD (SHift Right Doubleword)?

Not unless you name it shr32 or something like that. SHRD does not look 
meaningful without knowing the instruction and elsewhere you use bit 
numbers instead of b, w, d letters. (I don't know if shr32 is actually a 
good name for this op, just commenting on the naming itself.)

> 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

Again this might look familiar to those knowing AArch64 but not to someone 
who does not know that. Maybe zext sext is a bit more decypherable.

In general I think it would be best to name these to describe what they do 
not necessarily following any other ISA naming because that's only useful 
for those who know those particular instructions so maybe it should be 
consistent within TCG and does not have to match what CPUs call it.

Regards,
BALATON Zoltan

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

[Aleksandar Markovic]

> From: BALATON Zoltan <balaton@eik.bme.hu>
> 
> Sorry to comment on this without really knowing what is it about but maybe
> my view is not completely useless if this is to be understood by people
> who don't know anything about it. If it is not useful just ignore.

No, Zoltan, to the contrary, you hit the nail - the good interface scheme
should look natural even for people not acquainted with the gory details
of the area.

I have a couple of students, and these names just don't stick to their
minds, they just want to run away from using them. There seems to be
an "entry barrier" that is self-imposed by us.

All those functions seem to me underused in QEMU code. Partially
because some of them are relatively new, but for sure partially because
of some kind of disorganization of the naming.

Aleksandar

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

[David Hildenbrand]

On 20.08.19 18:38, Aleksandar Markovic wrote:
>> From: BALATON Zoltan <balaton@eik.bme.hu>
>>
>> Sorry to comment on this without really knowing what is it about but maybe
>> my view is not completely useless if this is to be understood by people
>> who don't know anything about it. If it is not useful just ignore.
> 
> No, Zoltan, to the contrary, you hit the nail - the good interface scheme
> should look natural even for people not acquainted with the gory details
> of the area.
> 

I just got familiar with the terminology and everything I read so far
confuses me even more (gather/pick/extend/extl/shrd). No, I don't like that.

> I have a couple of students, and these names just don't stick to their
> minds, they just want to run away from using them. There seems to be
> an "entry barrier" that is self-imposed by us.
> 
> All those functions seem to me underused in QEMU code. Partially
> because some of them are relatively new, but for sure partially because
> of some kind of disorganization of the naming.
> 
> Aleksandar
> 

-- 

Thanks,

David / dhildenb

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

[David Hildenbrand]

On 20.08.19 17:37, Richard Henderson wrote:
> On 8/20/19 6:49 AM, Aleksandar Markovic wrote:
>>> From: Peter Maydell <peter.maydell@linaro.org>
>>> On Tue, 20 Aug 2019 at 13:50, Aleksandar Markovic
>>> <amarkovic@wavecomp.com> 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.

-- 

Thanks,

David / dhildenb

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

[Peter Maydell]

On Tue, 20 Aug 2019 at 17:44, David Hildenbrand <david@redhat.com> wrote:
>
> On 20.08.19 18:38, Aleksandar Markovic wrote:
> >> From: BALATON Zoltan <balaton@eik.bme.hu>
> >>
> >> Sorry to comment on this without really knowing what is it about but maybe
> >> my view is not completely useless if this is to be understood by people
> >> who don't know anything about it. If it is not useful just ignore.
> >
> > No, Zoltan, to the contrary, you hit the nail - the good interface scheme
> > should look natural even for people not acquainted with the gory details
> > of the area.
> >
>
> I just got familiar with the terminology and everything I read so far
> confuses me even more (gather/pick/extend/extl/shrd). No, I don't like that.

FWIW the way I tend to approach these is to say "I want to do
$WHATEVER, surely we must have a tcg op for that, it's probably
got 'ext' in it, search through tcg/README to find something
that seems like it matches what I want to do"...

thanks
-- PMM

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

[Richard Henderson]

On 8/20/19 9:15 AM, Aleksandar Markovic wrote:
>     > tcg_gen_gather_i32
>     > tcg_gen_gather_i64
>     > tcg_gen_gather_tl
> 
>     I'm not sure how "gather" applies.
> 
> 
> gather = come together; assemble or accumulate

Sure, but...

>     To me this sounds like a vector
>     scatter/gather operation, where N different addresses are used to load the N
>     elements of the vector.

... it also has a completely different well-known meaning.


>     Hmm, "pick" doesn't mean anything to me. 
> 
> 
> and "extl" does?

Sure: "EXTract Low".  Paired with "EXTract High" it certainly makes sense.


> I was hoping we would remove "sextract" (well, it is funny a little bit
> definitely, but if there are zillion occurrences, and used everyday, it just
> stops being funny, and is somewhat distracting...), however it looks we will
> get "sextend", and "sextend2", and "sex_h" and "sex_l"...

Why mention all of these brand new straw-man variants?  Anyway, we are not
children, giggling at a sequence of letters taken out of context.


r~

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

[Laurent Vivier]

Le 20/08/2019 à 18:44, David Hildenbrand a écrit :
> On 20.08.19 18:38, Aleksandar Markovic wrote:
>>> From: BALATON Zoltan <balaton@eik.bme.hu>
>>>
>>> Sorry to comment on this without really knowing what is it about but maybe
>>> my view is not completely useless if this is to be understood by people
>>> who don't know anything about it. If it is not useful just ignore.
>>
>> No, Zoltan, to the contrary, you hit the nail - the good interface scheme
>> should look natural even for people not acquainted with the gory details
>> of the area.
>>
> 
> I just got familiar with the terminology and everything I read so far
> confuses me even more (gather/pick/extend/extl/shrd). No, I don't like that.

Personally I agree with David, proposed terminology is not more obvious
to me and changing things just for matter of taste is not a good idea.

Thanks,
Laurent

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

[Aleksandar Markovic]

> From: Laurent Vivier <laurent@vivier.eu>
> 
> Personally I agree with David, proposed terminology is not more obvious
> to me and changing things just for matter of taste is not a good idea.

Thanks, Laurent for your input, but this in not a matter of taste, there
are exact metrics here - different things should be called differently,
not almost the same. Also, the API names should describe something,
they are not mnemonics.

Aleksandar

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

[Aleksandar Markovic]

> From: David Hildenbrand <david@redhat.com>
> 
> I just got familiar with the terminology and everything I read so far
> confuses me even more (gather/pick/extend/extl/shrd). No, I don't like that.

David,

How often did you use the functions in question? Thinks about that,
and about reasons for that.

Yours,
Aleksandar

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

[Aleksandar Markovic]

20.08.2019. 18.49, "Peter Maydell" <peter.maydell@linaro.org> је написао/ла:
>
> On Tue, 20 Aug 2019 at 17:44, David Hildenbrand <david@redhat.com> wrote:
> >
> > On 20.08.19 18:38, Aleksandar Markovic wrote:
> > >> From: BALATON Zoltan <balaton@eik.bme.hu>
> > >>
> > >> Sorry to comment on this without really knowing what is it about but
maybe
> > >> my view is not completely useless if this is to be understood by
people
> > >> who don't know anything about it. If it is not useful just ignore.
> > >
> > > No, Zoltan, to the contrary, you hit the nail - the good interface
scheme
> > > should look natural even for people not acquainted with the gory
details
> > > of the area.
> > >
> >
> > I just got familiar with the terminology and everything I read so far
> > confuses me even more (gather/pick/extend/extl/shrd). No, I don't like
that.
>
> FWIW the way I tend to approach these is to say "I want to do
> $WHATEVER, surely we must have a tcg op for that, it's probably
> got 'ext' in it, search through tcg/README to find something
> that seems like it matches what I want to do"...
>

I must admit this is the most practical, pragmatic view among us.

Aleksamdar

> thanks
> -- PMM
>

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

[David Hildenbrand]

On 20.08.19 19:02, Aleksandar Markovic wrote:
>> From: David Hildenbrand <david@redhat.com>
>>
>> I just got familiar with the terminology and everything I read so far
>> confuses me even more (gather/pick/extend/extl/shrd). No, I don't like that.
> 
> David,
> 
> How often did you use the functions in question? Thinks about that,
> and about reasons for that.

I just used a whole bunch of them when implementing vector instruction
support for s390x. See target/s390x/translate_vx.inc.c for example.

-- 

Thanks,

David / dhildenb

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

[Philippe Mathieu-Daudé]

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 <peter.maydell@linaro.org>
>>>> On Tue, 20 Aug 2019 at 13:50, Aleksandar Markovic
>>>> <amarkovic@wavecomp.com> 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.

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

[Philippe Mathieu-Daudé]

On 8/20/19 6:21 PM, BALATON Zoltan wrote:
>On 8/20/19 5:37 PM, Richard Henderson wrote:
>> 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
> 
> Again this might look familiar to those knowing AArch64 but not to
> someone who does not know that. Maybe zext sext is a bit more decypherable.

Both namings seems acceptable.

Not sure if the lexicographic distance is reduced, neither if reducing
it would make a difference :)

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

[Aleksandar Markovic]

<amarkovic@wavecomp.com> wrote:
> > ...
> > 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
>

After a while, I realized that this idea would remove majority of potential
confusing spots, and even make names slightly shorter: (suppose other names
would remain intact)

* tcg_gen_ext8s_i32 t0, t1  to  tcg_gen_sxt8_i32 t0, t1
* tcg_gen_ext8u_i32 t0, t1 to  tcg_gen_zxt8_i32 t0, t1
* tcg_gen_ext16s_i32 t0, t1  to  tcg_gen_sxt16_i32 t0, t1
* tcg_gen_ext16u_i32 t0, t1  to  tcg_gen_zxt16_i32 t0, t1

8 or 16-bit sign/zero extension (both operands must be 32-bit)

* tcg_gen_ext8s_i64 t0, t1  to  tcg_gen_sxt8_i64 t0, t1
* tcg_gen_ext8u_i64 t0, t1 to  tcg_gen_zxt8_i64 t0, t1
* tcg_gen_ext16s_i64 t0, t1  to  tcg_gen_sxt16_i64 t0, t1
* tcg_gen_ext16u_i64 t0, t1  to  tcg_gen_zxt16_i64 t0, t1
* tcg_gen_ext32s_i64 t0, t1  to  tcg_gen_sxt32_i64 t0, t1
* tcg_gen_ext32u_i64 t0, t1  to  tcg_gen_zxt32_i64 t0, t1

8, 16 or 32-bit sign/zero extension (both operands must be 64-bit)

* tcg_gen_ext_i32_i64 t0, t1  to  tcg_gen_sxt_i32_i64 t0, t1

Convert t1 (32-bit) to t0 (64-bit) and does sign extension

* tcg_gen_extu_i32_i64 t0, t1  to  tcg_gen_zxt_i32_i64 t0, t1

Convert t1 (32-bit) to t0 (64-bit) and does zero extension

Any observation?

Thanks,

Aleksandar

>
> r~
>