The configuration would best be immutable for the most part. This way it could more easily be used when threads and such need to be created.


However, perhaps just an immutable class that can be initialized.


For a mutable variant I can just use a kind of builder.


I need better names for the CPUs in the builder. I will go with the planned variants.


So when it comes to building, I need a JIT that could cache and provide native executable code fragments for classes and such.


I believe the simulator with multiple simulations, groups, and otherwise would be a bit complex. I will just have a single simulation process that runs and executes until it completes.


So is the JIT on a per class basis or a per method basis? Classes are together in a group, so it would likely be better optimized to compile classes all at the same time.


A configuration system for configuring builds would be the best rather than just a CPU and OS target.


I would suppose that I have base OS support and then a front end that could work on the OS to provide an interface for the user. The front end could vary for a system and provide alternative control and featuresets.


The manifest code needs a new exception.


The package code should be placed in another location for the most part. Then thinking about it, I can adjust the build system (Build.java) so that it uses the package code rather than duplicating it and such.


Thinking about it, I suppose operating system support should be a part of the JIT. However generally not. The JIT will need to translate special method calls into some other form. Calling the special magical methods could just be transformed to a call to another class. However the ABI for the OS must be matched, otherwise using native debuggers would be much more difficult. So in generally, I suppose a class which is needed would be a system description class. However it needs to be able to support multiple architectures and such also. However, when it comes to the classes it could be automatic somewhat.


One thing though is that I will need to support variants which could overload pre-existing definitions. Basically these would be front ends and backends. Perhaps multiple backends could be supported at once, but that would be complex. Thinking about new code layout, I may want to remove the following projects:


So I suppose when it comes to the JIT, I just do a straight translation and in general just replace magical calls as required. I can have a common register availability class that the JIT uses and such.


So the JIT needs a JITCPUProvider which provides support for generating code for a given CPU.


As for the internal __squirreljme magic, the kernel can translate magical calls while the JIT which would run on the target would not translate them (so that they throw exceptions). All programs would source their classes from the built-in class path anyway.


I suppose there would be multiple support layers the build system would use to determine how to target a given system. jit-powerpc would be the basic PowerPC support while jit-powerpc-linux would be the variant that works on Linux. Then the os-* packages would just contain operating system support code such as file system accesses and system calls. There would also need to be architecture specific operating system information. So I would also need a os-linux-powerpc. So jit-powerpc-linux would help indicate code that is friendly to the Linux OS while os-linux-powerpc would contain the architecture specific Linux support code. I suppose when it comes to the run-time there is a base abstract class which is primitive OS handling and interfaces, abstract where appropriate. Although this would likely best be in __squirreljme. It could work at this position. I can use faked global init of sorts.


Basically there will be an abstract class which has a static instance which allows the standard run-time to communicate with the OS as required. Then the target system's initialization will magically set the value of a static field so that the interface is initialized and useable. That way, any calls made into the singleton will instead go to the operating system specific support library.


The __squirreljme package is literally just unsafe stuff, so instead of the special package I could just place it in net.multiphasicapps.squirreljme.unsafe.