From e51d2c03834eb7ddb281df738f735fdc4973a50d Mon Sep 17 00:00:00 2001
From: Søren Sandmann Pedersen <ssp@redhat.com>
Date: Sun, 1 Sep 2013 19:22:21 -0400
Subject: TODO

---
 TODO | 53 +++++++++++++++++++++++++++++++++++++++--------------
 1 file changed, 39 insertions(+), 14 deletions(-)

diff --git a/TODO b/TODO
index 7f5342a..df2c513 100644
--- a/TODO
+++ b/TODO
@@ -1,32 +1,57 @@
 - AVX 512
 
   - More registers, optional operands, opmasks.
-    Potential solution: encode all the additional stuff into one new operand
 
-    OPTION(k0, z, broadcast)
+    Potential solutions:
 
-    Another potential solution: Add pseudo-registers
+    * encode all the additional stuff into one new operand
+
+      OPTION(k0, z, broadcast)
+
+    * Add pseudo-registers
 
     	    k0m, k1m, k2m, ..., k7m
 	    k0z, k1z, k2z, ..., k7z
 
-    that corresponds to opmasks with zeroing/masking. This assumes
-    that opmasks are only used when zero/masking is also allowed, which
-    may not be true.
+      that corresponds to opmasks with zeroing/masking. This assumes
+      that opmasks are only used when zero/masking is also allowed,
+      which may not be true.
 
-    Another: Bite the bullet and add three new ops:
+    * Just add new mandatory ops:
 
     	     vaddps, zmm, k*, m/z, zmm, zmm, option
 
-  - There are additinal XMM and YMM registers as well, so we now need
-    the ability to choose EVEX encoding on the fly. The way to do this
-    is probably to introduce new optypes XMM_LO, YMM_LO, ZMM_LO(?),
-    and then change XMM to be XMM_LO | XMM_HI. Ie., similar to the
+      and require the user to specify, even when they want the
+      default.
+
+    * Support optional operands. Is this doable? It will require some
+      intelligence in variant selection. But the optional args will
+      have recognizable types, so it may not be impossible.
+
+    * It looks like the optional operands are generally considered
+      decorations on another existing operand.
+
+  - New disp8 addressing scheme. Requires emit_reg_regm to deal with
+    it and produce additional information to be stored in EVEX.
+
+  - There may be additinal XMM and YMM registers, so we now need the
+    ability to choose EVEX encoding on the fly. The way to do this is
+    probably to introduce new optypes XMM_LO, YMM_LO, ZMM_LO(?), and
+    then change XMM to be XMM_LO | XMM_HI. Ie., similar to the
     existing cases where some instructions can be encoded more
     efficiently when the register is ax, in this case some
     instructions can be encoded with VEX when the registers are
     *mm0-*mm15
 
+  - Some new variants of existing instructions have a different number
+    of operands, at least if you count optionals. For example
+    
+	vcmppd k1 { k2 }, zmm2, zmm/m512/bcst, imm8
+
+    vs
+
+	vcmppd ymm1, ymm2, ymm3/m256, imm8
+
 - Size directives
 
   - There are a number of cases where the op size can't be inferred
@@ -41,7 +66,7 @@
 
     	      add  PTR(ebx), imm8
 
-    which can have four sizes two. That goes for all the ALU ops in
+    which can have four sizes too. That goes for all the ALU ops in
     fact.
 
     Proposed solution: Add new OP_MEM8/16/32/64 and RIP_REL8/16/32/64
@@ -61,8 +86,8 @@
     - Some instructions will only allow the size directed variants.
     
 - The pextrw instruction got a new variant in SSE 4.1 where the
-destination can now be either a memory location or a register. In
-earlier versions it could only be a register. That means this code
+  destination can now be either a memory location or a register. In
+  earlier versions it could only be a register. That means this code
 
          pinsrw eax, xmm1, IMM (7)
 
-- 
cgit v1.2.3