Starting with the good news, we finally merged the ``arm-backend-2`` branch
-into the main development line. As described in previous posts the main goal of
-this branch was to add support for ARM processors to PyPY's JIT. As a general
-byproduct the multi-architecture support should have tgo we improved several
-details of PyPy to better support non-x86 architectures such as ARM and the
-in-progress support for PPC64. The JIT requires an ARMv7 or newer processor
-with a VFP unit targeting the ARM application Profile. These are the same
-requirements as those of the Ubuntu ARM port and correspond to the hardware
-used in most smartphones and development boards offered today.
-might support previous architecture versions, but will be slow.
+into PyPy's main development line. As described in previous_ posts_ the main
+goal of this branch was to add support for ARM processors to PyPY's JIT. As a
+general byproduct PyPy should now do a better job supporting non-x86
+architectures such as ARM and the in-progress support for PPC64.
+On ARM, the JIT requires an ARMv7 or newer processor with a VFP unit targeting
+the ARM application Profile. Although this sounds like a strong restriciton,
+most of the ARM processors used in mobile devices and development boards are
+ARMv7 (sadly the raspberry pi isn't) or newer. Also these are the same
+requirements as those of the Ubuntu ARM port. The non-JIT version might support
+previous architecture versions, but without the JIT it will be slow.
-The JIT backends supports floating point numbers and therefore requires a VFP
-unit to be present. The **Procedure Call Standard for the ARM Architecture**
+Because the support for a floating point unit is optional for ARM processors
+there are historically different calling conventions. These differ on the
+requirement for a floating point unit.
+The **Procedure Call Standard for the ARM Architecture**
(`PDF`_) describes in the *base procedure call standard* how parameters are
passed in processor registers and on the stack when calling a function.
When supporting floating points there are two incompatible procedure call
standards and three ways of handling floats. Usually they are referred to as
*softfp*, *soft-float* and *hard-float*. The first two use the core registers
-to pass floating point arguments. The first uses a software based
+to pass floating point arguments. The first uses a software based
float-implementation, while the second can use a floating point unit. The
latter and incompatible one requires a floating point unit and uses the
coprocessor registers to pass floating arguments to calls. A detailed
comparison can be found `here`_.
-The PyPy ARM backend currently supports the soft-float calling convention,
-which is the most common one. This means that we have to copy floating point
-values from the VFP to core registers and the stack when generating code for a
-call that involves floating point values. Because the soft- and hard-float
-calling conventions are incompatible, PyPy for ARM currently only will work on
-systems built using soft-float. More and more GNU/Linux distributions for ARM
-are supporting hard-float. There is almost finished support in the JIT backend
-for the hard-float calling convention, but we seem to have hit an issue with
-ctypes/libffi on ARM that is blocking us to run our tests against the
+The JIT backends supports floating point numbers and therefore requires a VFP
+At the time we started implementing the ARM support in the JIT the soft-float
+calling conventions were the most commonly supported ones by most GNU/Linux
+distributions, so we decided to support that one first. This means that we have
+to copy floating point values from the VFP to core registers and the stack when
+generating code for a call that involves floating point values. Because the
+soft- and hard-float calling conventions are incompatible, PyPy for ARM
+currently will only work on systems built using soft-float. More and more
+GNU/Linux distributions for ARM are supporting hard-floats by now and there is
+almost finished support in the JIT backend for the hard-float calling
+convention. But we seem to have hit an issue with ctypes/libffi on ARM that is
+blocking us to run our tests against the hard-float implementation.
Testing and Infrastructure
seen on the `PyPy buildbot`_. As can be seen there are still some issues to be
+In a previous post we mentioned a set of open topics regarding PyPy's ARM support, here is an update on these topics:
+* 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.
+ The scratchbox2 based approach has given the best results so far and qemu has shown to be to unstable to use it as a base for the translation and the qemu-arm emulation is very slow compared to cross-translating.
+* Test the JIT on different hardware.
+ As mentioned we are running nightly tests on a Beagleboard-xM and a i.MX53 board.
+* 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.
+ As stated above this is now working, we explored
+ using qemu-arm and a chroot to run tests and this didn't although faster than
+ our boards was to unstable and crashed randomly as to be used to run tests on
+ a regular basis. A fully emulated approach using QEMU might still be worth trying.
+* Improve the tools, i.e. integrate with jitviewer.
+* Review of the generated machine code the JIT generates on ARM to see if the instruction selection makes sense for ARM.
+* Build a version that runs on Android.
+* Experiment with the JIT settings to find the optimal thresholds for ARM.
+* 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.
.. _`PyPy buildbot`: http://buildbot.pypy.org/summary?branch=%3Ctrunk%3E&category=linux-armel
.. _`PyPy docs`: https://bitbucket.org/pypy/pypy/src/default/pypy/doc/arm.rst
.. _i.MX53: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53QSB
.. _`nightly build server`: http://buildbot.pypy.org/nightly/trunk/
.. _`PDF`: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
.. _`here`: http://wiki.debian.org/ArmHardFloatPort/VfpComparison
+.. _previous: http://morepypy.blogspot.de/2011/01/jit-backend-for-arm-processors.html
+.. _posts: http://morepypy.blogspot.de/2012/02/almost-there-pypys-arm-backend_01.html