assets/developer-notes/stephanie-gawroriski/2016/04/10.mkd

   1 # 2016/04/10
   2
   3 ## 09:31
   4
   5 Now to continue with code generation and such.
   6
   7 ## 10:21
   8
   9 `CPVariableStates` may require the list of jump sources and the verification
  10 state so derivation can determine what is what.
  11
  12 ## 10:48
  13
  14 Actually it is not needed to pass it to them, the derivation can determine
  15 such things.
  16
  17 ## 12:14
  18
  19 I do wonder though if the current `classprogram` is overly complex and cached.
  20 Right now I have a mashup of states which are all mutable and rather
  21 intertwined with other states. However due to my recent refactoring and split
  22 placement I should be able to change the entire `classprogram` structure
  23 without requiring that I rework parts of the interpreter and such since I do
  24 like some existing things. I like the operation handlers and the computational
  25 state. The one thing that I would change is all the dynamic variable states
  26 and the operations. The operations would be kept logical except their type
  27 would be known and there could be possible derivations of `CPOp` for specific
  28 instructions. Operations could still use computations. However the goal of
  29 this refactor would be a very broadband simplification of the code. I would
  30 still have SSA in the end however. I would propose that I:
  31
  32  1. Get logical instruction orderings like I already do.
  33     * This is good because there are no gaps, the next instruction is always
  34       +1 and not +3 in some cases +2 in others.
  35     * Simplifies jumps and checking of states.
  36  2. Have `CPOp` for every instruction precreated with their initialized state
  37     with verifications.
  38     * These operations would chain to others potentially.
  39  3. Determine the variable states for every instruction along with their type
  40     inside of `CPOp`.
  41  4. Handle exceptions and such.
  42     * The SSA variable IDs would be merged and potentially "phi"ed if an
  43       instruction has multiple entry points and local variables contain
  44       different states.
  45     * Would also need to handle conditions where a variable may be used in an
  46       exception handlers and branches so that their values are saved even if
  47       they are pointless operations. However, this would only be done when
  48       it is a local to local copy, copies from locals to the stack are still
  49       pointless.
  50     * As such, the stack **NEVER** gets "phi"ed.
  51  5. Verify the states are correct by parsing the `StackMap`/`StackMapTable` and
  52     then dropping the verification info since it would not be needed.
  53     * Local variables which get removed away would not require that they be
  54       saved.
  55  6. Each operation would be able to be passed to a computational machine.
  56     * Operations that generally have no effect (they are copies) would just
  57       not perform any computations.
  58     * However, if a variable is "phi"ed then a computation is performed on it.
  59     * The general cases, storing values into locals would result in them
  60       potentially getting stored even if they are not actually used in the
  61       future. Later optimization passes could determine this however.
  62
  63 I would also keep the combined local and stack elements since uniformity is
  64 nice.
  65
  66 As for "phi", the variable states for each operation would have a flag which
  67 specifies that it is a junction of other types and that its current value is
  68 not really that known yet.
  69
  70 ## 12:29
  71
  72 This should in general result in cleaner and easier to maintain code, with an
  73 added speed bonus at the cost of using extra memory (since now entire methods
  74 would have to exist within memory). Thus most of the existing classes I have
  75 would generally still exist, however they would be radically different
  76 compared to before.
  77
  78 ## 12:32
  79
  80 `CPProgramBuilder` would be merged into `CPProgram` and become its constructor.
  81
  82 ## 19:11
  83
  84 Instead of jump target, the following addresses could just be operations. I
  85 know of a way where I can determine the jump targets and have it all in the
  86 operation code as required. The same could be said for operation sources. With
  87 this I would completely remove the jump source and jump target list.
  88
  89 ## 19:17
  90
  91 After I determine the natural and exception flow of instructions I can follow
  92 with determine the states of variables and the SSA required bits such as "phi"
  93 junctions and uniquely set values. However in retrospect, this new operation
  94 handling is far simpler than before despite it having some recursion involved.
  95 In general it should result in code that is much cleaner to maintain since the
  96 current existing program representation was just a gigantic mess of mutables,
  97 references, and other things. In the current case, the program description is
  98 completely mutable which means multiple threads can safely work on it without
  99 requiring locks. Thus as a result, the interpreter speed would be increased.
 100
 101 ## 22:02
 102
 103 It would be too complex in the constructor to calculate the SSA states and
 104 such, thus that will be delayed so that it is calculated when it is needed for
 105 example.
 106
 107 ## 22:16
 108
 109 I suppose I shall sleep soon, however with part of my pre-existing base and
 110 refactoring the operations, things are a bit simpler now. The control flow
 111 graph is more direct in that operations are used rather than jump targets and
 112 jump sources. So a slight level of indirection was removed. Following this, the
 113 variable types and SSA variables will need to be initialized. For that, the
 114 types can be implicit as specified by the stack map, or explicit which is based
 115 on actual operations. So the compute machine and the operation handlers will
 116 return as such. They have not really gone away at all anyway. The class program
 117 code is still the most line heavy code however at 1733 sloccount lines. However
 118 once every operation is handled and the variable states are setup, I predict it
 119 may be aroung 4000 lines total. 4000 is quite a high number, however the
 120 operation handlers for each instruction that exists will add to the count by
 121 quite a number. Once the SSA states and other such things get enough of a base
 122 I can continue interpretation. The operation initialization is a bit recursive
 123 however. The exception handler linking stuff by having it scan around makes it
 124 a `O(n^2)` operation which is quite slow. So a gigantic method containing
 125 65535 logical instructions will require about 4 billion iterations. I would
 126 say tommorrow that I do something I did similarly to the jump sources.
 127 Otherwise it will just be really really slow when more bulky methods come into
 128 play.
 129
 130 ## 22:32
 131
 132 While I prepared to go to sleep, I found a bug in my implementation. I just
 133 assign exceptions to every single instruction and use all of them instead of
 134 checking to see if they are in range or not. So this needs fixing, also in the
 135 code which does that I can do the similar thing to jump sources.
 136