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 <
address@hidden> 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.


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