- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page