On Friday, 13 January 2012 at 16:02 , Antonio Cuni wrote:
> Hello Michał, > > On 01/12/2012 09:24 PM, Michał Bendowski wrote: > > Hello everyone, > > > > Back in the summer I asked on this mailing list if there's interest in > > moving the JVM backend forward. Back then there was some enthusiasm, so I > > got back to it when I had the chance, which unfortunately was a few months > > later. The suggestion back then was to look into using JPype to integrate > > more closely with Java-side code, and that's what I would like to do. > > > > But before that, I noticed that the JVM backend fails to translate the > > standard interpreter and spent some time lately getting to know the code > > and trying to get it to work. What I have right now is a version that > > outputs valid Jasmin files, which unfortunately still contain some invalid > > bytecodes (longs vs ints from what I've seen, I'll look into it next). > > the long vs int problems are likely due to the fact that you are translating > on a 64 bit machine. The translator toolchain assumes that the "native" long > type of the target platform is the same as the source one, but this is not the > case if you are targeting the JVM (where long is 32 bit) on a 64 bit linux > (where long is 64 bit). > > This problem is not easily solvable, so my suggestion is just to translate > pypy-jvm inside a 32bit chroot for now. > > > It would be awesome if someone could take a look at my changes. What's the > > best way to submit them? Bitbucket pull requests? They will need to go > > through some review - do you have a workflow for that? > > we don't have any precise workflow, although a bitbucket pull request might be > the easiest thing to do. I'll be glad to review it. > > > Here's a short list of stuff I found and fixed (hopefully): > > - support the ll_getlength method of StringBuilders in ootype, > > - make compute_unique_id work on built-ins (StringBuilders again). > > > > not sure what you mean here. What is the relation between compute_unique_id > and StringBuilder? > > > - provide oo implementations (or stubs) for pypy__rotateLeft, > > pypy__longlong2float etc. > > - handle rffi.SHORT and rffi.INT showing up in graphs. For now I try to > > emit something that makes sense (seemed easier), but the right solution is > > probably to see if the code in question (rbigint, rsha) can be implemented > > on the java level. > > > > yes, this is another issue that has been around for a long time. In theory, we > would like to be able to write per-backend specific code which overrides the > default implementation. This would be useful for rbigint and rsha, but also > e.g. for rlib.streamio. However, we never wrote the infrastructure to do that. > > > - handle the jit_is_virtual opcode - I had no idea how to "safely ignore" > > it for now, is False the safe answer? > > yes. Look at translator/c/funcgen.py:848: this is how jit_is_virtual is > implemented by the C backend, you can see that it always returns 0/ > > > I hope someone can help me to submit the changes and maybe guide with > > further work. > > Please put your work on bitbucket, I'll review it. I'd greatly appreciate if > you committed small checkins (one for each fix/feature you are doing) instead > of one giant commit with all the changes :-) OK, I got myself a 32bit environment and created the pull request (. I'll be grateful for any feedback. One thing I didn't do was to create regression tests against the problems I found - I didn't know where to put the tests and what (and how) exactly to test. If you can shed some light on it, that would be awesome. Here's the URL: https://bitbucket.org/pypy/pypy/pull-request/19/improvements-to-the-jvm-backend Thank you, Michał _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
