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.
00:05
It is now November. It should also be noted that x86 has too many extensions.
00:22
My phone which uses an ARM processor may have Jazelle on it, but I cannot do anything with it anyway.
00:35
Also appears that AArch64 is more like MIPS, such as the zero register which is really nice.
10:49
And now I am awake, a bit late however.
13:44
Been programming for the past few hours, suppose I should really eat breakfast. Right now most of java.lang.String is generated (it is mostly just blanks) but I have collided into a CHECKCAST instruction in compareTo. This is most likely just a bridge method generated by Java since Comparable accepts any type and as such erases to Object.
16:13
The next interwork temporary slot must be able to handle long/double values since currently it only obtains a single set for int/float/reference.
16:43
Noticed that registers were being read/written to the same positions for each of the locals, stack, and temporaries. So basically the could would look like:
load 3
load 4
load 3
load 4
load 3
load 4
Instead of :
load 3
load 4
load 10
load 11
load 20
load 21
However after this, the next thing to handle is ACONST_NULL which should be rather easy. On an unrelated note, I am glad I no longer have to type the HTML paragraph start and end anymore.
16:55
I could generate Markdown JavaDocs instead of HTML.
17:34
I must differentiate between static field reads and writes to detect changes in the classes and to make sure that fields which should not be written to are modified.
17:53
Completely failed that, wrote to the wrong class. For static field access I get the class static area and then an offset to the field. It might be just simpler to use a direct pointer to the field instead.
18:25
Appears that my PowerPC code could use some refactoring, most of the stuff is in a single class and a bunch of the methods are very similar albiet different. An exmaple of this would be all of the stack to/from int/float/double variants. One thing I can do is move all the register magic stuff into a new class. I could quite possibly have a kind of interface where I can just do something such as ".fromStack(bar).toIntRegister(foo)". This would make it really heavy in object usage however. Everything PowerPC is pretty much contained within a three classes where the 64-bit generation code is rather unimplemented. So yes a refactor must be done because otherwise this will just be really complex work to be done. I can have something in POIT that is called StandardBindings for very common CPU sets. When I do write the generator code, everything will be very similar for many architectures, just different set of CPU instructions. So what I can do instead is have a StandardTranslator which PowerPC and other targets can be based off. This StandardTranslator will essentially be a stack and register machine. This would help reduce the very possible duplicate code across all of the translators for each target architecture. Then after that adding support for new architectures will be much simpler as less methods have to be implemented where most of the cases are the same. I suppose instead of say StandardTranslator I will need a StandardRISCTranslator which does not have direct memory access and a StandardCISCTranslator.
19:48
Now that I have eaten, I can attempt start of refactor.
20:28
So far I am liking these changes.
20:56
I can also use method references for stuff such as types to types and to/from the stack. So instead of a bunch of checks in tons of stuff such as referenceRegisterToStack, said method can just call a method handle for example to longRegisterToStack. Another thing I can do is remove all the boolean stuff and just throw exceptions.
21:02
I can also have just basic register to memory operations, of which the stack related stuff can base off that. I suppose for those however that I should use LongSupplier for offsets because it is very possible that the offset will not be known yet. There can still be standard long based ones however.