08:52
Woke up a bit late this day.
10:41
Actually the byte code representation does not know the object a method is being invoked on, so there cannot be a virtual lookup. This also means there has to be another special instruction.
10:58
If I move some of the verification stuff to the lookup (checking that there
are no circular classes and extending/overridding of finals) then I can remove
that code from the interpreter. Also the compiler would benefit from it also
since it would not have to duplicate all of the access checks and such. I
could also virtually wrap all NCIClass and have mapped methods accordingly
as such.
13:30
I should keep some kind of statistics, since those would be useful in the interpreter.
13:32
Also, I should be able to implement the jdb protocol potentially so I can
actively debug the running virtual machine instance. However, one major issue
with this is how can the interpreter communicate with the debugger when there
is no real communication channel which is possible? I would need to actually
create some socket code perhaps from MIDP 3 and then use that as a kind of
agent using TCP of sorts. Although, there is MEEP. Or GCF.
13:47
However the GCF classes do not even specify how lookup of things and such are even performed. So I would suppose that I am given freedom to implement the services how I would do it, via the service loader and such. The thing is however, that I will need an actual launcher that wraps everything up while performing the needed magic. That would be rather complex at this stage. So I suppose that the interpreter I am writing cannot have an attached debugger.
13:52
I would suppose then, that I would have to define an actual launcher interface. This would be similar to an application selector. All running threads that either use real threads or are done via setjmp/longjmp style will be managed by the launcher. The launcher would need access to the magical stuff. In essence, the launcher is the kernel and is an important part of the virtual machine. The launcher should be able to run as a single thread. Any calls in the class library will just be forwarded to the launcher as a kind of user space call. So stuff such as permission checking will just cross calls and such. If I were to design the launcher in a way along with the magical interfaces where instead of writing the interpreter I have the launcher call the interpreter from a host virtual machine for now (perhaps Swing and such for example). There would be a system defined interface which defines and declares the needed things for the launcher to work. So programs would instead call into the launcher interface as a kind of system call. Then it should be handled in a way where the launcher being Java code can work when it is compiled and when it is running on another JVM such as desktop ones or SquirrelJME itself. Of course the launcher which runs on the JVM would be stuck to being interpreted, but tests could be ran on it and such.
13:59
Then this would mean there would be a launcher for each individual system on top of the common base launcher. Having such a launcher would save some time writing it and having an optionally integrated interpreter in it. For any system specific stuff not defined in the CLDC I will just need a bridge package which defines all of the interfaces that my initial host JVM launcher uses.
14:02
So if the launcher can invoke the compiler to generate code to be ran, then the launcher would have to be bound to a native compiler if it can perform JIT. There could also optionally be an attached interpreter too. The launcher using the service loader can determine if an interpreter or a AOT/JIT interface is being used.
14:05
So the first thing then would be to define the base launcher interface which can manage things. Then there would be an extension of this launcher which is defined by sub-classes, this becomes the driver which can perform the system specific magical stuff changed by the compiler. To simplify the base however, I would need to split the compact CLDC to a bare minimum set or at least modify the package builder to allow for alternative dependencies in a kind of replacement scheme. Or, I can have a special package which indicates that the host classpath should be used instead of a dependency. This way the CLDC is compiled and depended upon but it has no real effect since the system classpath takes priority when it comes to using classes such as Object and such. That would allow me to get away with defining a bunch of classes of the classes that I use. The host JVM interface would use reflection and other details to perform its magical work. Classes at least in this interface can be converted so that they conform to Java SE 7 (renaming things also) then used directly.
14:28
So the launcher being done now rather than later will mean that I will be able to design the interpreter and compiler into the launcher itself rather than writing the launcher following it and then attaching the interpreter/compiler to it. The launcher would call the compiler to generate native binaries and then load them as needed.
14:47
I will actually need a GUI manager of sorts. I suppose for now I can stick with a basic text based launcher interface. I suppose to keep it simple, the base launcher should just use a console interface. Other interface would be supported in the future if they are available.
15:22
For the base interface for the launcher, I will need JSR 238 so that I have an internationalized interface as needed.
15:39
The terminal will just be a basic 16x16 color terminal potentially. However RGB colors would be nice and may be supported on specific systems. Having the color scheme be similar to DOS however would result in only requiring a single byte for colors and such. Instead of annoying blinking text, the bits will just be bright color and emphasis added.
17:09
So the launcher will also need an abstract file system interface so that the host filesystem (or block device, which means I would have to implement a file system driver) can be accessed for JARs, programs, and such.
17:34
The launcher interface could actually provide connections so that jdb and
gdb may connetc and debug programs running on the system.
18:11
I will need some event system. Also, I should probably rename the launcher to something else. It would act as the kernel for the most part, so perhaps it should be named as such.
18:18
Also, instead of having a loop doing things, I should just have a thread
spawned for the user interface and associated with the kernel somewhat or
similar. Then the interface will just implement run in Runnable to do
things.
19:17
Drawing the console might be really difficult when it comes to swing, so likely the best way to do it would be with images.
19:54
Checking if a character is actually visible before drawing it is actually faster than drawing all characters regardless.
19:57
Ok, so now I need an event system which is fast and does not require countless amounts of objects for each event that occurs. So I suppose single integers in an array would do for events. That would be 4 billion unique events, which is rather plenty. There is no need for objects to be used in this case. The event handler could just really call an abstractable event handler for the user interface or similar. Or the user interface would just poll the kernel and such then possibly send events to a thread that is running so that the program which is currently in view gets said events. Then the console UI or other interface can handle special keys and such for actions to be performed. In the general sense, since I am going to support game consoles and such, I would want the ability to use controller inputs and treat them as events. So they would be essentially controller n pressing buttons or using a joystick. Then the user interfaces can have a virtual keyboard if text input is required and the system lacks an actual keyboard.
20:33
Implementing the weighted down scale was easy and looks nicer than GIMP doing the downscale. However some colors are missing it seems.
21:08
My color matching woes is due to sRGB however. I have the colors I want to weigh using linear RGB.
21:38
Disliking this since there is no way to convert to linear RGB and GIMP only shows linear RGB.
21:59
So the downscale works as intended so far. 32x32 is quite small, but it does not look that bad. However it seems 8x8 is really bad and 16x16 is not much better. So 32x32 is the absolute lower limit of the algorithm.
22:48
I put the SquirrelJME mascot as a base64 PNG in the skin for the fossil project, so hopefully it sticks.
23:10
Well, the algorithm made creating a 32x32 icon manually by hand rather nice and easy. I just had slight trouble getting the eyes just right, but I believe I have it now.
23:17
I believe 32x32 is the lowest sane resolution I would be able to reach. For lower resolutions such as 16x16 and 8x8, I suppose I should do something else. I suppose for 16x16 I can just do the eyes.
23:18
Actually the eyes and the mouth fit perfectly in a 16x16 image, so it is just cropped.
23:20
Now if I had a 24x24 version, I could draw it in the console window for the swing interface using purely ASCII art. It would essentially just be an intro of sorts.
23:35
So today I got many commits done.