assets/developer-notes/stephanie-gawroriski/2017/01/28.mkd

   1 # 2017/01/28
   2
   3 ## 13:45
   4
   5 Thinking about it, the JIT code is essentially sort of a duplicated interface.
   6 Perhaps what I can do is move the byte code handling part of it to the class
   7 format. Then the JIT itself will just become some helpers and a bridge of
   8 sorts. Because right now, the JIT class output interfaces are just duplicated.
   9 This means that I should refactor up the class format code and the JIT code
  10 at the same time to simplify things. The class format dedcoder code is a bit
  11 ugly I believe in some areas.
  12
  13 ## 13:48
  14
  15 Well, the class format code just spits out the code stream as normal and
  16 does not do any stack caching on it. The stack caching part can just be a
  17 normal part of the JIT, with jump targets as barriers as before. So this means
  18 getting rid of all of the `JITBoopWriter` interfaces which are closeable, but
  19 pretty much mark the end of something. So what I can do is make the
  20 description streams all closeable but remove the exception.
  21
  22 ## 13:53
  23
  24 Then some classes such as `AccessibleFlags` can be split off because they will
  25 be needed by the Kernel's context initializer to link classes together and
  26 such.
  27
  28 ## 13:54
  29
  30 One other thing that I thought about was porting SquirrelJME to systems such
  31 as turing complete machines (like the turing tape), but that would be very
  32 complex. Pretty much every modern computer architecture is the same. So I
  33 suppose for simplicity that I will only target these kinds of systems. The
  34 good thing is that this means I do not need to have the JIT split apart now
  35 because the machine area writers and such can be in a single place. So I can
  36 effectively take care of every architecture. I just need to take into
  37 consideration cases where variables are too big to fit into the system's
  38 native registers. However one way to handle that is to exploit the carry
  39 flag. It will not be as optimized, but it should work. But one thing I can
  40 do in the design is have it where values are limited so to speak. But not
  41 every case would be optimized. So SquirrelJME running on 16-bit CPUs will be
  42 a bit more bloated and slower due to more operations. Java integers are
  43 32-bit in size and in many cases, there is no way to tell how big an input
  44 value is on argument passing or return. Maybe there is some kind of method
  45 where I can condense all those operations together. Or maybe instead of
  46 generating all the instructions most of the time, the 32-bit add is in a
  47 microfunction of sorts, although that would have lots of overhead but it
  48 would decrease the code size.
  49
  50 ## 14:03
  51
  52 So the `AccessibleFlags` and such can go into `Executable`. Executable will
  53 need to contain methods to return access flags and such for methods. Even
  54 when no JIT is compiled into SquirrelJME, this will still need to be known
  55 because suites can be linked as needed for running programs into contexts.
  56
  57 ## 14:19
  58
  59 Actually, all of the flags and the linkage stuff could be moved into a linkage
  60 project. Since those are generally the same. This would mean that there are
  61 less classes in the class format. But also that the class format decoder
  62 does not have to depend on the executable project.
  63
  64 ## 14:50
  65
  66 So `squirreljme-jit-basic` is now going to be folded into the standard JIT for
  67 the most part. Then the JIT is going to have less dynamic things, no
  68 configurations for the most part. Anything that is machine specific will be
  69 handled by classes on JIT initialization. Then those can handle configurations
  70 as needed, for example for specific CPUs.