SquirrelJME/SquirrelJME

# 2016/06/15

## 07:48

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.

## 07:50

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

## 07:55

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

## 08:22

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

## 08:39

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

## 08:43

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.

## 08:45

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.

## 09:55

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

## 10:04

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.

## 17:56

The manifest code needs a new exception.

## 18:05

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.

## 20:27

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.

## 20:32

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`, `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.
 * `mmu-*`: The `MemoryAccessor` interface is nice to have. One thing to
   consider is that I could move it into `__squirreljme` and make it available
   and dynamically translated by the JIT. If a constant pointer is read it can
   potentially translate it directly. A requirement of `__squirreljme` would
   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.

## 20:42

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.

## 20:45

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

## 20:47

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.

## 20:55

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.

## 20:59

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.

## 21:04

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