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
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
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.
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
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.