Indentations break the feed.

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

# 2016/09/09

## 09:08

It would probably be best to split off the string table from the constant pool.

## 09:16

The pool should probably become a visible map of sorts, potentially. I can
use the sorted tree classes I made, although all of the indices will be off.

## 09:19

The generic JIT is getting a bit unweildy. I believe it needs to be split off
a bit. One thing I would split off is the machine code related stuff, things
which are used by the compiler such as logic generators and register
allocation. Then after that, what is left is the result of the standard JIT,
that is anything layered on top of that. However, one consideration is that the
standard JIT can use the same base machine code generators also. Although I
would still have to decide on that. If however, they do use the same interfaces
then there could be a simpler bridging of output logic although it would not
have register allocation and it would basically be providing a byte code
representation of the program.

## 09:31

Another thing I can do is merge together some of the generic and JIT pool
related stuff. Perhaps remove the representation of the constant pool
entirely so to speak.

## 09:33

For the most part, the native code pieces can be reused by every implementation
of the JIT for the most part. One thing I can have though is that the
register allocator could potentially be replaced rather than using the default.
This could be used when a slightly difference scheme is desired. If I can
remove the bulk of the native code generated stuff from the generic JIT then
that package would be much lighter. The generic JIT just has to pass
information for the most part to the native code generators. Then the native
code generators could be used in the future to generate bootstrap code such as
if I need to have some kind of raw initialization process.

## 09:39

Then another plan would be a merging of the constant system, right now there
are some constant pool entries that are generic only that could be useful in
the JIT, these would be the call types and such. One thing I can do is to
remove the constant pool from the JIT and make it completely hidden. In most
cases the pool could become a burden as at least in the case of the generic
JIT, most of the pool would go unused. The generic JIT also virtualizes all
of the entries also. Also the base JIT code has an inclusion system so that
entries are marked as being used. Since I am doing that, it would be best to
just completely remove passing the pool and let the JIT implementation handle
such things.

## 09:44

So right now I have:

 * Move native code off to its own stand-alone project.
 * Hide the constant pool from the JIT interfaces and have a unified simple
   constant system.

## 09:47

So what I could do as I thought of before is that I could move the program
representation around also. Then this could be reused by code such as a
hypothetical interpreter or `javap`. The JIT interfaces can then take this
information and pass it to the JIT implementation. So that project would
contain just a class representation that can be piped into the JIT for usage.

## 09:52

So the end result of all of this should be much smaller and simpler JITs along
with reusable native code generators and class representations. I would
suppose that the hiding of the constant pool can be done by the class
representation code. And that representation code can use directly the stack
and local variables also. Then the JIT would handle stack caching so that it
is not in that representation code. Then once the JIT caches stack items and
such it will send that to the implementing JIT. The implementing JIT then
generates native code via the native code generator classes. Then this means
that the base JIT will get all of the stack and pool entry representations
moved out making it far simpler.

## 09:55

Then I can move forward with implementing the JIT and I would then be less
likely to step over anything, since the current rather large set of classes can
be difficult to navigate especially when they will only increase in size.

## 09:56

So basically:

 * `jit` -> `class-format`
   * Anything that represents the class file format goes here.
   * Make class streamers the JIT can use.
   * Hide the constant pool.
 * `jit`/`jit-generic` -> `class-format`
   * Merge pool entries
 * `jit-generic` -> `native-code`
   * Move any register stuff and other interfaces related to target code
     generation.

And some notes:

 * `class-format`
   * Keep a simplified and merged pool, hide the details of it and use only
     what is used.
   * Does not handle stack caching.
 * `jit`
   * Performs stack caching then passes that to JIT implementations.
 * `native-code`
   * Anything related to native code generate goes here.

## 11:43

It may be possible to even remove `jit-generic-mips` and `jit-generic-powerpc`
potentially.

## 11:56

So the Java stuff needs to be removed from the native allocator and placed in
the JIT.

## 12:04

What the native code allocator needs is a kind of state that can be used. It
either specifies that a register is used or some stack space was allocated. I
can then move the Java allocation state to use these markers. This would be
more effective than keeping variable states somewhere and using raw register
or stack values. Then the allocator state can be what is currently allocated.
The allocations should be immutable so they can be shared with the state,
otherwise it can get a bit messy.

## 12:55

Going to need a `native-code-base` which is dependend on by `jit-base`. Then
the floating point type is moved there. Then also with this native code being
split off, the allocator could handle cases where registers are 8-bit. So in
a way, in the future, it can help me when I write the small target JIT if the
current JIT does not become a part of it.

## 13:36

One thing I need to adjust is how the generic JIT allocates variables. I
believe I should follow a similar route and have it be based on allocations.
That is instead of register and stack it is just `NativeAllocation`.

## 13:43

Currently stuck on moving the generic stuff over, I suppose what I should do
then is move over the MIPS/PowerPC stuff such as ABIs and other things to the
`native-code` roots. Then from there I can work out how I want to access the
stuff from the generic JIT.

## 14:03

This means that the generic JIT becomes essentially final and provides the
service itself.

## 14:51

So the only thing I have to in the generic JIT code for this move is to make
the initial argument allocation with argument priming. However this should be
easy as I can have an input argument request that fills parts of the state. So
some of the generic code moves back and it becomes just a wrapped
`NativeAllocation` which is bound to the general allocator state.

## 15:18

So the moving of the native code generator is partly complete as my code now
compiles, I just need to reimplement that behavior now.

## 15:24

The generic output needs a factory that can create native compilers as needed
when methods are to be output.

## 15:29

I will need another tread for locals to store copied stack values since the
native allocator will not allow values to be duplicated, only spliced in
registers and stack. I can continue the reimplementation of the register
allocator code in the future. Now one thing I need to do is move the class
format decoding code into its own project and out of the JIT. Basically it
would operate as a kind of class reader where the constant pool is hidden away.

## 17:47

This means the class decode is rid of the JIT details.

## 17:49

And that is a good thing since it makes the class decoder code much simpler as
the decoder no longer has to juggle JIT details at all.

## 18:39

The stack map parser state needs a partial and then a locked state. One thing
to consider though is that the information could be hidden again. I may want to
go for it being hidden as before. Except for `ClassStackMapType`.

## 18:57

The operation parsing part of the class decoder is a bit ugly. However now that
that code compiled, I must now rework the JIT itself. Then after the JIT is
reworked I would then go into the generic JIT code again and refix that due to
the changes. However, the benefit now is that I can refactor the class parsing
code also. The class parsing code as I said is ugly and I will want to rework
that a bit, especially the operation decoding part. However the description
streams will allow me to easily refactor without changing much. One intended
goal that I have is to make the stack and local references a bit more stable.
That is, the Class code will give me what I need. However, the Class prefix
before the class format code is quite annoying and I should remove that
before I continue on to the JIT.

## 19:24

So now all my code compiles again. I spent the entire day refactoring. However,
my refactor is not yet complete. I must reimplement the code I removed and
perform a refactor of the class parsing code, especially the operation
handlers.

## 21:53

Seems that this split off code will work rather nice. Although the class writer
bridge will be very empty, it would definitely be a bit more clean compared to
the old code.

## 22:14

The class writers for the JIT does not need the pool index numbers.

## 22:27

So today, I got much work done. Now I shall go to sleep since I am rather
tired. Tomorrow I will work on reimplementing the removed parts of the code so
that I get back to where I was. Then I suppose I will refactor the byte code
handling so it is a much cleaner. Then after that, hopefully I can then get to
emitting actual instructions and such.