assets/developer-notes/stephanie-gawroriski/2016/09/27.mkd

   1 # 2016/09/27
   2
   3 ## 07:34
   4
   5 So I shall setup the base for a stack frame setup, one that will be easy to
   6 implement and easy to use.
   7
   8 ## 07:42
   9
  10 I can put the stack direction, alignment, and the stack pointers used in the
  11 layout. Basically anything related to the stack would be placed in the layout.
  12 This way, all of that information is together. I suppose initially I should
  13 have it so the code can handle PowerPC's stack frame layout, which has a number
  14 of requirements.
  15
  16 ## 09:44
  17
  18 So hopefully with the creation of the stack frame layout, I can very much more
  19 easily and more simply write the stack frame that is needed. My hope is that
  20 the current `invokeMethod()` method is much smaller. It starts from line 218
  21 and ends at 394 and as such is nearly 100 lines and I would guess that it
  22 would be about 20-40 lines more. However even with only 100 lines it is still
  23 quite complex.
  24
  25 ## 11:18
  26
  27 Ok, so I had an idea. The code decoder stream needs flags. These flags will be
  28 stuff such as `NO_CODE` which disables code parsing and just states that only
  29 the layout of a class is to be parsed. Then another thought I had during my
  30 walk is that I really really like a fixed size stack where I can preallocate
  31 every variable as needed. What I can do with this new flagging system is have
  32 it where I can have a special flag which is used to go through all operations
  33 and then set in a bit field, all types which are assigned to a given location.
  34
  35 ## 11:34
  36
  37 Then this way, I can determine how I want to allocate registers. When it comes
  38 to the stack, I will still need to select premade allocations although I do
  39 not have to worry about frame pointers or setting the stack pointer. Also the
  40 stack pointer can completely act as the base. So this means that the stack
  41 direction needs a `top` which is the opposite of `base`.
  42
  43 ## 17:41
  44
  45 Actually I will do that regardless since it is difficult to forward JIT
  46 specific options currently.
  47
  48 ## 18:27
  49
  50 I am considering making SquirrelJME a kind of hybrid Java/C program where the
  51 C program runs code, but has symbolic access to the byte code (which is
  52 compiled). That is, they can call each other and can execute each other. I
  53 would have to write my own C compiler, because the system one would be unable
  54 to handle access to Java and there would be a great difference in the target
  55 machine. I would want the C part to have the same size types for int and such
  56 regardless of the underlying system. Otherwise, the mass number of defines
  57 would not be maintainable.
  58
  59 ## 18:33
  60
  61 A pure Java approach can work, but everything is a heap reference for the most
  62 part and there would be overhead of some calls for example. However, if the
  63 JIT is written partly in C then I would need a way to execute that C code in a
  64 way where it can be bridged with the JVM. Oracle's Java ME VM is written in C
  65 and is pretty much a pure C program. For hybrid programs, I would still need
  66 to recompile the byte code to native code. However, right now I output to
  67 namespaces which are part of objects.
  68
  69 ## 18:41
  70
  71 However, switching to C would be quite the scope creep. I believe what I need
  72 is to actually splice apart the JIT. Basically there will be _NO_ namespaces
  73 writen by the JIT. There would be a namespace target specific output (say to
  74 ELF or similar) and another which can generate machine code, similar to the
  75 native code generator.
  76
  77 ## 19:15
  78
  79 So basically, the JIT for the class is going to splice the class handler. I
  80 would say it would be split into two parts: `Container` and `NativeCode`.
  81 Since `Container` is already is a class then `Binary` should be used instead.
  82
  83 ## 19:20
  84
  85 Essentially the JIT on top of the class decoder will be split in where it
  86 handles things. There will be a basic output which writes to the container
  87 along with one that is attached to the native machine code generator. So
  88 the machine code generator would be for just generating machine code spit
  89 out by the JIT. Then I can perform a kind of optimization of sorts so that
  90 I can have two different binary containers: one that outputs to a native
  91 binary for usage for system execution (say an ELF with symbols) and another
  92 which is used by the JIT at runtime to execute JIT compiled code. One
  93 would be static while the other would be more dynamic. This would then make
  94 it where outputting to ELF or say PE at a later step is removed and is
  95 handled by the binary container code. This would essentially remove the
  96 link step along with needing a kind of cache for output. Basically it can
  97 write the ELF and such in a single go for the most part. Since it might not
  98 support linear output, I can use `FileChannel` to write ELFs and such and
  99 update it that so that it does not need to store anything in memory. So it
 100 would initialize it with unknowns and write the known information on close.
 101
 102 ## 20:22
 103
 104 So basically this would be a splitting refactor that would remove the need
 105 to have the link stage to ELF and do that output directly, and potentially
 106 having symbols and other linkage information. This should actually make
 107 output generation be simpler and remove the potential need for namespaces.
 108 I just need a kind of descriptor for actually being able to use the
 109 namespaces at runtime. This could actually be separate and I could even
 110 support code and data completely alone.