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

   1 # 2016/09/18
   2
   3 ## 00:04
   4
   5 API wise, it is very small which means it will be easier to implement. I can
   6 have internally driver sets for it. Also due to the age of OpenGL it is more
   7 targetted for older systems. So I could essentially dynamically load OpenGL
   8 libraries potentially and use those for rendering. I would need to have a
   9 driver interface that the standard code set uses. So I would essentially have
  10 a software rasterizer, but for example on the N64 I can have a driver which
  11 uses that GPU.
  12
  13 ## 00:08
  14
  15 The `sloccount` of the JD disassembled classes (they are virtually all
  16 interfaces and abstract classes) is only 1,273 lines. So the API itself is
  17 very small indeed. However, I may be getting a bit ahead of myself a bit since
  18 I do not even have a fully working compiler yet.
  19
  20 ## 00:12
  21
  22 Since JD's output is rather ugly, I can actually have a doclet which outputs
  23 Java source code. For my previous project (attempted to implement the entire
  24 Java 8 library, about 4000 classes) used something such as this. However that
  25 code is a bit old and rather ugly.
  26
  27
  28 ## 00:17
  29
  30 Register saving is just for the most part allocating some stack area and then
  31 copying the value to that. Essentially, I need a pure stack allocation.
  32
  33 ## 00:27
  34
  35 So the register allocator will need an allocate method which can allocate to
  36 registers, stack, or both.
  37
  38 ## 01:20
  39
  40 `BasicCodeWriter` triggered my code size warning despite it only being about
  41 500 lines long. I suppose I could ignore it however.
  42
  43 ## 08:41
  44
  45 JSR 239 has fixed point support, which means a software rasterizer could
  46 potentially work a bit faster if no floating point is available. However one
  47 thing to consider is the floating point parts. I would suppose that when it
  48 comes to actual rendering, that it would use either floating point or fixed
  49 point but render that data directly. So drawing a triangle using the fixed
  50 point functions will draw it using fixed point, while floating point would
  51 draw it using floating point. Floating point would be far more accurate, but
  52 when it comes to fixed point drawing it would not have to convert to float
  53 or vice versa. Other drivers however might convert float to fixed or vice
  54 versa.
  55
  56 ## 09:40
  57
  58 I rather feel like rewriting the build system to be a bit better. One thing I
  59 need are profiles. Essentially, stuff such as "minimal" and "opengl" which
  60 include packages. These would be included in the build for the target binary
  61 and select which packages are available for usage. I should also simplify the
  62 bootstrap build system and basically just explicitely compile the packages
  63 required to run things. I just need a class loader interface along with a
  64 Java compiler interface also. This way if I write an internal compiler then
  65 I can use that instead. This build system would be fully self contained.
  66
  67 ## 11:20
  68
  69 Ok, so the `Package` classes will turn into `Project` instead. This is so it
  70 does not get confused with Java packages. Following that, I am going to
  71 change `ProjectList` to instead map for `ProjectGroup` which contains binary
  72 and/or source `ProjectInfo`. This way, it is possible for source packages to
  73 be compiled internally and initialized when neeeded. The bootstrap system will
  74 definitely need to perform this task. I thought about having `ProjectInfo`
  75 having a `binary()` and `source()` methods but that would be too complex.
  76
  77 ## 11:51
  78
  79 I believe I need to change my syntax highlighting theme.
  80
  81 ## 12:26
  82
  83 I could remove the commas from the build dependencies to simplify things.
  84
  85 ## 14:17
  86
  87 So the bulk of the bootstrap code, instead of relying on the host VM libraries,
  88 for the most part depends soley on my own code. Since the bootstrap is built
  89 all at once, it is possible to use the bootstrap as a seed of sorts. I could
  90 potentially adjust the script that if no Java compiler is detected in PATH
  91 that it instead runs the bootstrap directly.
  92
  93 ## 14:23
  94
  95 The new bootstrapper should be around half the size of the older build system.
  96 Of course, I have to implement the old build system part into the new bootstrap
  97 system.
  98
  99 ## 15:01
 100
 101 So what I need is a means of getting the binary project of a given project
 102 along with anything that is optional. This means that there is potential to
 103 have co-dependencies which I have previous talked about. However, first I
 104 should re-implement the build stuff that is missing, this way I can resume
 105 working on the cross compiler potentially. Although technically I can use the
 106 old build system to do so. At least with this new build setup the bulk of
 107 the project building will be completely within the scope of SquirrelJME. So
 108 technically if I added a custom launcher (for example an interpreter or
 109 bridge to `launcher`) and a compiler, I would have a completely self contained
 110 system where I can build SquirrelJME on SquirrelJME. Following the build system
 111 reimplementation, I need to adjust the target builder a bit potentially so
 112 that it is possible to give profiles or some kind of configuration-like thing
 113 where I can select projects to use. So a minimal configuration would contain
 114 the bare minimum, while a full configuration would include every package. When
 115 it comes to targets for a given system, say for autobuilds, I would want to
 116 choose the configuration that fits the best. So this means that targets such
 117 as the Nintendo 64 and Sega Dreamcast will get the full configuration meaning
 118 that all projects would be included in the output binary. And as such, they
 119 would be the complete suite. Doing it this way then means that it will not be
 120 needed to have special operating system specific projects which depend on
 121 other projects. So in essence, I would have had a "os-nintendo-n64" which
 122 would depend on stuff such as say the LCDUI code (when it pops around in the
 123 future). With configurations, I would then be able to explicitely specify
 124 which set of default projects to include. Of course for demo purposes I would
 125 want the best choice.
 126
 127 ## 16:25
 128
 129 The dependencies will need to change from being `ProjectInfo` to being
 130 `ProjectName`, because now with binaries and sources it can get a bit
 131 ambigious and confusion.
 132
 133 ## 17:53
 134
 135 I will need a project contents browser. The base browser can be derived from
 136 the bootstrap compiler interfaces, well it is not required. I just need a way
 137 to give the bootstrap compiler source code to compile along with options.
 138
 139 ## 18:42
 140
 141 Now that `BootCompiler` has a method, it fails to find classes.
 142
 143 ## 19:02
 144
 145 So now I am suffering from `ClassLoader` woes. The `ClassLoader` stuff is
 146 near impossible to debug. When it comes to dynamically loading classes and
 147 interfaces via proxies, if they cross `ClassLoader` bounds then things
 148 start to explode.
 149
 150 ## 19:10
 151
 152 Probably one thing to try would be after a build, relaunch with a special
 153 flag so that way I know it is a secondary launch after an initial bootstrap
 154 build. So essentially, run java twice.
 155
 156 ## 19:21
 157
 158 That fails also. So regardless, things are broken with proxies. I suppose the
 159 only thing left would be to have a special project which is not technically
 160 a project but it used by the bootstrap system to bridge. Then I can continue
 161 with the double execute.
 162
 163 ## 19:31
 164
 165 Double JVM invoke has a speed cost, but it works.
 166
 167 ## 19:51
 168
 169 So to recap, I just need to write the compiler and then the launcher.
 170
 171 ## 21:43
 172
 173 So perhaps I need a compiler directory of sorts.
 174