Actually with my argument handling, I can simplify.
I can also have an interpreter on the interpreter test, which would be likely exponentially slow when running tests, however it would see if the interpreter can interpret itself however.
WeakHashMap just using
HashMap will not work because I may need reference
queues and the ability to use iterators without worrying about concurrent
modification of the key values. Otherwise keys will only be removed during
iteration. However, with multiple iterators it would get confusing as to which
entries are gone which are not. So basing it off that will not work.
I suppose for my implementation of the hashmap, I will have buckets where the
keys are identified by their hash. The keys would be sorted by their hash.
When a lookup is performed a binary search is made for a matching key. If one
is found, then its value is obtained. When the load amount is reached then the
number of entries would be doubled in size. Entries in a bucket will be split
between the two buckets. To determine the bucket that a key is within there
will be a basic binary search based on an initial starting hash. So for example
the starting bucket has a hash range between
Values are placed accordingly. When the capacity or load factor is reached then
the bucket is split down the middle and entries are sparsly placed in the
arrays. with an even amount of spacing between them. The only thing to
determine though is if a position is blank is could possibly affect the binary
search. So if an area is blank then it should share the same key as an entry
before it. Then for values I can have a special value identity which says
if the key is actually valid or not. If a binary search does not find the
entry then it would specify the location where the item would be and if it
points to an invalid entry then it will be cleared. Since
WeakHashMap will be very similar. Thus, I can have a
common hash class which can be used internall by the code in a private
LinkedHashSet could just use the
LinkedHashMap and go through their keys then use dummy object for usage in
add since it must know if the data actually changed.
I suppose instead of
IOOB and such I can give them actual error
codes when null is passed. However that will create a lot of error codes for
just null checks. So I suppose for the main class library I will use error
codes like that instead. With two sets of letters, I have 1,296 error codes
available. If this is not enough then I can always add another letter. I
suppose for the class library instead of
CL I should use
It would be simpler for type determination if the old values were only sane for what the type an existing value is.
I may have enough of a partial interpreter to write an SSA optimized variant of it which might be cleaner than the current interpreter and much faster. Currently hit a bug in the interperter when popping frames. However the interpreter is very complex and slow. The SSA representation should be similar to the native code representation. Need to have an efficient means of handling exceptions in the SSA code. Perhaps a kind of lookup table instructionally speaking.
I will need two registers, the address being handled and the exception being
handled. The exception handler lookup will be at the start of a method. It will
check if there is an exception, if there is then it will look for the given
instruction in a specific range and if one of the correct type is found then
it will go to the exception handler. This can get really branchy however,
although it would not require a lookup table. An alternative however is a
special instruction which contains a lookup key. If the exception handler of
an instruction changes then that register becomes the lookup key. Then when an
exception occurs type checking will occur to determine which exception was hit
except if the given exception is
Throwable (which catches everything). In the
Throwable it will just be a jump to the exception handler.
I believe I have a verification operation which is not correct which causes the error I hit in the interpreter.
Appears the topmost float is not passed to the constructor.
The class program code and the current interpreter are quite large:
3221 javame-class-program java=3221 2659 javame-basic-interpreter java=2659
And consist of a number of methods and classes. I must find a way to simplify them so that they are together as one and perhaps in only 4000 lines. It must also handle SSA too. The class file code is about 2000 lines of code.
When I look up the exceptions I can generate the code at the very start and put special markers as such for handling exceptions. For the stack map table and the byte code, I can process them linearly at the same time. Verification of types can be inlaid to the SSA variable data. So instead of a verification and then an interpretation/compilation pass, they are both performed at the same time. So instead of determination and op handlers, it would be combined into a single unit. Many operations are pretty much the same. So it would be similar to the compute machine except it would be given actions which could be merged to and from SSA code.