Next will be
TABLESWITCH but I think what I will do there is just transform
that into code rather than having gigantic instructions because that will be
a bit complicated to implement and it would put it on the VM to implement it
correctly. I think it is just too much to be really that worth it. Since I do
not really want to dual handle these two cases I will just simplify
LOOKUPSWITCH since the previous is a linear set of values
while the second has multiple sorted pairs. Then I need only worry about doing
just a single format.
I think the only instructions remaining following doing all of this would be
instanceof, so I can do that quickly.
For lookup switches I am going to need an if compare to constant, but this can just be a single instruction.
Need to check if
DUP_X2 is done correctly and such.
Seems to be correct, should hopefully be fine. However the stack map table deltas seem to be wrong, they are according to my decoder:
- 0, 26!, 34, 62!, 86 -- 26 and 62 are not valid!
According to javap, they are:
- frame_type = 0 /* same */
- frametype = 252 /* append */, offsetdelta = 26, locals = [ int ]
- frame_type = 7 /* same */
- frame_type = 27 /* same */
- frametype = 250 /* chop */, offsetdelta = 23
There is a definite size difference here. Mine says there are 5 when there are 6. So something is being read incorrectly, likely a type.
Okay in the stack map parse I found an off by one for appended frames. It is subtracting 251, but I checked JVMS and it was correct.
Actually it is correct, just the offset delta is off by one.
It might have to do with implicit and explicit frames.
Definitely is this.
Okay so I cannot check against placeaddr, I need another variable to determine if this is an address which gets incremented by one.
Okay so this next one is a append top top int, followed by a chop frame. It chops off 3 locals. So the only logical thing I can think of is that those extra top-undefined types are considered for chopping which I believe I am doing.
So it seems that jumping to a state, unless my stack map table code is still wrong, can add more types onto the target. More bugs in the stack map table have been ironed out, it is a rather clunky format. So perhaps transitions can happen.... let me seee.... maybe I could check if a value is placed there or something. I suppose I can just assume that it means a zero register transition or similar.
Definitely want to refactor the instruction writing and such so it is a bit more compact.
I will definitely see how much more compact the classes are.
Still like 26K...
- w/ Lines: 27180 bytes (26 KiB)
- No Lines: 25628 bytes (25 KiB)
So the lines do not really matter much.
I could shave some bytes off the constant pool.
There are in the range of 300 pool entries, what if I could reduce that by making it so handles are not their own thing.