assets/developer-notes/stephanie-gawroriski/2016/03/30.mkd

   1 # 2016/03/30
   2
   3 ## 11:00
   4
   5 I suppose I can have a single class for variable states, I could also just
   6 merge the stack and locals into one single list so that the visible state of
   7 all operations are combined as one. I would only have to maintain a single
   8 state, but it would have to be able to handle the stack and such. It would
   9 have to be like my old one, where variable types and such are implicit.
  10 Although this time instead of being actually existing and forced into memory
  11 it is instead cached fully. Thinking about other things, I likely do not need
  12 to do the program output as I can use the `JVMByteProgram` class and use that
  13 for translation and such. This class would be handling the SSA and such and
  14 it could be combined into an interpreter of sorts also.
  15
  16 ## 11:04
  17
  18 The program will have an initial input state which is determined by the method
  19 signature and if it is an instance method or not. When the `StackMapTable` is
  20 read in the future it will instead of modifying the state of an instruction
  21 like I have done before, it will become a sort of "checked" state which when
  22 a check is done, it must be the result for a given operation. This way I do
  23 not have to juggle setting that state and having derivations of it. Essentially
  24 there would be no derivations so to speak as the output of an instruction would
  25 be run through the instruction. It would be cached of course. In the end,
  26 although using caches much will increase the CPU requirements, it will allow
  27 the interpreter to run on tighter constrained systems. However since the code
  28 blocks of all classes must be in memory it is unlikely that the interpreter
  29 will run at all on constrained systems. Thus on said systems it will likely
  30 only be AOT only or a JIT of sorts which compiles as needed.
  31
  32 ## 11:10
  33
  34 For input and output chaining, they can share the same objects so to speak.
  35 The initial method inputs will be the input for the first instruction. The
  36 output of the first instruction will be the input of the next instruction (or
  37 any points it jumps to). So, I will have to scan the code for jumping points
  38 so that can correctly be determined. However, the only jumping around
  39 instructions are literal `goto`s and comparison branches. Exception handlers
  40 would also have to be known too.
  41
  42 ## 13:20
  43
  44 I will need an efficient way to store the control flow graph, most of the flow
  45 is implied as it always goes forwards. All of the other parts depend on
  46 comparisons and such. I need a fast and and an efficent way to store all the
  47 information. I could use a map. However I believe what I will do is have a map
  48 of destinations which are then sourced. When evaluating instructions, it is
  49 known what it jumps to however in general processing sources are not known
  50 until the entire program is parsed. So it will contain a set of jump sources
  51 which are either normal, conditional, or exceptional. I should probably move
  52 the program stuff to its own package also.
  53
  54 ## 13:27
  55
  56 I will need a prefix for the program though, not `JVM` but something else.
  57 Perhaps just `PRG`.
  58
  59 ## 13:56
  60
  61 For program sources, all instructions can have it. If there is none in the
  62 source mapping then it is an implied previous instruction. I would have to
  63 build it around places where there is no natural flow to the instruction. For
  64 example an instruction after `return` or `athrow` with no other jump sources
  65 would need to be initialized with a blank jump source because it is not
  66 reachable, otherwise if none is set then the implied one will be used instead.
  67
  68 ## 13:58
  69
  70 Going to need a good way to represent the state of variables in the program.
  71 Ones which are both implicit and explicit. Something similar to the operator
  72 links but a bit better perhaps.
  73
  74 ## 18:16
  75
  76 It would be nice to generate some documentation of the source code (i.e. the
  77 JavaDoc) and then host it somewhere.
  78
  79 ## 19:11
  80
  81 I suppose states would be based on the initial instruction as input. The first
  82 instruction would always return the method input state, while other
  83 instructions for input will pull from one of the sources it has. If there are
  84 multiple entry points for an instruction, then an intersection of the base
  85 outputs would be used instead (they must be compatible however). The
  86 `StackMapTable` and other attributed details can instead be something different
  87 and act as an input verification state rather than actually being state. This
  88 means that the states do not have to stick around if they are not needed, it
  89 also simplifies things also.
  90
  91 ## 20:39
  92
  93 Better to split off the operations before it gets too large.
  94