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.


I am going to have to fix POIT because that few hundred errors appearing everytime I use NARF can get bothersome and makes it harder to see if NARF works. However, I can always just not call if a config is supported unless a compiler is chosen.


Well it was actually caused by my addition to have foo@arch, the supported only checked if the base foo supported it and not any potential architecture specific addition. I should also probably add a foo@arch@extra so that there may be multiple variant support for architectures. There could be two different supports by the same compiler for the given architecture, perhaps a dynamic recompiler separates 32-bit and 64-bit code for example. That would actually be rather handy as it could complicate things less. However the NARF dynamic recompilers should be rather generic and support everything.


However, the extra field would be very vendor specific and there would be no way to know how it is used. One compiler could use one extra format and another compiler can use it completely differently, while hairball would be unable to tell the difference. So due to that, it would be best not used.


The first part of the NARF dynarec will transform the Java byte code into that abstract-ish program for basic optimization and assignment work. It will not be SSA.


One thing I do not want, is a gigantic mega-class or a hundred classes for handling byte code operations. I could perhaps move them into separated classes and sort them by functional group.


I have this idea for the disassembler, I have instruction guessing in the ArchitectureData class, instead of having it there I can have a sub-class that can be cached which can cache the guessed instructions.


Today is a leap year. This means I can get a commit and log on the 29th and it will be very special.


I have figured out a way to sanitize the fossil export so I can eventually it run it in gitstats to give repository statistics which I have not done in awhile. Two years of project time is coming up however. Lots of dedication to get this far despite not having a true dynamic recompiler yet.


I wonder if I should rename Foobarniux to say something such as Squirrex or Squirrelex. However "Squirrelex" is a meme that I know not of, basically something called "Skrillex Squirrel" which I do not know. There may be negative attachments to it and such, so it would best be avoided.


I could try "Squirrnix" or "Squirrnex". Google says nothing for "Squirrnix" and suggests other searches. "Squir" appears to be a word, meaning to throw with a jerk, to throw with edge foremost. So is this throwing something slightly different or is someone throwing something with a jerk (as in person). So I suppose Squirrnix will work, it is potentially easier to say and faster than "Foobarniux". Two instead of four. So I suppose a rename is in order again.


The new name is also one character shorter too.



I wonder if I would be able to base AWT on top of JavaFX so then Swing which is based on AWT could also be based on JavaFX. Supposidly Swing is on its way out in the future so having AWT/Swing on JavaFX would work for compatibility while potentially having a common look between all three of them.


However, JavaFX does not support image format operations for what ImageIO is used for.


Ok, so the JavaFX source I grabbed is OpenJFX 8, Update 40. So this means that there is printing, because otherwise not having printing support would be rather bad.


When it comes to the GUI, JavaFX might be simpler to implement because it is a bit more modern, although it might be complex.


The biggest part of the fourth part of the library though is the AWT/Swing stuff, so figuring out a way to modularize that more will be a bit complex. Also if hardware accelerated graphics come into play, then I am going to just support Vulkan.


I should probably fix POIT so I can run it if needed and also not have to watch it fail to compile everytime NARF fails to compile.


Looking at the stats for the repository. The least popular day of the week I have made commits on is Thursday, then followed by Friday. I still follow a sine wave pattern across the weeks. In 2015 I made 5000 commits and so far for 2016 I am halfway there. Actually read that incorrectly. 2014 was almost 3000 commits, this year there are only 270 so far. It seems that fossil export to git handles edits that have been made to commits (their author) since I no longer have giant vertical jumps in a bunch of locations. I currently just have one large jump.


I must work on the new ArchitectureData stuff. Thinking about JavaFX it may be possible for me to implement as a framebuffer (for the console) on top of JavaFX. So there would essentially be a kind of kernel provided window manager. However JavaFX is a bit large for a kernel so that might be a bad idea.


JavaFX does not compile for me, most likely due to my PowerPC. So if I were to add test and such my own JavaFX implementation it would have to be rather independent for it to work properly. I can at least install the source so I can run code stripping through it.