API wise, it is very small which means it will be easier to implement. I can have internally driver sets for it. Also due to the age of OpenGL it is more targetted for older systems. So I could essentially dynamically load OpenGL libraries potentially and use those for rendering. I would need to have a driver interface that the standard code set uses. So I would essentially have a software rasterizer, but for example on the N64 I can have a driver which uses that GPU.


The sloccount of the JD disassembled classes (they are virtually all interfaces and abstract classes) is only 1,273 lines. So the API itself is very small indeed. However, I may be getting a bit ahead of myself a bit since I do not even have a fully working compiler yet.


Since JD's output is rather ugly, I can actually have a doclet which outputs Java source code. For my previous project (attempted to implement the entire Java 8 library, about 4000 classes) used something such as this. However that code is a bit old and rather ugly.


Register saving is just for the most part allocating some stack area and then copying the value to that. Essentially, I need a pure stack allocation.


So the register allocator will need an allocate method which can allocate to registers, stack, or both.


BasicCodeWriter triggered my code size warning despite it only being about 500 lines long. I suppose I could ignore it however.


JSR 239 has fixed point support, which means a software rasterizer could potentially work a bit faster if no floating point is available. However one thing to consider is the floating point parts. I would suppose that when it comes to actual rendering, that it would use either floating point or fixed point but render that data directly. So drawing a triangle using the fixed point functions will draw it using fixed point, while floating point would draw it using floating point. Floating point would be far more accurate, but when it comes to fixed point drawing it would not have to convert to float or vice versa. Other drivers however might convert float to fixed or vice versa.


I rather feel like rewriting the build system to be a bit better. One thing I need are profiles. Essentially, stuff such as "minimal" and "opengl" which include packages. These would be included in the build for the target binary and select which packages are available for usage. I should also simplify the bootstrap build system and basically just explicitely compile the packages required to run things. I just need a class loader interface along with a Java compiler interface also. This way if I write an internal compiler then I can use that instead. This build system would be fully self contained.


Ok, so the Package classes will turn into Project instead. This is so it does not get confused with Java packages. Following that, I am going to change ProjectList to instead map for ProjectGroup which contains binary and/or source ProjectInfo. This way, it is possible for source packages to be compiled internally and initialized when neeeded. The bootstrap system will definitely need to perform this task. I thought about having ProjectInfo having a binary() and source() methods but that would be too complex.


I believe I need to change my syntax highlighting theme.


I could remove the commas from the build dependencies to simplify things.


So the bulk of the bootstrap code, instead of relying on the host VM libraries, for the most part depends soley on my own code. Since the bootstrap is built all at once, it is possible to use the bootstrap as a seed of sorts. I could potentially adjust the script that if no Java compiler is detected in PATH that it instead runs the bootstrap directly.


The new bootstrapper should be around half the size of the older build system. Of course, I have to implement the old build system part into the new bootstrap system.


So what I need is a means of getting the binary project of a given project along with anything that is optional. This means that there is potential to have co-dependencies which I have previous talked about. However, first I should re-implement the build stuff that is missing, this way I can resume working on the cross compiler potentially. Although technically I can use the old build system to do so. At least with this new build setup the bulk of the project building will be completely within the scope of SquirrelJME. So technically if I added a custom launcher (for example an interpreter or bridge to launcher) and a compiler, I would have a completely self contained system where I can build SquirrelJME on SquirrelJME. Following the build system reimplementation, I need to adjust the target builder a bit potentially so that it is possible to give profiles or some kind of configuration-like thing where I can select projects to use. So a minimal configuration would contain the bare minimum, while a full configuration would include every package. When it comes to targets for a given system, say for autobuilds, I would want to choose the configuration that fits the best. So this means that targets such as the Nintendo 64 and Sega Dreamcast will get the full configuration meaning that all projects would be included in the output binary. And as such, they would be the complete suite. Doing it this way then means that it will not be needed to have special operating system specific projects which depend on other projects. So in essence, I would have had a "os-nintendo-n64" which would depend on stuff such as say the LCDUI code (when it pops around in the future). With configurations, I would then be able to explicitely specify which set of default projects to include. Of course for demo purposes I would want the best choice.


The dependencies will need to change from being ProjectInfo to being ProjectName, because now with binaries and sources it can get a bit ambigious and confusion.


I will need a project contents browser. The base browser can be derived from the bootstrap compiler interfaces, well it is not required. I just need a way to give the bootstrap compiler source code to compile along with options.


Now that BootCompiler has a method, it fails to find classes.


So now I am suffering from ClassLoader woes. The ClassLoader stuff is near impossible to debug. When it comes to dynamically loading classes and interfaces via proxies, if they cross ClassLoader bounds then things start to explode.


Probably one thing to try would be after a build, relaunch with a special flag so that way I know it is a secondary launch after an initial bootstrap build. So essentially, run java twice.


That fails also. So regardless, things are broken with proxies. I suppose the only thing left would be to have a special project which is not technically a project but it used by the bootstrap system to bridge. Then I can continue with the double execute.


Double JVM invoke has a speed cost, but it works.


So to recap, I just need to write the compiler and then the launcher.


So perhaps I need a compiler directory of sorts.