Re: [RFC] x86: proposal for a new .insn directive

[Jan Beulich <jbeulich@suse.com>]

On 20.01.2023 02:25, Jiang, Haochen wrote:
>>>>
>>>> # TBD: How to specify the Disp8 scaling factor here? (In Intel syntax we can
>> simply
>>>> #      use memory operand size.)
>>>>         .insn EVEX.66.0F38.W0 0x88, 4(%eax), %ymm1      # vexpandps
>> 4(%eax), %ymm1
> 
> One of the way I think is to add a field at encoding
> 
> {VEX,XOP,EVEX}[.<len>][.<prefix>][.<space>][.<w>][.<memory>]
> 
> <memory> could be x or y.
> If <memory> is omitted, it is implied by register size or it is in Intel syntax.

I don't see how x or y would apply here. The Disp8 scaling size for this
and alike (e.g. also S/G insns) is element size, and hence can't be
derived from operand size (which I take x and y are kind of meant to
refer to). (Yes, a similar issue exists with insns where we have x/y/z
pseudo-suffixes in AT&T mode, but I specifically chose the example above
to point out that we need to go beyond x/y/z.)

While to address the issue with immediates right now I'm considering a
prefix (C cast like) notation e.g. $(s16)0x12, for EVEX memory operand
displacement handling it likely needs to be something different, e.g.
(%rax):4, to avoid possible parsing ambiguities. Question then would be
what to do when there is a non-zero displacement but no such specifier:
We could then derive it from other (register) operands, but we could
also default to avoid Disp8 in such cases. (This similarly affects
Intel syntax, wrt presence/absence of an operand size specifier on the
memory operand.)

Of course such a suffix notation could then also be used for immediates,
e.g. $0x12:u16 or $symbol:s32, which would overall end up looking a
little more uniform.

> But the potential problem is that if we have to add a field every time we meet
> something special, the directive will turn out to be longer and longer and more
> and more complicated. I don't know whether everyone like this.

I view this not so much as a problem because of the growth, but because
of my present goal being for this to largely match what the SDM uses
(with limited extensions, part of which are actually up for discussion).

Jan