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.
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
ProjectList to instead map for
ProjectGroup which contains binary
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
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
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.
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.