Had a nightmare that a school was throwing out all of their Apple IIes and I was not allowed to take any of them. So much for preserving some history.


So the thing is, I need a common setup for registers and such for the generic compiler. But I need a system which is not limited at all. Also, not all registers could be used at any one time also. One thing to consider is ABI crossing where SquirrelJME's calling convention does not match that of the running operating system if native C libraries are to be accessed. However the main plan is to just have everything be a static binary. Having a dynamic library such as libsquirreljme.so would be interesting however.


Perhaps something that might work better is one something that goes with the code. Basically the configuration can specify a factory that is to be used to generate worker helpers for a given target. Essentially instead of specifying a list of registers and the permitted parts of it, it will basically handle the register allocation and the stack setup. There just needs to be an initial setup to determine what is used. Since the generic compiler has for the most part the same thing for any CPU, it will essentially just be a base class. It could be part of the configuration but could just be a mapping of helper factories. So one would register a given class to a specific factory. This way there can be multiple ones and the configuration system does not have to be cluttered with unknowns.


Since I have an other note system, I should move the manual stuff away and place it there.


This should be the most effective, since it would allow multiple class types. So I just need to make a factory which handles register allocation and such. Since factory instances vary, I can have their own method. So the generic compiler stuff for example would need to pass the program being used. Other kinds of factories would vary depending on the situation. This would be the most flexible choice and the most adaptive. One thing to consider that a request for a given class should match the type that was used. So one cannot register a factory of type A and then have it associated with key B.


So the generic register allocator will take the purely virtual registers given by the JIT and manage them. Each instruction address will need to have its state stored or at least marked for jump targets. This would be so that jumping back can restore the proper state into the allocated variables and such. As previously mentioned, the JIT will be a simple stack caching and will not perform much when it comes to optimizations.


Basically most operations should be easily mapped to native instructions at least for my first target: MIPS. The most major work when it comes to writing would essentially be the register allocator, jumping, calling methods, and exception handling. One a basic layout is done, I would then need to write the linking system to find classes and such.


So is it a special or is it something else? It would just be a generic class association mapping for the most part. It would be registerFoo and a getFoo, but what are these special things called? I suppose just Object can do.


Then they could also have an extra an optional interface which is used to potentially configure it via system properties and such. Or it could be required.


This is quite a bunch of typing adding the skeleton for {@link Display} by hand.


The LUI interface is not really that great, it definitely is not a traditional character based terminal with character cells and attributes. It might be a bit difficult to implement Squirrel Quarrel on this type of display.


And I am done, that took awhile. Although I do have to implement the key event stuff eventually.


Going to need a way to specify midlets and such.


What is needed is the following:

MicroEdition-Configuration: CLDC-1.8
MicroEdition-Profile: MEEP-8.0
MIDlet-Name: Squirrel Quarrel
MIDlet-Vendor: Steven Gawroriski
MIDlet-Version: 0.0.2
MIDlet-1: Name, icon.png, main

So if I were to just specify MIDlet-1 and such that could be a trigger for if something is a MIDlet or not to the build system.


What I need is a refactored build system that is actually in the build root. One that bootstraps a very minimal build system into say a single JAR file. Then, this build system invokes the internal build system. This way the actual build system and all of its logic is part of SquirrelJME rather than being very alone.


Need to determine which package the MIDlet interface shall go inside of.


And I managed enough to get the MIDlet installation on an actual Java ME 8 system.

Suite: 2
  Name: Squirrel Quarrel
  Version: 0.0.2
  Vendor: Steven Gawroriski
	Squirrel Quarrel (Console): net.multiphasicapps.squirrelquarrel.

It also runs and then crashes, which means it works: java.lang.Error: TODO - net/multiphasicapps/squirrelquarrel/ConsoleMain.destroyApp(), bci=6 - .unknown...unknown.(), bci=2 - .unknown...unknown.(), bci=6 - .unknown...unknown.(), bci=306 - .unknown...unknown.(), bci=38 - .unknown...unknown.(), bci=5 - .unknown...unknown.(), bci=130 - com/sun/midp/main/AppIsolateMIDletSuiteLoader.main(), bci=23[ERROR] [AMS] iso=1:Sending the notification: com.oracle.midp.proxy.RunCommand@210 . FAILED, proxy is disconnected

So I appear to have the potential for an actually testable setup. For the configuration autodetection based on dependencies, a new build system I can setup via the package manager can perform the detection work as needed.


So it will be very important that a new build system be setup that can run entirely within SquirrelJME.


I suppose I can work on that before I continue on to the JIT. I can add to the existing project manager but then also have an interface which specifies a compiler that can be used to compile the code as needed. My bootstrap can build a bootstrap JAR setup from a set of packages and use that to actually configure things. I could also utilize some more manifest properties that specify what something is, or if it provides a standard. One thing I can do is if a dependency depends on a standard, it can just depend on that rather than my own package set. This way it would be a bit easier to see if it conforms to existing machines.


One thing is that a JAR cannot be both a MIDlet and a LIBlet, but I kind of dodge that as not supporting such a thing sounds really ugly (reusing code is very nice). So as such, I will note a bug.


SquirrelJME will be a microkernel. The JVM that runs closest to the system will interact with the hardware. Any application that then runs including the launcher will communicate to the hosting JVM via some unspecified channel. So while the JVM's stdout will point to the actual stdout, the application one will point to some kind of virtual console instead.