Skip to content
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

Open
ghost opened this issue Oct 15, 2014 · 10 comments
Open

Unimplemented instructions #40

ghost opened this issue Oct 15, 2014 · 10 comments

Comments

@ghost
Copy link

ghost commented Oct 15, 2014

fcmpl/g to name the one that caused me problems...
how many instructions are still using the interpreter code?

@ElvishJerricco
Copy link
Member

Zero.

@ghost
Copy link
Author

ghost commented Oct 15, 2014

Ehm... that's not what yevano just said. The one I listed (yevano said) isn't implemented... so..

@ElvishJerricco
Copy link
Member

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

@ghost
Copy link
Author

ghost commented Oct 16, 2014

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

@ElvishJerricco
Copy link
Member

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.

@ghost
Copy link
Author

ghost commented Oct 16, 2014

Sounds good to me. :)

@Yevano
Copy link
Member

Yevano commented Oct 16, 2014

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.

@ElvishJerricco
Copy link
Member

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

@Yevano
Copy link
Member

Yevano commented Oct 20, 2014

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

@ElvishJerricco
Copy link
Member

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.

@ghost ghost mentioned this issue Nov 22, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants