assets/developer-notes/stephanie-gawroriski/2016/01/16.mkd

   1 # 2016/01/16
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 ## 11:29
  10
  11 Not sure if I need to output anything else for the Java instruction dump to
  12 the manifests.
  13
  14 ## 11:48
  15
  16 And now to redump the PowerPC manifests so that it matches the newer format
  17 and has the image const and value set (which is for decoding).
  18
  19 ## 13:20
  20
  21 Well the new field layout is much more compact and probably easier to
  22 understand.
  23
  24 ## 14:58
  25
  26 The joys of distributed version control where you have the entire history.
  27 Going back in time has been quite helpful too. Now I have the new stuff for the
  28 instructions so I can continue on the refactor of `ArchitectureData`. I do
  29 wonder though if it would be possible for me to keep a map which bases the key
  30 on the value. I could make a special map type for that, it would require
  31 loading of the manifest to determine the name of the instruction however. But
  32 before I do that I will need to cleanout the Java and PowerPC code.
  33
  34 ## 15:16
  35
  36 I wonder if I can split off `java.net` or at least have two new packages to
  37 make the jump lighter. Appears I will need to split off URI/URL. Then I can
  38 have the socket based stuff in `java.nio` go into the net package. There would
  39 be a splice between them, however it would split them even further apart. I
  40 need to look at InetAddress though since the SecurityManager uses that.
  41
  42 ## 15:26
  43
  44 I can actually split off `java.math`. Actually no I cannot due to a few
  45 imports due to Java 8's streams.
  46
  47 ## 16:33
  48
  49 I believe I will have to fork POIT to fixup for these new changes.
  50
  51 ## 16:46
  52
  53 I could attempt writing up NARF with some of the stuff I learned from POIT.
  54 POIT will generate very bloated code for the most part even for the simplest
  55 of methods. However, SSA is insanely complex.
  56
  57 ## 16:57
  58
  59 Perhaps I can use a threading approach. Basically the entire layout of the
  60 method will be placed and operands and their register usages will be determined
  61 and stored. Instructions will have a flow back (dependency) and used local and
  62 stack variables would have a usage and liveness so to speak.
  63
  64 ## 17:05
  65
  66 Actually for thrown exceptions, the only odd time they are thrown is during
  67 potentially very fatal virtual machine failures. However for speed, my virtual
  68 machine should just read from null pointers and such (except if there is no
  69 MMU available, it must check them) so that a trap in the CPU is triggered and
  70 then where an exception is generated, rather than just checking for null
  71 pointers. A check against a null pointer can just be a dereference of the
  72 pointer, I do not really have to do anything with it. Of course though, the
  73 first page of memory must not be writable, however if a system needs it it is
  74 possible to have a null pointer which is NOT zero.
  75
  76 ## 17:20
  77
  78 Actually instead of having register shuffling to that their numbers are dynamic
  79 to the code running, there could instead be virtual registers which map to real
  80 registers and stack locations. So basically something such as this:
  81
  82         The stack
  83         -------------------------
  84         sjl1 Save area for Java local variables on the CPU stack.
  85         sjl* ...
  86         sjs1 Save area for Java stack variables on the CPU stack.
  87         sjs* ...
  88
  89 So essentially, a Java operation which performs on stack entries will have a
  90 modifiable (if needed) link to a Java local/stack. The code in POIT already
  91 has a fixed location for locals and stack items however it is very fixed in
  92 that temporaries are needed if the stack/local is really large. However, using
  93 a kind of pointer system, registers would be saved into their local/stack
  94 positions so that if an exception is thrown or a method call is returned from,
  95 it can just load from the saved position as needed. The only thing though is
  96 that having the registers caller save would be better, however the positions
  97 of entries on the stack/locals might not be known to methods being called (they
  98 would be unable to know the size of the stack/locals). There are the method
  99 table of contents however. But my point is that if a method is called and it
 100 wants to save `r17` because it overwrites the value, it would have no idea
 101 where to store that value before the method call is done. So to simplify the
 102 handling of this, before all methods (or null pointers are dereferenced) the
 103 registers which are active will have to be saved and restored. Otherwise if
 104 they are not saved, then on the handling of an exception values of locals will
 105 have incorrect values.
 106
 107 ## 17:31
 108
 109 Now say if there is a jump back from a later instruction to an earlier
 110 instruction. SSA would demand using `phi` and require more complex parsing to
 111 be done. However for simplicity I can generate code which performs a jump call
 112 back to reload the required registers to the correct locations for the target
 113 block before jumping to it. This way, when the code is first entered that is
 114 not done because things are normal. Essentially it would be like this as an
 115 example:
 116
 117         // Block of code is entered at this point
 118         _entry1:
 119
 120         instruction 1
 121         instruction 2
 122         instruction 3
 123
 124         if foo, jump to _prejumpentry1
 125
 126         instruction 4
 127         instruction 5
 128
 129         return
 130
 131         _prejumpentry1:
 132
 133         move around links before the jump is made
 134
 135         jump to _entry1
 136
 137 Exceptions would be sort of similar if they jump, however the dispatcher which
 138 determines the exception for handling will determine the point in the code to
 139 jump at. Then the entry of the exception handler would setup the required state
 140 needed to run the code properly.
 141
 142 ## 17:57
 143
 144 For complex methods that are gigantic this might produce some bad code, but the
 145 general Java practice is to make smaller methods rather than gigantic ones.
 146 Most of Foobarniux so far just consists of simple methods except for few
 147 methods that may be quite large since they have not been refactored. I suppose
 148 the first step would be to load all the instructions so that I know what they
 149 are, then assign native operations and registers to them as required.
 150
 151 ## 23:06
 152
 153 Tried to sleep after eating a bunch of food, but really could not before so now
 154 I am more awake again.
 155
 156 ## 23:34
 157
 158 To simplify dynamic recompiler service lookup, I can just have a `foo@arch`
 159 which can simplify things. If one is not found or does not support a config
 160 then it will fallback to another class. This will remove the need of setting
 161 up sub-services and such, which can get bothersome and boilerplated.
 162