Encodings for instructions with {sae} are unclear in the doc

[Michael_R_8]

Chapter 4.6 indicates that EVEX.L'L is encoded for the vector length, and that {sae} is supported for all vector lengths.

However, the various instruction pages, such as VCMPPD, only show {sae} for 512-bit vectors.  Furthermore, the E2 #UD equations indicate that EVEX.L'L must be 10b (VL=512).

Furthermore, GNU gas assembles VCMPPD zmm, zmm, {sae} with EVEX.L'L = 00b.  It will not assemble VCMPPD ymm, ymm, {sae} or VCMPPD xmm, xmm, {sae}.  Also GNU objdump ignores EVEX.L'L for both vector and scalar instructions with {sae} (using .byte instruction to create encodings with all possible EVEX.L'L values).

I haven't yet tried assembling with masm, nasm, or yasm.

So the question is, what's the truth?

(1) Does the CPU ignore EVEX.L'L and implicitly use VL=512 for vector and VL=128 for scalar instructions (same as with {er}), or does it require the correct value for EVEX.L'L?

(2) If the latter case, then does the CPU actually execute with VL=128 or VL=256, or do these #UD?

Another discrepancy in the doc:  The E3 #UD equations, which include VCMPSD/SS, say that EVEX.b = 0 is required.  I assume this is wrong and should be removed.  Also, the instruction description show the encoding as LIG and W1 or W0, whereas the VEX version shows the encodings as 128 and WIG.  I would have expected that VEX and EVEX encodings for the same instruction should have similar encodings.  I also see that the Software Developer's Manual lists the VEX encoding as LIG; so I would guess that the 128 notation in the ISE Manual should read LIB.

Finally, it would be nice if the PDF documents have links wherever there is a mention of  'Exceptions Type ...'.  This applies also to the Software Developer's Manual.  References to VEX encoded exceptions in the ISE Manual might also mention that these are found in the SDM Volume 2.

[Michael_R_8]

I ran some VCMPSD/PD instructions with the Intel SDE, with these results...

TID0: INS 0x0000000100401000             AVX512EVEX vcmppd k1{sae}, zmm1, zmm2, 0x0
TID0:   k1 := 00000000_000000ff
TID0: INS 0x0000000100401007             AVX512EVEX vcmpsd k1{sae}, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x000000010040100e             AVX512EVEX vcmppd k1, zmm1, zmm2, 0x0
TID0:   k1 := 00000000_000000ff
TID0: INS 0x0000000100401015             AVX512EVEX vcmpsd k1, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x000000010040101c             AVX512EVEX vcmppd k1{sae}, zmm1, zmm2, 0x0
TID0:   k1 := 00000000_000000ff
TID0: INS 0x0000000100401023             AVX512EVEX vcmppd k1{sae}, zmm1, zmm2, 0x0
TID0:   k1 := 00000000_000000ff
TID0: INS 0x000000010040102a             AVX512EVEX vcmppd k1{sae}, zmm1, zmm2, 0x0
TID0:   k1 := 00000000_000000ff
TID0: INS 0x0000000100401031             AVX512EVEX vcmppd k1{sae}, zmm1, zmm2, 0x0
TID0:   k1 := 00000000_000000ff
TID0: INS 0x0000000100401038             AVX512EVEX vcmpsd k1{sae}, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x000000010040103f             AVX512EVEX vcmpsd k1{sae}, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x0000000100401046             AVX512EVEX vcmpsd k1{sae}, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x000000010040104d             AVX512EVEX vcmpsd k1{sae}, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x0000000100401054             AVX512EVEX vcmpsd k1, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x000000010040105b             AVX512EVEX vcmpsd k1, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x0000000100401062             AVX512EVEX vcmpsd k1, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x0000000100401069             AVX512EVEX vcmpsd k1, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000001
TID0: INS 0x0000000100401070             AVX512EVEX vcmppd k1, xmm1, xmm2, 0x0
TID0:   k1 := 00000000_00000003
TID0: INS 0x0000000100401077             AVX512EVEX vcmppd k1, ymm1, ymm2, 0x0
TID0:   k1 := 00000000_0000000f
TID0: INS 0x000000010040107e             AVX512EVEX vcmppd k1, zmm1, zmm2, 0x0
TID0:   k1 := 00000000_000000ff
TID0: SIG signal=0xc000001d on thread 0 at address 0x100401085 EXCEPTION

The last 16 of these, including the one with the exception, were created using the .byte instruction, and have all 4 of the L'L values.

I note that the L'L value has no effect on the disassembly, same as with GNU objdump.

More interestingly, the emulator also ignores L'L in the emulation with {sae} present.  It does not raise any exceptions.  The k1 values indicate that it is comparing scalars with vcmpsd and zmm vectors with vcmppd.

The emulator ignores L'L for vcmpsd without {sae}, and has no exceptions.  It interprets L'L as the vector length for vcmppd without {sae}, including the exception where L'L = 11b.

Now it's possible that the emulator is wrong.  Personally, I'm inclined to trust the emulator.  If the emulator is right, then the documentation is wrong -- {sae} only supports 512-bit vectors, L'L is ignored, and no exception for L'L !0 10b in type E3, and no exception for b = 1 in type E2.

I have attached the executable file that SDE was running, so if someone has access to a real Knights Landing CPU, they can try running it.  You may need to delete '.txt' from the extension.

[MarkC_Intel]

For instructions which support embedded rounding and sae, embedded rounding and sae are only supported on the reg-reg forms of 512b and scalar operations (*{SS,SD}).  It is a limitation of the encoding scheme we chose.

I'll look at the other issues you mention...

[Michael_R_8]

Thanks for quick reply.  I thought that this was the case.  It would make sense from an instruction decoding point of view that {sae} and {er} would follow similar rules.  It also means that GNU gas is doing the right thing.

All you need to do is correct the documentation.

BTW, I tried attaching a file, which was foo.exe renamed to foo.exe.txt, but I don't see it in this post.  Can you tell me where I can find the attachment in the posting, and how I include an attachment.  Thanks.

[MarkC_Intel]

I forwarded the doc typo to the doc team. Thx for reporting that issue.

I don't know much about attachments on IDZ. I think the scanners probably remove exe's. Probably not safe in general.