Initial X86 64 support
Description
Environment
is depended upon by
is superceded by
Activity
Ian Rogers November 25, 2008 at 11:07 AM
The code base now has a large amount of the x86 64 compiler implemented. The implementation differs substantially from that of Frederick De Schrijver, Arun Thomas and Dan Williams so I consider it a separate work. Differences include:
1) it implements JNI - essential to actually be of use
2) the assembler changes are different in that a helper routine is used, registers are strongly typed, we don't always generate REX prefixes
3) the baseline compiler changes are more performant by using short opcode instructions (push/pop), abstracting stack adjustments and having strongly typed registers - the work also leverages our previous work on SSE support that the old x86 64 work couldn't
4) tableswitch is radically overhauled for performance and now makes use of RIP addressing to get at the offset table
5) the baseline compiler changes only minimally use "if (VM.BuildFor32Addr)" so that code generation has coverage testing when doing 32bit regression testing
As I didn't use the previous work for reference there are many other subtler differences. I wanted to state this to make the origin of the contribution clear.
We have a tar ball in the research archive:
http://sourceforge.net/tracker/index.php?func=detail&aid=1590217&group_id=128805&atid=723235
which would add baseline compiler support for the Jikes RVM on x86 64. The patch is quite straight forward. Firstly it extends the assembler to generate the REX prefix byte. The REX prefix occupies 16opcode locations that on IA32 encode the now deprecated inc and dec a register single byte opcodes. The prefix uses 1bit as a possible size override, and then either 2bits to either extend the source and destination register to be one of 16registers, or 3 bits to extend the base, index and source/destination register. The changes to the baseline compiler are minor in the patch. Importantly it doesn't modify the behaviour of dup and other bytecodes that assume an object reference will fit into a single stack slot. Therefore the patch is only safe if all references are in the bottom 4GB of memory, but this should be straightforward to enforce until we can handle dup and similar bytecodes properly by redesigning the baseline compiler.
I'd like to merge this work as a step toward getting x86 64 support going. We need contribution statements from Frederik De Schrijver (the University of Ghent), Arun Thomas and Dan Williams (the University of Virginia).