assets/developer-notes/stephanie-gawroriski/2019/06/14.mkd

   1 # 2019/06/14
   2
   3 ## 09:11
   4
   5 Okay so instead of passing stuff like classpath and otherwise, I am going to
   6 have a configuration ROM where all the settings and initial stuff set by the
   7 VM are stored. This will allow it to grow in size and support other options in
   8 the future so that SummerCoat/RatufaCoat do not need to be completely changed
   9 to support new configuration items. But this will definitely help and make it
  10 nice and cool to work with. It will also probably be easier to generate as
  11 well.
  12
  13 ## 11:39
  14
  15 Okay so now I have this much better looking config ROM, so this will be nice!
  16 The good thing in this case is I will be able to write to a rather expanding
  17 format of things, without needing to hardcode various parameters in the method
  18 call. This very much future proofs the VM and such.
  19
  20 ## 11:40
  21
  22 So the next thing to figure out is, what causes the arguments to mess up and
  23 such.
  24
  25 ## 11:43
  26
  27 So I might have an idea, maybe it is related to the volatiles? It did work
  28 before the return values were fixed by using temporary volatiles. So not too
  29 sure then.
  30
  31 ## 11:45
  32
  33 It might be code being called in the boot strap, but I am pretty sure I want
  34 to be sure it is not code being done in the actual note code itself. I mean
  35 calling other methods are fine.
  36
  37 ## 11:48
  38
  39 Okay so, in note 8 and 9 are being used correctly when being passed to the
  40 note method. Additionally 8 is being used as the object to do length on.
  41
  42 ## 11:51
  43
  44 Unless the RAM links are like too short at the start? I should check that out.
  45
  46 ## 11:53
  47
  48 Okay the RAM links are fine. So it seems like it has trouble getting the
  49 vtable of what was pushed in. But the big thing is that they end up being the
  50 same exact arguments.
  51
  52 ## 11:57
  53
  54 So I think note is fine?
  55
  56 ## 13:28
  57
  58 Okay so this is the call to the notes. The registers 14 and 15 seem to be fine
  59 so these are okay. However they are the same value.
  60
  61         ***** @4f1155e4 INVOKE             /INVOKESTAT | L51  /J23  reljme/jvm/
  62         Bootstrap::__start:(IIIIII)V
  63         A:[        23,         14,         15] | V:[+1326452060,   +1067384,
  64         +1067384]
  65         >>>> 4f100d5c >>>>>>>>>>>>>>>>>>>>>>
  66         > ARG [1067384, 1067384]
  67         > WAS cc/squirreljme/jvm/Bootstrap.__start:(IIIIII)V @4F1155E4h (:51
  68         J184@23)
  69
  70 ## 13:31
  71
  72 Okay so, 14 is the result of `jvmLoadString()` and 15 is the result of
  73 `jvmNewArray`. Maybe with all of the return changes I made, I accidently saved
  74 or trashed the value of the return with what was previously in it. So no idea.
  75
  76 ## 13:34
  77
  78 So I should look in `jvmNewArray` just to see.
  79
  80 ## 13:43
  81
  82 Okay, so removing the code test debug makes things work. Like the act of
  83 calling `Assembly.objectToPointer("Hello?")` messes up. Storing the string and
  84 never using it again, messes up? Okay so, if a string is referred to but is
  85 never used to where it would become GC electable, it just fails to work
  86 properly?
  87
  88 ## 15:20
  89
  90 More issues with `jvmLoadString()`. So will need to solve that actually.