assets/developer-notes/stephanie-gawroriski/2019/03/26.mkd

   1 # 2019/03/26
   2
   3 ## 14:53
   4
   5 Got more code generated. The duplicate UNCOUNT+RETURN pairs still seem to be
   6 happening in this second constructor. Not sure why they are appearing, they
   7 should not.
   8
   9 ## 14:54
  10
  11 Oh, the next return index is never incremented.
  12
  13 ## 15:07
  14
  15 Okay, so it seems like the operation tables are not considered the same? The
  16 stack entries should be freed but it appears no code is generated for them
  17 just the zero uncount.
  18
  19 ## 15:10
  20
  21 A left over from when I cut and pasted the return stuff over. The return
  22 points were different but I was only handling the final state which was
  23 incorrect.
  24
  25 ## 15:43
  26
  27 I wonder if I can make it so that before a final return I can handle
  28 exceptions first or similar. But that would probably complicate things.
  29
  30 ## 17:21
  31
  32 I need to keep track of what has been counted and not counted. For example
  33 input arguments to a method do not need to be counted because they are
  34 passed already. As such they should not be uncounted at the end. I definitely
  35 will need a more advanced state tracker. I mean if an object is sent to a
  36 method then it will always have at least one reference then it does not
  37 need to be freed. I definitely need to refactor things. I think having a
  38 more standard instruction format will help as well. I should refactor this
  39 now before I continue so that way it does not get extremely messy. But for
  40 the code builder, I will do checks to ensure that only the right instruction
  41 format is used for writing to prevent programmatical errors from occuring.
  42 So as it stands I am going to have quite a mess of instructions.
  43
  44 ## 17:34
  45
  46 I definitely want to store the encoding type in the operation, so I guess the
  47 number of encodings may be a bit small perhaps. How much can I fit in 8-bits?
  48 So here is a table:
  49
  50  * Enc (Max) : Op (Max)
  51  *   1 (  2) :  7 (128)
  52  *   2 (  4) :  6 ( 64)
  53  *   3 (  8) :  5 ( 32)
  54  *   4 ( 16) :  4 ( 16)
  55  *   5 ( 32) :  3 (  8)
  56  *   6 ( 64) :  2 (  4)
  57  *   7 (128) :  1 (  2)
  58
  59 I mean realistically if I run out of room I can have encoding groups that are
  60 the same for two different groups. I know the encoding group that would be
  61 the biggest would be the math and conversion operations which convert from one
  62 type to another. I will have to make a spreadsheet and the encodings just to
  63 see how the layout is. Of course each operation would be a unique instruction
  64 the encoding just describes what it looks like. So I think 4-bits will work,
  65 have 16 different encoding types with 16 instructions each. For the tons of
  66 math operations they can just be last and use one big group since there are
  67 definitely more than 16 of them.
  68
  69 ## 19:40
  70
  71 Okay I have a table of operations and it seems the most efficient is 8 groups
  72 of 32 which can pretty much fit everything.
  73
  74 ## 19:42
  75
  76 But I can have 16 groups of 16 instructions. Currently I have 114 instructions
  77 taking up 13 groups, so that works. The three u16 group takes up 4 groups!