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

   1 # 2019/03/30
   2
   3 ## 08:40
   4
   5 I definitley feel that `__StackState__` needs some refactoring. Something that
   6 is easy to copy for freezes and does not involve using references to other
   7 slots. Wonder if I can rework all of that to do such things.
   8
   9 ## 14:43
  10
  11 Actually, SquirrelJME is to be released in four weeks. So that will be
  12 something to work twords. Probably going to have to take some time snipping to
  13 make the release on time. Hopefully SummerCoat does not turn out horrible.
  14
  15 ## 14:45
  16
  17 Actually, idea.... what if I made the stack state immutable? I could easily
  18 compare it with other states and store them accordingly. I would just have to
  19 do bulk pushes and pops of course. Basically I would need to build stack
  20 actions and such. I think this would be easier to use than an immutable state
  21 and I could easily save it without having a third class.
  22
  23 ## 14:07
  24
  25 Also for stuff like swap and all the dup exchanges, I was thinking of perhaps
  26 having a shadow stack that is operated from. Essentially the swap and
  27 duplication do not actually do anything it just seems like they do.
  28
  29 ## 15:10
  30
  31 Or really what I can do are value registers and positional registers. This
  32 could work actually! There will have to be state stored for the value
  33 registers as well. But for example swapping will swap two types on the stack
  34 but their value register is swapped as well so nothing actually moves.
  35
  36 ## 15:35
  37
  38 For the stack result I am going to have to do availability or similar.
  39 basically say something needs to be uncounted, it will need to be done first
  40 before the register is made available or similar. I just have a very basic
  41 idea at this point.
  42
  43 ## 15:42
  44
  45 Actually, using the register value stuff instead of aliases will be easier
  46 for cache invalidation matching.
  47
  48 ## 16:04
  49
  50 Actually in the stack state I was adding proposals, but then I realized that
  51 the stuff is immutable which means I can actually do the destroy and get the
  52 result without actually setting the new state. Cool. This actually removes a
  53 ton of mess that I had previously which is nice. I am just kind of not sure
  54 how the uncaches will be done if they still need to be done the same as how
  55 they were before.
  56
  57 ## 16:24
  58
  59 Okay, so moving things around due to uncounting will be a huge pain to do.
  60 It just complicates things for the most part. So I think the best thing to do
  61 in this case would be to add a new instruction called `REF_ENQUEUE` which
  62 copies the values of registers to be reference uncounted. Then a call to
  63 `REF_CLEAR` will go through every enqueued copy to remove the reference
  64 counts. That way there is no insane complication or juggling of values and
  65 such. This simplifies things as well. I may though need new jumps for
  66 `IF_ACMPEQ`, `IF_ACMPNE`, `IFNE, and `IFEQ` because these can operate on
  67 objects potentially. Like I need a copy of all of those but ones that also
  68 do a `REF_CLEAR` after the condition is checked.
  69
  70 ## 16:49
  71
  72 Okay this seems much better than before, much easier to code for and I do
  73 not have to go crazy with the stack just to uncount references.
  74
  75 ## 18:50
  76
  77 The code is actually much smaller as a result as well and much easier to
  78 operate with. Even though I have TODOs in the stack stuff, I really like the
  79 new `REF_ENQUEUE` instruction as it solves so many things for me.