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

   1 # 2016/09/28
   2
   3 ## 07:50
   4
   5 So today will be splitting the code generation portion of the JIT and binary
   6 output portion of the JIT into two separated parts.
   7
   8 ## 09:18
   9
  10 So what could be done is that `ExecutableOutput` can be modified to work in
  11 this new fashion, it would have an ELF output for UNIX-like systems. I can
  12 also do a kind of prelinking step for example. So I can make the core
  13 SquirrelJME binary as static as possible. If everything is prelinked and
  14 ready to go, the only thing that would be needed is to load or access that
  15 portion in memory.
  16
  17 ## 09:30
  18
  19 Ok so, JITConfig could really go into the base of the JIT. The only thing that
  20 would have to be removed from it is the cache of `JITOutputFactory` but the
  21 way the code is, that would be a simple task.
  22
  23 ## 09:49
  24
  25 So my goal would be so that the executable output is handled by the JIT
  26 itself. This means _jit_ depends on _exe_ (where _exe_ depends on _jit-base_).
  27 The EXE would be given the `JITConfig` so it knows how to work with it. There
  28 would be factories for specific formats. So the config would get the factory
  29 class which the JIT will use as a binary container. Then the existing basic
  30 code generating work will be spliced off. So `jit-basic` does not care much
  31 about the layout of namespaces or the constant pool, it will just handle the
  32 native code portion. Then this way, the actual code generator code will be
  33 far simpler with namespaces split off. It would more easily be reused.
  34
  35 ## 10:27
  36
  37 I should rename `ExecutableOutput` so I can claim its class name.
  38
  39 ## 10:33
  40
  41 So this means that for the namespace processor, it will need an executable
  42 output. There would have to be two kinds of things, a major output namespace
  43 and a minor one. The major one would construct the executable early while
  44 the minor one would create it later. This way it can output all namespaces
  45 to a single binary or multiple ones, depending on the situation.
  46
  47 ## 11:26
  48
  49 Ok, so I thought about it. I will not do it at the _jit_ level but at the
  50 level of _jit-basic_. If I have a language target then it would be a bit
  51 pointless to have an executable ouput. So for traditional CPU targets
  52 _jit-basic_ handles it.
  53
  54 ## 11:29
  55
  56 Also thought about merging `JIT` into `JITNamespaceProcessor` since it would
  57 make much more sense there for the most part.
  58
  59 ## 11:45
  60
  61 Since I plan for shared executables, `JITOutput` can now be closed along with
  62 the namespace processor. This way any final things can be managed as needed.
  63
  64 ## 12:07
  65
  66 I would say that `JITNamespaceBrowser` loses output and it is instead placed
  67 in another interface.
  68
  69 ## 12:12
  70
  71 Actually since I made a new class called `JITNamespaceOutputSingle` I can
  72 remove the key for shared output and imply it based on the namespace
  73 processor.
  74
  75 ## 12:50
  76
  77 Since I am going to output the distribution ZIP directly, I actually need to
  78 use a temporary output ZIP file, which I then move over.
  79
  80 ## 15:08
  81
  82 So in reality I do not even need an executable or a linking step if it not
  83 needed for the native target. So this in general makes it much better than
  84 before.
  85
  86 ## 21:46
  87
  88 Actually, I could keep `ELFOutput` since I already have all of it. I can
  89 undeprecate it then move the JIT part of it to `jit-basic-elf`.
  90
  91 ## 21:48
  92
  93 Well actually, the executable output system is tied to the JIT for the most
  94 part. So for simplicity, I will just move the bulk of the code over.
  95 However for ELFs I will need three sections for the most part which would
  96 be referenced in memory. I would guess that the output support internal
  97 relocations where pointers are set on write for the most part. But the
  98 major thing I need to do is reorganization of the code generation. I still
  99 do have to handle the call stack management however.
 100
 101 ## 21:55
 102
 103 The initial things that would need to be modified would be mostly the
 104 `BasicNamespaceWriter`. If the executable output can handle multiple streams
 105 then I can have data and other such things in their own self contained
 106 locations.
 107
 108 ## 22:00
 109
 110 So the generic executable output interface would have the ability to create
 111 new output sections regardless of the output type. Then one thing I should
 112 do for the ELF code is decouple the part used by the JIT and the underlying
 113 ELF code. This way, the sections and such can more freely changed without
 114 being tied to a single class. The structures and such would mostly be the
 115 same for the most part and the executable output wrapper would handle such
 116 things. Then when it comes to machine code generation, it will write to
 117 another stream but be mostly based on the native code writer. However they
 118 both would be standalone so that there would be no intermixing of them. So
 119 the code description stream should purely operate for the most part via the
 120 native code writer. One consideration I have been thinking of is call stack
 121 setup. I am very much thinking of preallocated variable slot data. However
 122 that could potentially waste space. So I suppose what can be done for the
 123 code writer output would be the ability to have future data be able to be
 124 set. Then the code writer can eventually be output to a byte array or some
 125 type of stream. If I allow this rather than having a direct code output then
 126 I can allocate on the stack as I need from the base of it or similar (perhaps
 127 via the frame pointer). This future referencing of data would reduce some of
 128 the complexity required during code generation. So then this way, all
 129 management of the stack is seemingly static in the output code. For the most
 130 part generated methods would be small in size, so the instructions for the
 131 entire method would not have a high cost on memory usage.