The VCVTPS2PH instruction is encoded incorrectly

[LinuxCoder13]

Reproducer

section .text
global _start

_start:
    vcvtps2ph [rax+rcx]{k2}, zmm2, {sae}, 10

Assembling with:

nasm -felf64 input.asm -o a.o

succeeds without an error.

NASM version:

NASM version 3.02

The resulting bytes are:

62 f3 7d 1a 1d 14 08 0a

GNU objdump 2.46.1 disassembles them as:

vcvtps2ph [rax+rcx*1]{bad}{k2},xmm2,0xa

The {bad} output makes me suspect that this is not a valid instruction encoding for the requested operand/decorator combination.

Relevant Intel documentation:

Intel SDM section 2.7.9 "SAE Support in EVEX" states that SAE support for arithmetic floating-point instructions applies to scalar and 512-bit vector lengths register-to-register only, by setting EVEX.b.

Therefore, a form containing a memory operand should not accept {sae} when SAE is restricted to register-to-register forms.

For comparison, my assembler rejects the same source with:

AmmAsm:5: SAE is only valid for register-to-register form

I would expect NASM to reject the source with an error indicating that {sae} is not valid for this operand combination, rather than emitting an encoding that objdump reports as {bad}.

NASM - 3.02
GNU binutils/objdump - 2.46.1
Target - ELF64 / x86-64

I may be misunderstanding some detail of the EVEX encoding, so please correct me if this particular encoding is actually architecturally valid.

[ludloff]

Look at x86/insns.dat.

VCVTPS2PH is in there twice, i.e. a 2nd time under AVX512FP. That's one problem (though a benign one, for now).

And then there are its typical double entries, for the mem-vs-reg forms.

There, the reg form has "|sae". That's your reported problem, yes?

Consider reviewing the whole database for this issue, not just the one instruction you ran into. :-)

[LinuxCoder13]

Look at x86/insns.dat.

yes...

VCVTPS2PH	mem256|mask,zmmreg|sae,imm8	[mri:hvm: evex.512.66.0f3a.w0 1d /r ib] AVX512

but any way, nasm should write some thing like SAE is only valid for register-to-register form