[pypy-dev] pypy arm progress

[David Schneider]

Hi Wiktor,


> -We are looking for a better way to translate PyPy for ARM, than the one describe above. I am not sure if there currently is hardware with enough memory to directly translate PyPy on an ARM based system, this would require between 1.5 or 2 Gig of memory. A fully QEMU based approach could also work, instead of Scratchbox2 that uses QEMU under the hood.

By now I think using Scratchbox is the best approach to translate PyPy for ARM. The cross-compilation tools have gotten better over the last year and the setup has become easier to reproduce. There are some machines like the Calxeda servers[1] that have enough resources to translate PyPy directly on the host, but it is still at least 4 or 5 times slower than cross-translating.

> -Test the JIT on different hardware.

We have a BeagleBoard-xM[2] and a i.MX53 Quick Start Board[3] that run the JIT backend tests nightly.

> -Experiment with the JIT settings to find the optimal thresholds for ARM.

Still pending

> -Continuous integration: We are looking for a way to run the PyPy test suite to make sure everything works as expected on ARM, here QEMU also might provide an alternative.

Since yesterday we have a buildbot  on a dual core x86_64 machine that uses a combination of chroot and qemu-arm to run tests. There is a builder that runs the PyPy unit tests, which is very slow in this setup and can mainly improve through having more cores to run the tests, and a builder that translates a version of PyPy with and one without the JIT to run tests on top of them. There are test failures in all of these builders, some of them are apparently related to architecture specific things and in some cases we are seeing seemingly random segfaults in qemu. So here is also some work left to be done.

> -A long term plan would be to port the backend to ARMv5 ISA and improve the support for systems without a floating point unit. This would require to implement the ISA and create different code paths and improve the instruction selection depending on the target architecture.

This is still pending.

> -Review of the generated machine code the JIT generates on ARM to see if the instruction selection makes sense for ARM.

This is also pending.

> -Build a version that runs on Android.

This one is still pending, but there was a discussion about it last week on the mailing list.

> -Improve the tools, i.e. integrate with jitviewer.

This one is done.

My main focus, currently is on getting the branch and the testing infrastructure into a state that allows it to be merged back into the main development line.

Regards,

David

[1] http://www.calxeda.com/technology/products/
[2] http://beagleboard.org/hardware-xM/
[3] http://l.bivab.de/OS6jOu