-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unimplemented instructions #40
Comments
Zero. |
Ehm... that's not what yevano just said. The one I listed (yevano said) isn't implemented... so.. |
There are several that aren't implemented but zero that use the old interpreter code. The interpreter has been 100% gone since the JIT's beginning |
Hmm... well I was just saying what Yevano said. Either way, that instruction I listed (fcmpl/g) doesn't seem to work for me? Maybe its just a weird anomaly? Or is it that the installer has a version which has a broken version of that instruction? Not sure... |
Like I said, there are several instructions that aren't implemented. Unimplemented instructions will throw an error. I'm surprised that fcmpl/g aren't implemented. But they should be easy enough to put in. |
Sounds good to me. :) |
No, sci4me is correct. Some instructions (such as 0x94-0x98), do still contain old interpreter code. I probably should have gotten rid of that a long time ago, but I think I originally left it so as to make it easier to implement the instructions in the new way. |
Taking a look at a lot of the unimplemented instructions, I think we need to split doubles and longs into multiple registers like the JVM does just to make implementing the instructions more correct. Maybe the first register has the value and the second has a magic value the represents double or long. This might complicated invocations though... |
If we just make everything conform to using one register per value, won't it still function correctly? I haven't really looked into it, but that's just my intuition. I'm guessing the compiled Java code doesn't do crazy things with the multiple registers. If we can make certain assumptions about how the Java bytecode is normally formed, we might not have to worry too much. This is similar to how we don't need to implement the jsr and ret instructions because no compilers actually use those instructions these days. (And I think it's actually an error now to execute those instructions in modern VMs, but I'm not totally sure). |
Well there's just a couple of instructions that behave differently when a value is a double or long. I don't know enough to say if it can just be ignored or not. |
fcmpl/g to name the one that caused me problems...
how many instructions are still using the interpreter code?
The text was updated successfully, but these errors were encountered: