Indentations break the feed.

[SquirrelJME.git] / assets / developer-notes / stephanie-gawroriski / 2016 / 09 / 02.mkd

# 2016/09/02

## 07:52

Thinking about it, I only need to setup registers via the allocator for
input arguments and such when they are primed. I also need to consider the
stack. I do wonder though if I need a sub-variant of the OS to choose the
calling convention. Such as instead of generic I have eabi or o32. These would
just be generic targets for the most part. When it comes to a specific
system such as the CI40 or GCW it can use the appropriate ABI as such. So
instead of say `linux.generic`, for MIPS there will be `linux.eabi` for
selecting the EABI calling convention.

## 10:15

Thinking about it, adding support for new systems is currently complex
because there needs to be all these classes and packages declared across
a large range of areas. Adding base PowerPC projects adds another 6 projects.
Essentially with my given goal of literally being write once and run anywhere,
there will quite literally be perhaps 1000 projects. This would be an
unmaintainable mess. Many systems share the same thing, but just have a few
differences such as the ABI that is used and how the target is built. There
are also emulator considerations also. Right now the emulator for one is
split across many packages for each CPU and such.

## 10:23

What I propose then is merging all of the architectures and variants of a
given OS and just put it into a single package. So that `builder-linux` handles
every Linux system and all of its variants. Also the `TargetBuilder` as it
stands is a bit ugly and will not work as much either. That has to be adjusted
a bit for it to work. But merging the emulator into a single set would be a
good choice because it would all be compacted into a single place. Although
not as modular, it can essentially be a multi-system emulator so to speak. The
purpose of the emulator is to just test targets for the most part.

## 10:38

I also am a bit distracted, I should be implementing the emulators first before
I target a given system, so I can work out how it works and such. The emulators
do not need to be very complex. However, since emulation is part of the core of
target system building, I should refactor the target build system. I am
thinking of a just essentially an enter build. Say the user requests a given
triplet, it will go through all services and try building one that works. I
can have a special exception indicating that the given target is not supported
for the given builder. I thought about removing the OS variants, but that would
be needed in cases where the operating system calls differ for the same target
(such as MIPS o32 and n32 for example).

## 11:24

So as it stands right now, `TargetBuilder` is essentially a factory and its
methods are called as if they were static. This needs to change because it is
very ugly and complicates things.

## 11:27

One thing I can do is move the "can it JIT?" to the build instance instead
of having it in `TargetBuilder`, because it may be possible for the same OS
which has a variant which does not support a JIT (perhaps a ROM based Linux
system that will never run JARs).

## 11:34

`BuildConfig` should get `PackageList` so the build instance can pluck any
packages that are needed.

## 12:34

However, I would have to do some adjusting for that, eventually.

## 13:18

My new main looks much nicer.

## 14:22

I do like how this code is turning out.

## 14:36

Had an idea for the registers. Right now they are associated with and they
return stuff such as floating point. I was thinking of having some kind of
register association kind of setup. One that is set by the API completely
instead of one set by the registers. Then this way I can have cases where I
have 32-bit integer registers and 64-bit floating point ones, and vice
versa.

## 14:38

I do wonder though if I could actually remove `JITOutputFactory` now and just
use the output classes directly.

## 14:44

It is a bad idea and there is no reason for `MIPSABI` to cache the ABI anymore.

## 14:47

So specifying the registers sizes in the ABI should work much better. There
can also be a means of specifying which registers actually exist for a given
ABI also. So for example on PowerPC with a G4, there will be AltiVec registers
and those can be added, while on older CPUs such as the G3 they cannot be
valid. The same thing happens with MIPS because newer revisions have removed
the `LO` and `HI` registers (used for division). So in short, having the types
associated with `GenericRegister` would be a bad idea. I plan instead to just
have it where it can be a `GenericABI.getRegisterIntType()` kind of thing.

## 16:05

So currently, the soft, hard, and anything in between stuff is rather bad.
There are CPUs such as MIPS ones where there can be no FPU, or the FPU can be
32-bit on a 64-bit system or 64-bit on a 32-bit system. The floats do not have
to even match at all. So I believe I will change this to:

 * soft
 * hard32
 * hard64

Software will be purely in software, while hard32 will do `float` in hardware
and `double` in software. The last `hard64` can do both kinds of floats no
problem.

## 17:18

So I did much refactoring today, although still not yet done.

## 17:28

So now I just have to move over the code that exists in `NewBuilder` and
refactor that into the new `BuildInstance` code.

## 18:11

I am going to want to hide all of the internal builder stuff which should not
be exposed at all.

## 18:12

So the next thing to do would be to setup the `JITOutputConfig` from the
input. That can be handled by a method for the most part. Soon I would have
worked on SquirrelJME for 10 hours, despite having barely any sleep at all
last night. However the refactor is going well, hopefully tomorrow I can finish
the refactor if I do not finish it today. Otherwise I should work on the
emulator also, although I may work on the JIT.

## 18:30

So as I said before, I can use the registration system to not need service
loading on `JITOutputFactory`, although the factory is still needed.

## 18:32

Also removing the "supports config" would be good too, this would prevent
double checks and such.

## 18:38

So compilation wise, I am at the same point. However since I currently TODO in
code I cannot get to the linker stage yet. However since I want to get rid of
the old crusty code, I will bring in the linker part.

## 18:40

However, I can always wait for that, I do have version control and I can see
all of my old code. So I will set a note. Revision
`24503a462c85ef804c8fe8d008ee538ccc21bb02` will contain the old information
needed for linking and such.

## 18:53

And the refactor is complete for the most part except for the linking part,
but I can do that when I get the JIT code done. I should however next get the
emulator working and running the simple hello binaries I have.

## 19:31

Ok, so for the emulator, I can have a similar registration system that I have
for the configuration. Basically I can have common stuff across architectures
and such. Take for example mount points on Linux, this can be handled by a
POSIX mount point class. I can then use this for other POSIX-like OSes too. So
instead of rewriting it over and over for each OS when it is the same, it
will cut down on code duplication. Then I can get rid of the OS and
architecture specific configurations and just have a single one. For protection
I can make it immutable also. So basically, since many details on a target
system are unknown and vary widely across systems, this would be the most
sane choice because then there would be unimplemented stuff or things that
throw exceptions saying it is not supported. So for sanity, this would work
out well. I would then suppose that I need a basic CPU setup that can run
instructions, and then have a initializer and a undefined behavior trapper. So
when a system call happens in the CPU code, a special handler handles it. This
way there only has to be a single CPU emulator for each system. So similar to
what I planned before but easier to work with. Then it should be much easier
to add emulation of other systems to see how they sort of work out before I
support linking and code generation for them. One thing I can do though is have
a bunch of source code that implements a large number of operations, basically
a test binary. I can run this on the host system and also in the emulator. I
would most likely stick to just CPU instructions however. Although one issue
would be the fact that some CPUs vary. Regardless, writing the emulator will
help give me a feel out how to generate code.

## 19:54

Then for the register allocator, the first thing would be to prime the
arguments. However, now that I have `GenericABI` I can essentially just for
the most part assign every local and setup the initial stack as if the method
were entered. So I essentially refactored two sets of code. The good thing is
that right now is that I do not believe the base JIT needs refactoring at all.
The generic JIT just needed new register handling. But now that register
handling should be much easier to work with and should scale better.

## 22:02

So I believe first I will target Linux MIPS and PowerPC. Then once I have that
setup, I shall implement the bulk of the library. Implementing the library will
be a bit tedious, but if I stick to what I use then I can get away with not
implementing parts of it. Most of the basic CLDC library is the collections
though. After that would be MEEP which is a bit more complex. One thing I
will have to consider is the LUI code. I will be needing my own terminal
emulation code along with perhaps PTYs. I suppose for starters I can support
the vt family since that is pretty much a defacto standard.

## 20:09

So to recap, the current tasks would be:

 * Priming the arguments in the JIT.
 * Writing the emulator.

These should not be difficult at all since their algorithms are quite simple.
Hopefully in two to three weeks I can have a sort of demo, even if it just
prints text to the console. And since I currently lack sleep, I shall be
sleeping very soon now.