assets/developer-notes/stephanie-gawroriski/2017/05/29.mkd

   1 # 2017/05/29
   2
   3 ## 10:57
   4
   5 Ok so, the actual key code could have the processing information which
   6 generates instructions needed for the target. So for example one which
   7 uses byte code instructions would read the byte code and handle those
   8 things as such and place them into basic blocks. A zone key which uses the
   9 exception table would generate instructions using another means.
  10
  11 ## 10:58
  12
  13 This means that zone keys are comparable to each other too.
  14
  15 ## 14:12
  16
  17 Thinking about it, I likely do not even need `BasicBlockStateMap` because
  18 the zone and entry state could be represented by a single object.
  19
  20 ## 14:14
  21
  22 But it would probably be easier to use it if the state maps were not a map
  23 and it was just in the program state because then that means there is just
  24 a reference to a single class: `ProgramState`.
  25
  26 ## 14:15
  27
  28 But this would mean that there would be zones which are not known about
  29 potentially and then there might not be easure.
  30
  31 ## 14:16
  32
  33 However, there would be a `jumpTo(ZoneKey, ImmutableVariableState)` method
  34 which creates and returns a basic block to be queued. However, in reality the
  35 basic blocks could be mostly immutable. The queue would operate with block
  36 keys which have a zone key and an immutable variable state. Rather than
  37 operating purely in basic blocks.
  38
  39 ## 14:20
  40
  41 The JIT is a really large package and I believe combining everything into a
  42 single package is a bit messy. Not everything needs to be directly connected
  43 to each other.
  44
  45 ## 14:26
  46
  47 I could also probably make it so the information in a method is contained
  48 within a single class, perhaps `ByteCode` rather than having a large number of
  49 classes for having the raw method code and other such things.
  50
  51 ## 14:36
  52
  53 Also thinking about it, the exported symbols and such might not need that
  54 strong handling they currently have at run-time. At run-time the linker really
  55 only needs class names, field name/type, and method name/type. So the
  56 `linkage` could very potentially be folded down into a much simpler form that
  57 has less information contained within it. The same could be said for method
  58 and field references too.
  59
  60 ## 14:49
  61
  62 The regions of the program could be within `ByteCode` instead instead of
  63 having the code zones and such. I could also move the instruction out of
  64 `ByteCode` into its own class and use private means of accessing parts of the
  65 method.
  66
  67 ## 14:58
  68
  69 `NativeType` and `Allocation` could be changed somewhat. Potentially even
  70 combined into one. For example some 8-bit targets or strange targets might
  71 have a clear mapping of how things are represented. For example, pointers to
  72 other regions of memory might not have a clear cut representation. So for
  73 example on the 286, pointers could be 24-bit in that they use a segment
  74 along and a 16-bit memory address. So they cannot really be represented using
  75 a single integer variable to be added and subtracted from normally. So I need
  76 a unique pointer native type. Also another example could be that some targets
  77 might not support registers containing shorter or longer values, just a
  78 fixed size. Since I definitely do plan to now target the ZX Spectrum Next
  79 which uses a Z80 I am going to need special pointers to refer to different
  80 banks of memory. So this plain treating pointers as integers would be really
  81 messy for these targets. I also do plan to support many wide targets so I
  82 would essentially have to rework everything just to handle pointers.
  83
  84 ## 15:03
  85
  86 So basically there would be a "give me a native type which can store the
  87 specified type" and force objects to be pointers essentially.
  88
  89 ## 15:06
  90
  91 The classes do need flags however such as for interfaces, if they are final,
  92 and a few other things. That is needed for linking. Members also need those
  93 too, so there is probably not much I can do at all. However what I could do
  94 is remove a bunch of the preloaded constants and make them not exist at all.
  95 They really have no reason to exist and were just for making less objects
  96 visible. Also that information is only needed during class recompilation
  97 and runtime linking. However, this is only needed if there is an actual JIT
  98 because otherwise for targets without a JIT, everything is already prelinked
  99 into a single executable where nothing has to actually be checked. So this
 100 means that the symbols go out of the symbol package and instead go straight
 101 into the JIT where they can be molded to be simplified. So anything
 102 related to linking will require the JIT.
 103
 104 ## 15:19
 105
 106 So yeah, `ByteCode` is going to get the regions and such instead of the
 107 native generator part of it.
 108
 109 ## 16:46
 110
 111 It would very likely be far easier to create a new JIT project and move all
 112 the old code into that rather than trying to fix up pre-existing JIT with
 113 all of its old code.
 114
 115 ## 16:51
 116
 117 `ExecutableClass` could probably be removed or changed a bit. At least
 118 initially the interpreter could be ran as if there were no JIT installed at
 119 all, so it is really an interpreter for things.
 120
 121 ## 16:56
 122
 123 So there really is just a pointer for the most part, then classes could
 124 potentially be installed to be executable and such.
 125
 126 ## 16:58
 127
 128 So register dictionaries could be forked into two specific things, a fixed
 129 set of registers or a dynamically generated unlimited set of registers. Both
 130 could be used in many cases.
 131
 132 ## 17:02
 133
 134 Instead of saved/temporary requiring to be requested that can be used in the
 135 register itself and associated with it. That is there is no
 136 `isRegisterTemporary()`, it is just `Register.isTemporary()`. Any and all
 137 registers have to be saved before method calls so the condition for argument
 138 registers could be avoided for example. However, alternatively there could be
 139 a mapping for which registers are available. Would have to think about this.
 140 There is stack caching, but it might not fully matter where registers are.
 141
 142 ## 17:06
 143
 144 In reality though, the register handling could be done by the target specific
 145 JITs rather than the JIT itself. Basically there would be an allocation
 146 mutator which changes state according to the registers available and such. So
 147 this would mean that the `VariableState` and such is linked to this class.
 148 But with an infinite set of registers for some targets, all would have to be
 149 pushed to the queue for it to wait on registers for usage.
 150
 151 ## 17:08
 152
 153 One thing though is that I seem to be going in circles finding the best
 154 solution to things. It has been a year of me writing the JIT over and over
 155 again to find something that works. Compilers are really messy, but the more I
 156 do it the more I learn.
 157
 158 ## 17:09
 159
 160 Ok so if having a register dictionary does not work for a target and there be
 161 a variable state kind of thing in the native code, then I would say that it is
 162 similar to a dictionary but it pulls registers for usage.
 163
 164 ## 17:24
 165
 166 I can however have a combined linking stage. My previous plan when creating
 167 combined executables would be to perform the linking step after all the
 168 individual binaries have been compiled. However one thing I can do is do
 169 something similar to what I have before and just have a single export/import
 170 table which the JIT will place things into. Basically there would be imports,
 171 exports, and it will maintain a list of unresolved imports. When an import
 172 is resolved it will not be in the unresolved list and will have a direct link
 173 to the export. This would work for the kernel itself and any built-in classes.
 174 Dynamically loading in new JARs would have to be done similarly, but the
 175 dynamically loaded classes would require the JIT itself. However one thing
 176 that changes in this case is the fact that some JARs could depend on a
 177 separate group of classes under the same name. Basically, there is a
 178 separation which could allow different versions of the same class to exist at
 179 any one time.
 180
 181 ## 17:30
 182
 183 So the question is, can multiple versions of the same MIDlet exist at the same
 184 time? But, one consideration here is that right now I am talking about the
 185 kernel, in virtually every case there will only be a single version of any
 186 MIDlet installed. So effectively this is a non-problem. In the future when
 187 dynamically loading and linking JARs are supported, it could perform a similar
 188 means of having a duplicated link table that links into the kernel. Basically
 189 JIT the entire class, then for any unresolved imports just pull from the
 190 kernel. But the thing is, all classes pull from the kernel first when it comes
 191 to importing. So for system classes there can never be duplicate ones or
 192 JARs with different versions anyway. So this issue does not exist at all. So
 193 this means that the JIT has a global link table which is compiled into.
 194
 195 ## 17:47
 196
 197 So this means that the interpreter changes to instead of loading and
 198 interpreting a single class at a time, it changes to instead be a compile
 199 of everything and then just running that thing. So I would say that the
 200 interpreter in this case just runs a single JAR under the interpreter
 201 potentially of course with modified runtime stuff as needed. Since the
 202 kernel and whatever is running will be prelinked.
 203
 204 ## 17:50
 205
 206 So in this case, do I get rid of the interpreter and just have a native
 207 executable that is output? This would be similar to how I have done it
 208 in the past. This would handle the single link table, although testing the
 209 generation of code would be done after everything is compiled and linked
 210 together. I can remove the interpreter and instead of a very direct route
 211 to how code is ran. So basically I inspect the output machine code to make
 212 sure it is working. I for now drop the interpreter and treat the system and
 213 the JIT as if it were a one-shot output and link system.
 214
 215 ## 18:00
 216
 217 You know, I am on PowerPC but my initial target is MIPS. I can run both
 218 natively (well the MIPS on other hardware), but PowerPC is the hardware I run.
 219 So I think I could implement a JIT which targets PowerPC first that way I
 220 can run it on my native Linux PowerPC system.
 221
 222 ## 18:08
 223
 224 I could write something which runs directly on IEEE1275 which is bare metal on
 225 PowerMacs. It is really limited but I could use it as a base system where I
 226 can have a very close to the metal environment running. It would require a bit
 227 more work because there is no real file system (well there is one but it is
 228 read-only). But I think it would be best to get a Linux target working first.
 229
 230 ## 18:21
 231
 232 But MIPS is the simplest.
 233
 234 ## 18:45
 235
 236 Thinking about it, having the kernel just be a normal program works.
 237 For example it is possible for projects to be compiled and executed directly
 238 but I think I would want the kernel environment rather than something else.