Re: [PATCH 04/10] Support Intel CMPccXADD

["H.J. Lu" <hjl.tools@gmail.com>]

On Sat, Oct 15, 2022 at 11:34 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.10.2022 23:51, H.J. Lu wrote:
> > On Fri, Oct 14, 2022 at 11:27 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >>  On Fri, Oct 14, 2022 at 6:46 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>> On 14.10.2022 11:12, Haochen Jiang wrote:
> >>>> @@ -8480,6 +8609,70 @@ static const struct dis386 mod_table[][2] = {
> >>>>      /* MOD_VEX_0F38B1*/
> >>>>      { VEX_W_TABLE (VEX_W_0F38B1) },
> >>>>    },
> >>>> +  {
> >>>> +    /* MOD_VEX_0F38E0_X86_64 */
> >>>> +    { "cmpoxadd", { Mdq, Gdq, VexGdq }, PREFIX_DATA },
> >>>> +  },
> >>>> +  {
> >>>> +    /* MOD_VEX_0F38E1_X86_64 */
> >>>> +    { "cmpnoxadd", { Mdq, Gdq, VexGdq }, PREFIX_DATA },
> >>>> +  },
> >>>> +  {
> >>>> +    /* MOD_VEX_0F38E2_X86_64 */
> >>>> +    { "cmpbxadd", { Mdq, Gdq, VexGdq }, PREFIX_DATA },
> >>>> +  },
> >>>> +  {
> >>>> +    /* MOD_VEX_0F38E3_X86_64 */
> >>>> +    { "cmpnbxadd", { Mdq, Gdq, VexGdq }, PREFIX_DATA },
> >>>
> >>> I understand the ISA extensions document names the insn this way and doesn't
> >>> list cmpaexadd (same for other aliases), but I think this is a mistake in
> >>
> >> Lack of aliases is a bad thing.  In any case, assembler should follow
> >
> > Oops.  I meant "Lack of aliases isn't a bad thing."   Aliases make me
> > wonder if 2 different jcc are really different.
>
> Have you taken the time to read through my question raised in the forum?
> There is a reason for there being multiple names for a single condition
> code: What is meant depends on context. As said there, JZ makes sense to
> use with e.g. TEST or SUB, but it doesn't make sense to use with CMP
> (where JE is the appropriate mnemonic). Here we're talking of only CMP
> (an advanced form of it), so not being able to use CMPEXADD (for there
> only being CMPZXADD) is an issue.

You have a point here.

> >> the spec.
>
> First of all the (early) spec should be sanitized. I'd be surprised if
> there were actually rational reasons for the choice of mnemonics which
> the doc currently lists; the set looks rather arbitrary to me. If the
> spec cannot be relied on, I think it's better to defer implementation of
> something that's questionable.
>
> Plus: What harm would there be if gas supported the full set of mnemonics
> even without the spec listing them all? It's not like there's any non-
> negligible risk of these mnemonics later gaining some different meaning.
>
> Jan
>
> >>> the doc. I've raised a respective question in the ISA extensions forum: I
> >>> think representation of conditions to check for should be uniform among
> >>> insns, and hence it should be "ae" here. (That would also be the effect if
> >>> you used %C<whatever> here.)
>


-- 
H.J.