Friday, June 25, 2010
PyPy GSoC status update
Well, the backend is RPythonic again. And I managed to remove some of the boilerplate/duplicated code from the rx86 module, although there is still room for improvement. Also, some common cases of loading a large number of variables from memory locations that are "close" to one another became more efficient.
The main thing this coming week is to address an issue that I only became fully aware of in the middle of this week: Many places in the code use jumps with a 32-bit relative displacement that are sometimes patched later to point to a different destination. The problem is sometimes you need to patch it to point to a location farther away.
This issue had been masked by the fact that on some operating systems (Linux included), you can give the operating system a hint as to where you'd like the memory to be allocated, and as a result, all of the memory used by the JIT was within 32 bits of each other. But we can't count on that working all the time on all platforms, so we need to handle the edge case.
We have a plan for how to fix this while not making the common case any less efficient, and while it is not hugely difficult, it also isn't trivial.
After this issue is taken care of, the next thing will be to port the asmgcc root-finding strategy to 64-bit. (Without this, 64-bit JIT would have to use the very slow boehm garbage collector, which sort of defeats the purpose of a JIT)
Friday, June 11, 2010
PyPy GSoC update: Most tests pass on 64-bit and 32-bit CPUs
Most JIT tests now pass on both 32-bit and 64-bit CPUs. However, there are some caveats:
- I made some changes that make the code no longer "RPythonic", which means you can't actually build a working, JIT-enabled, PyPy with this code quite yet.
- The rx86 module has accumulated some code duplication.
- There are a number of miscellaneous hacks I had to add that I'd like to get rid of somehow.
- 64-bit memory references aren't as efficient (in terms of code size) as they could be.
My plan for next week is to spend some time cleaning up the rx86 module, and then working on making the JIT translatable again. If by some miracle I get both of those things done next week, I'll start on the other two items. :-)
Monday, June 07, 2010
rx86 conversion complete, 64-bit work started
Last week saw the completion of the rx86 conversion: All tests pass, and the JIT works on i386 machines.
Last week I started on actually implementing 64-bit support. Mostly this will be an exercise in "magic removal": Locating those parts of the code that are only applicable to i386, and either adapting them to work with both i386 and x86_64 or else factoring those differences out into arch-specific classes.
One issue specific to x86_64 is the fact that most instructions cannot encode a 64-bit immediate value. I've worked around this by setting aside one register as a scratch register, and loading the immediate to that register first when a case like this arises. In the future I may try to optimize this to output a 32-bit relative displacement in the cases where that could work.
