The stack pushing and popping would likely be better if it were more intelligent rather than just the types. So pops would be just the type while pushes would be the given n-th pop or a new value.


Also the state of the stack and operations should be known also, so there must be no narrow or wide alias types. This would make parsing much easier for example.


The interpreter could actually first have a duality. For example I can have a pure interpreter which is standalone so to speak, and then have the compiled program execution. This way I can easily test if the byte code is being interpreted properly before the compilation route is taken. It would have to be pluggable in that any route can be chosen. Although the pure interpreter would be a bit slow it would help much in debugging.


Although the pure interpreter would be slow, hopefully this new design will make it slightly faster. Then once the pure interpreter works fully I can then design a native compiler that works with it.


Actually for system properties I need something similar to the useful squirreljme.error.


It would be best if the byte code representation was given the lookup interface. This way the verification that the byte code is actually correct only has to exist in the byte code representation and not in the interpreter or the compiler. Duplicating the verification could end up being rather dangerous.


Also since the work would be done in the byte code representation, then that means the interpreter would be much simpler because it does not have to perform that many checks.


What I need in the operation is a way to cleanly load all of the required information without making it very ugly. The constructor for operations is going to be gigantic.


Something which I need would be to have is the stack map table and such loaded in so the byte code can be verified correctly.


Will need a singleton so that the first operation always has an implicit verification state which matches the flags and input arguments.


The UnmodifiableList class for the non-random access list should implement the list iterator since it is possible for AbstractList to not actually be RandomAccess. As such depending on the ListIterator implementation it is quite likely that for stuff such as LinkedList that it would just iterate through the entire list and the further away the ListIterator is the more operations are performed, so it would basically be O(n^2) which is quite bad.


Also with the lookup, the byte code initializer can verify the access permissions of the target class. This would then mean that the interpreter would never have to check the access requirements during execution which would result in slightly faster interpretation. It is illegal for the byte code to reference classes in this way also however. So this would result in an easier to implement compiler and interpreter since the operations and such would already be checked.


Class types would have to be verified though along with null references and such.


This time individual treads for the locals and stack makes it easier than having them combined together such as it was done previously.


I wonder if the class lookup should accept ClassNameSymbols so that arrays can be referenced and such.


This means I will need a can access checker for the byte code.