DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.
Might be rewriting a huge chunk of the JavaCodeBank and the Decoder. I need a normal FormCodeBank and then an FormCodeBankExecutable which can be used by the run-time to actually execute banks which are loaded. That would reduce the need to write tons of loaders as I can just have on (past the bootstrap). Part of the decoder code is clean while other bits are nasty. The stack handler will definitely need recleaning and anything using that to be changed. Also with possible better type verifications. There are also two different stack modes and more restrictive stacks in Java 8. The Java 8 stack forces single instances and gapless local variables. Gapless as in local 12 cannot be set before local 11 is set and such in any state.
Well, it is not going to be a complete rewrite, just a major code clean up and optimization. One part that is going to be rewritten is the stack code as it is a bit ugly. I can also move all the code over as needed also to a new package rather than putting it in the form.ld package which is rather ugly. A new asmfmt package will keep the nasty bits out. Another thing is the asmfmts get their own package. Also the dynarec for PowerPC and other things will have their own asmformats in their respective JARs. Their factories can either be an encoder of a DecodedMethod or a decoder into them. Although for most of the languages it will be a one-way encoding trip. I will also have to move the stuff around for the Java byte code handling so that it may be reused later by the compiler to output standard class files. For many of the operations that are the same for the decoder, I can create some fancy lambda references instead of just having a giant MethodHandle table. Although I will be initializing that stuff. All the byte code operations will just be placed into another class, so just a move over and a cleanup. Then perhaps another class for simplified operations. I will have to determine how that would work. Some operations are really complex, some are just duplicates of others, while others just call a standard helper method.
Not going to do a rewrite of the core decoder stuff, just the stack stuff along with major cleanup. The stuff like the Java class loader works and I have no reason to actually touch it, but it could be cleaned up a bit. Well no reason to trash it completely. Moving the stuff from form.ld into both binfmt and asmfmt. Probably would be best to get to work cleaning stuff up after I sleep. So to reiterate:
- Move binary related Java (class file) to binfmt.
- Move code related Java byte code stuff to asmfmt.
- Separate and rewrite the JavaMethodDecoder.JStack into its own separate class file, also handle return addresses and stuff such as uninitialized and null values along with more type availability.
- That would go for Spot too, make it better.
- Take all of the operation run handlers in JavaMethodDecoder and make it a bit nicer, some ops are the same so they can be mapped similarly. Might be best to have a separate class which handles all of the varying opcodes and their similarity. Perhaps with lambdas with arguments for specific cases that are very similar.
- Add base code path for the possibility of encoding Java byte code and writing of class files, so that it may later be used by the future written Java compiler.
- Commonize some structures to allow for reading and writing of them so that they may be used by both encoders and decoders of code and binary files (structures such as StackMapTable).
So far the refactor goes well.
Now everything is moved over to the new packages and compiles and runs without issues, however the refactor is only just beginning.
Currently rewriting my stack code and it looks much better than before, also a bit more object oriented.
Will need to move pushpop code to the new JavaStack and such.
Ported over everything to the new code althougn the current matchPushPop does not operate as intended it seems.
Probably due to a missing pivot being copied.
Appears that there are extra top bits set in the target stack.
And this time it is not my code that is incorrect, but the StackMapTable truly does have three consecutive top values inside specified. Now I wonder how that works.
Some kind of bug somewhere causes the stack states to not match properly. It is most likely the StackMapTable related read. So instead of avoiding the issue I should fix it before I proceed.
And as I suspected it is stack map table related.
And with little flag hints I have
FCFCACACFS1. Perhaps the problem is with
the same frame and the same frame with one thing. Although the append frame
could also be the problem, however the full frame after it nullifies it. So it
is one of these: full, same, or same1. However those types are really simple
as they just represent a single thing.
The full frame however, the local values can be lower than the actual number of stack items. However I clear the upper bits. Not clearing it causes other things to occur elsewhere.