assets/developer-notes/stephanie-gawroriski/2016/07/22.mkd

   1 # 2016/07/22
   2
   3 ## 07:37
   4
   5 Need to include some more class details.
   6
   7 ## 08:05
   8
   9 When it comes to methods and fields, I should have precomposed descriptors for
  10 them so that they do not need to be parsed at the start. However for the C code
  11 and simplicity I will do that in C code.
  12
  13 ## 08:08
  14
  15 That is pretty much it, there are just fields and methods. The main work will
  16 be going through the byte code. However once that is done I would have to
  17 delve into the initialization and then the class library. My first goal would
  18 be to write a simple string print.
  19
  20 ## 10:56
  21
  22 I will need to implement virtual dispatching in C. So I would suppose that
  23 I would need a table associated with a VM for a given class. Actually thinking
  24 about it, if I target Java instead of C I would not need to worry about using
  25 extern or having potentially incompatible C and JVM execution. The end result
  26 would be pretty much the same. An issue with Java however would be the lack of
  27 pointers, although that is not really important. If I target Java ME (which I
  28 should) I could have a virtualized environment that could be built on J2ME
  29 devices. One thing though, is still virtual dispatch. Personally being able to
  30 compile to Java and build a J2ME program would be more valuable to me. if I
  31 target older virtual machines, that could form the basis for a kind of
  32 bootstrap project. Then with a compiler, I can run and test SquirrelJME on
  33 much older systems that do not support Java 7. With Java at least, namespaces
  34 can be stored in packages instead of being prefixed to the name. One issue
  35 though would be classes, although they would be static there would just be
  36 direct class references in a global namespace class so to speak. Resources
  37 could be included there also. Since Java ME lacks reflection (apart from
  38 finding classes), this means that all class objects when they are used have to
  39 be initialized (using `newInstance()`). A class would have actual methods,
  40 input arguments (as boxed classes). For a given virtual machine, the call stack
  41 and other such things need to be kept for the GC. So I would need an efficient
  42 means of storing this information that tries as much as possible to avoid
  43 allocating Objects. I could have an int tread and an Object tread, when a long,
  44 float, or double are read those can be handled using wrappers and such.
  45
  46 ## 11:09
  47
  48 Since byte code can jump around in some places, I will need a means of jumping
  49 to other portions of the code without requiring such things.
  50
  51 ## 11:11
  52
  53 Although in the end it might not matter as much.
  54
  55 ## 14:22
  56
  57 Ok, so this is not going to work. There are targets which do not support the
  58 JIT, so having the JIT code included in them would be rather pointless. Also as
  59 a note, the `linkBinary` needs to be given system properties which are `final`
  60 in the linked binary (cannot be replaced) and are global. These would specify
  61 the class which contains the JIT, the target, and a few other properties (such
  62 as the build date). `Builder` needs an option called `-jit` which can specify
  63 an alternative class to use for the JIT or specify `none` for no JIT. Packages
  64 for an operating system, cannot depend on the JIT. They just get an optional
  65 dependency on a JIT. The `jit` gets split into `jit` and `jit-base` (where
  66 `jit` depends on `jit-base`. The base project just contains the triplet and a
  67 few other simple things. Then CPU specific targets will be prefixed with
  68 `jit-cpu-`. `os` will remain the same. Each `os` package would have a new
  69 manifest field which specifies the package which contains the JIT. Then the
  70 architecture specific JIT package defines the classes which implement a JIT to
  71 be used. If a JIT is not to be included, then the target binary would not
  72 compile the JIT code.
  73
  74 ## 14:28
  75
  76 Another issue would be native executable output, I want architecture
  77 independent code. So basically, I create a new `exe` class which can output for
  78 a given binary type (such as ELF) then include some bootstrap code. Then to
  79 make it where the OS code is lighter, place the bootstrap code in another
  80 package and make it accessible via `getResourceAsStream()` on a class in the
  81 package. To reduce duplication everywhere, the ELF linker can be very generic.
  82 Then this way, the extra files which are used in the output do not have to
  83 needlessly be included in the namespace.
  84
  85 ## 15:13
  86
  87 I can also just remove the C based JIT output. Instead I can have a generic
  88 JIT serialization which could be used by an interpreter.
  89
  90 ## 15:28
  91
  92 The builder also needs a way to list all of the available systems, variants,
  93 and other such things. Since all stuff is included optionally that can simply
  94 be done by scanning the package list and then calling the JITs and output
  95 supports. So on that note, `os-` only contains operating system support. There
  96 may optionally be a JIT bound to the operating system (via `jit-base`). Then
  97 for SquirrelJME specific output, there would be `builder-os-arch` essentially
  98 (which would be optional dependencies also). Then this way, there would be no
  99 code at all that knows about linking the `os-` or the CPU JITs.
 100
 101 ## 15:35
 102
 103 Then the way to invoke the emulator can be used with the builder support also.
 104
 105 ## 15:36
 106
 107 Also, I suppose I will remove the PowerPC and Linux related stuff, none of
 108 that code exists yet and will just get in the way for the most part.
 109
 110 ## 17:15
 111
 112 Actually, I do not need to scan the package list because the target builders
 113 can just suggest prefixes to try.
 114
 115 ## 18:46
 116
 117 Initially it would be best to not compile any tests so it completes as fast as
 118 possible.
 119
 120 ## 18:47
 121
 122 I suppose following getting the projects to build would be getting the
 123 `JITOutputFactory` and such. However, at least now with the new builder setup
 124 it can be kept out of the way. So I essentially do not even have to build and
 125 compile the JIT itself. So this means faster generation. For sanity though,
 126 there will have to be an encodable JIT configuration which is used in a
 127 system property of sorts. I would like the actual JITs to have no operating
 128 system specific parts to them (which is easier with the current way of things).
 129 As such, an operating system builder will have to generate a `JITOutputConfig`
 130 that is to be used.
 131
 132 ## 18:56
 133
 134 This also means that the JIT does not need `linkBinary` as that is an artifact
 135 of the builder itself. So this in essence simplifies the JIT and reduces
 136 useless code bloat because that method will only ever be called by the builder.
 137
 138 ## 19:42
 139
 140 This new code is far better than the old code. I just need to get back into the
 141 namespace writer. Before it was just output to the cache stream, I could just
 142 do that again for the most part.
 143
 144 ## 22:23
 145
 146 For the resource writer, I need to remove the `OutputStream` and instead use
 147 another interface which does the same thing. This way JITs can have base
 148 classes for output, which would be reasonable.
 149
 150 ## 22:56
 151
 152 So reaching where I previously was (in the C code) should be quite simple. Also
 153 the new classes for writing are much cleaner. At least for the interpreter I
 154 do not need to worry about potential forward declaration due to late binding
 155 poentially being used. Namespace initialization would likely be in the order
 156 of last to first. At least when it comes to the interpreter, the emulator can
 157 handle everything. Then once I have enough to print a message, I will make a
 158 video and post it.
 159