todo

2 files changed, 71 insertions, 11 deletions

diff --git a/TODO b/TODO
index 8bbeafb..7dde1e5 100644
--- a/TODO
+++ b/TODO
@@ -34,23 +34,34 @@
   - 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
+  - There may (or may not) 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
+  - A problem is that some of the new instructions have the same name
+    as existing ones, but different number of arguments. For example
+
+        VPGATHERDD zmm1 {k1}, vm32z 
+
+    in AVX-512 vs
+
+	VPGATHERDD xmm1, vm32x, xmm2
+
+    in AVX-2. There are also things like
+
+        VADDPS zmm1 {k1}{z}, zmm2,  zmm3/m512/m32bcst {er} 
 
     vs
 
-	vcmppd ymm1, ymm2, ymm3/m256, imm8
+        VADDPS ymm1, ymm2, ymm3/m256
+
+    A possibility is to just rename the avx-512 instructions to use a vz prefix
+    instead of v.
 
 - Size directives
 
diff --git a/iterjit.c b/iterjit.c
index af078b7..0e069a0 100644
--- a/iterjit.c
+++ b/iterjit.c
@@ -13,8 +13,57 @@
   - Register allocator should support "get location" of a register. If
     the register is spilled, the returned op will be a memory location.
     If not, it will be a register.
+
+  - Biting the bullet on a real register allocator:
+
+	- Introduce new OP_VAR that represent a variable to be
+	  register allocated. 
+
+	- Introduce new OP_VAR_MEM{8,16,32,64} that correspond to
+	  memory references where the involved registers are
+	  all unallocated variables.
+
+	- register allocator hands out variables when given a register
+	  pool
+
+	- Ghetto liveness analysis:
+
+		1. Variable is live between first assignment
+		   and last read
+
+		2. For each jump target, for all variables live there
+		   make them live at the jump source
+
+		3. Repeat 2 until it converges
+
+	- Linear scan allocation for each register class
+
+	- Run through code and generate allocated machine code
+
+	  - Spilled variables will sometimes need to be loaded into
+	    registers; when that happens, we need to be able to 
     
-    
+	- Information required from the assembler:
+	    - which arguments are read and written
+	    - in which cases is a register *required*?
+	      - this second one could just be done by
+	        adding an api to "check" an instruction:
+
+		   check (I_mov, PTR (eax), PTR (ebx))
+
+		for example would not be allowed since there
+		are two memory references.
+
+		The technique for dealing with spilled variables
+		is to:
+		     1. first check the instruction with memory
+		        references
+		     2. if that fails, then load one of the operands
+		        into a register
+		     3. if that fails, then load the other into
+		        a register
+		     4. if that fails, then load both into registers
+		        (this should be rare/impossible)
 
   Flow:
   - outer loop: