[PATCH 06/10] Support Intel RAO-INT

[H.J. Lu]

On Mon, Oct 31, 2022 at 2:42 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 28.10.2022 18:08, H.J. Lu wrote:
> > On Fri, Oct 28, 2022 at 1:40 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 28.10.2022 10:31, Jiang, Haochen wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Friday, October 28, 2022 4:22 PM
> >>>>
> >>>> On 28.10.2022 10:10, Jiang, Haochen wrote:
> >>>>> BTW, should the suffix instruction dependent? It might be more operand
> >>>>> related from my opinion. If that is the truth, could we just judge
> >>>>> whether we should add them when dealing with memory operands?
> >>>>
> >>>> I'm afraid I don't really understand what you're saying/asking here.
> >>>> In any event - whether a suffix is required indeed depends on insn operands.
> >>>> Yet even insns with (only) GPR operands _may_ use a suffix in AT&T mode,
> >>>> irrespective of it being derivable from those GPR operands. We actually apply
> >>>> consistency checks between registers used and the suffix (if present).
> >>>
> >>> What I am saying is we could put all the suffix module out of instructions. If we
> >>> found that are using those variable GPR operands, then to determine whether
> >>> we should allow suffixes instead of determining at instructions.
> >>
> >> Once again - even with GPR operands use of suffixes is permitted (and
> >> actually kind of mandated by the only AT&T spec I'm aware of). You
> >> may have seen the series that I have pending to re-work some of the
> >> suffix recognition, but that's certainly not going in the direction
> >> you're suggesting (if I understand what you're saying; perhaps if you
> >> gave an example it might become more clear).
> >>
> >
> > The old AT&T syntax rules, which are quite vague, don't apply to new
> > instructions.
>
> Why would they not? These rules are intended to cover the full set of

The rules are quite vague and the same mnemonic can mean very
different instructions, depending on the operands.

> insns. I'm afraid I need to keep repeating myself: Inconsistency here
> leads to non-predictable overall behavior of the assembler (and of
> the disassembler as well, in suffix-always mode, just that there it
> won't lead to unexpected errors).

We can't change the behavior of old instructions.  For new instructions,
the unnecessary suffixes should be avoided.

> Jan
>
> > For new instructions, the suffix should be permitted and required only
> > if it must
> > be used to specify the operand size.
> >
> >
>


-- 
H.J.