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:
event-manager: Could be replaced with something better and be implemented when actual UI comes into play.
gc-standard: Rework these interfaces.
interpreter*: Remove these and do not support interpretation at all, interpretation is slow. However for a simulated build environment I could instead use a JIT of perhaps say MIPS or MMIX and then run it in a simulator to act as an interpreter. The hypothetical IDE I have had an idea of could just compile to a specific machine and then run the produced binary in the simulated environment. This could also be used to check for bugs also.
kernel-*: The kernel is somewhat nice with processes and threads, although there are some complex details. What is generally just needed when it comes to the virtual machine is the launcher interface, but a kind of IPC between running sub-VMs. Instead of system specific kernels, the support for a given system can instead be provided by the
os-*packages. Threads and processes would just use differing object spaces within the same process memory space.
MemoryAccessorinterface is nice to have. One thing to consider is that I could move it into
__squirreljmeand make it available and dynamically translated by the JIT. If a constant pointer is read it can potentially translate it directly. A requirement of
__squirreljmewould be that all method calls would be rewritten into other locations. So when it comes to the JIT and OS variants, there could be code that just overrides which method gets executed.
runtime-objects: This would be consolidated to a new object manager and GC in one.
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
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
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.
__squirreljme package is literally just
unsafe stuff, so instead of the
special package I could just place it in