Operator links should stop at TOP also and treat those the same as NOTHING.


Yes, I know how I can do it with checking and such. For an atom I can have a derivation of the current atom. This essentially clones the current atom (not using clone()) where its state can be freely modified and operator chains used as such. Then once the code runs and sets the state, the future atom for the next instruction (or any jumping points) can be set to copy the state of it so that at the entry of the instruction, the state is known. The derivation however has to have the correct position and the code has to know its it one.


Thinking about working on that sample game: Squirrel Quarrel. Reading up on the event code, MIDlets can be registered to be events so that when they occur they are executed. So for example it can act as a sort of IPC but a very slow form. There is the MIDlet-Event-Launch-<N> attribute in the manifest. I do wonder though if there are URL scheme handlers which may be registered by applications. What I mean by that is that if a program does an invoke of a URL, some application has to handle it for it to work properly. MIDP 3 basically added all of these goodies. So essentially what could be done when playing the game is if you are looking away and it is running the background, you could be notified that your base is under attack for example.


However for the event system, if a given system supports global events or otherwise (such as Palm OS) I can wrap those events and then pass them to the midlets being ran. So essentially say if the Palm OS event/notification is made and sent to all applications (or registered ones) that a new volume was mounted (perhaps because a card was inserted), then for example an event could be made and sent to all registered programs for example under net.multiphasicapps.volume.mounted for a generic case. However, for OS specific events such as Palm OS creating a new database, I could instead generate net.multiphasicapps.os.com.palm.dbnew. MIDlets can also be used as push notifications also. MIDP 3 just makes midlets actually useful with other midlets and native programs. Intermidlet communication would also be very useful too.


The auto-start could be useful also. For example on Palm OS every application is told when the system boots, so the VM could check if any midlets it contains should be launched.


GCF and MEEP are subsets of MIDP 3 however and there is no MIDP 8 as of yet. So essentially GCF and MEEP would be implemented and then MIDP 3 would just depend on it and add anything that exists in MIDP3 that is missing.


I should probably split the sub-classes of JVMProgramState before that file grows too big since it is already about 1300 lines.


Can move ByteOpHandler also.


And now they are in their own individual sources and the file with the most lines is Slot at 477.


And the second instruction to handle is invokespecial. So this means I have to do potential variable calculation and such since such a call with its input arguments would mean that all operators of that kind would have to be evaluated.


For invokespecial and the operator links, I will have to perform the pushing and popping as usual. Also the identity result of the invoked method has to be placed on the stack also (as an unknown). So I suppose what I need is a special operator link which performs an invoke operation on inputs. So this would be a method based link. What I must determine though is if I should set a flag along with the link that indicates that the value is to be evaluated when it is used, or handle this later at the final code generation phase once the entire program is known. I suppose then I should generate operations and then wait until the end to determine if a value needs to be calculated before it is placed in a field or called through a method.


I will need an external symbol table to use references with, that is the table would be my import table. This can just be assigned to a single class and shared between all of its methods. Previously I thought of doing it per method, however if there are any shared calls they would just be duplicated between them. At least keeping it to a single class would be simpler.


I believe I am starting to understand the dynamic huffman code. The code lengths must become huffman code.


I should probably read the top of the RFC document and just implement the algorithms it specifies. Shorter codes precede longer ones, so I must decode those and then sort them accordingly.