Intel® ISA Extensions
Use hardware-based isolation and memory encryption to provide more code protection in your solutions.
1123 Discussions

Multiple potential issues in ISA extensions doc 055

Beulich__Jan
New Contributor I
404 Views

While 055 corrected some minor issues from 054, (imo) more severe issues remain:

- As also noted by Christian Ludloff (see https://www.sandpile.org/x86/opc_3.htm), TCVTROWPS2P* (imm) encodings look like they're wrong: Likely all share opcode 77 and prefixes
match the non-imm counterparts.

- TCVTROWPS2P* (both reg and imm) prefix use looks suspicious: It would be more natural if one
prefix bit encoded result form (fp16 vs bf16) and the other encoded result placement (h/l).

- Is it really TILELOADDRS{,T1}, not TILELOADRSD{,T1} (more in line with VMOVRS[BWDQ]), i.e. "RS" ahead of the element size indicator? Similarly T2RPNTLVW{Z0,Z1}RS{,T1} vs T2RPNTLVRSW{Z0,Z1}{,T1}.

- Does TTDPFP16PS really belong to AMX-BF16, not AMX-FP16?

- Exception class AMX-E11 is missing.

- How come TILEMOVEROW and TILECVTROW* exist only in 512-bit form? That contradicts the AVX10.2/256 model.

0 Kudos
1 Reply
Beulich__Jan
New Contributor I
290 Views

Further:

- What's the APX encoding for MOVRS? The MSR-IMM insns have their APX forms specified when (like for the USER-MSR ones) the EVEX encoding is kind of obvious, yet for MOVRS - living in opcode space 0F38 - it's entirely unclear at what major opcode they would end up in (presumably EVEX map 4).

- What are the VMEXIT codes for MSR-IMM, and where are the MSR indexes placed for the VMM to retrieve?

0 Kudos
Reply