[kaffe] amd64 jit progress
eta at lclark.edu
Fri May 27 22:44:20 PDT 2005
Some of you may have heard me talking about amd64 jit on #kaffe. I've
made a significant bit of progress, but I thought I'd post just in case
I wander off to X again, so this doesn't get lost.
I'm failing jitBasic at ParameterizedLogicalMethods.int_bar_int(I)I, but
before a recent regression (which occurred while adding the op_* macros
for repeated opcode outputs) I had made it to tableswitch before falling
I've had to make a few changes to jit internals. One is adding
lslot_slot_lslot() to jit3/basecode.c, due to new code being exercised
(HAVE_store_long). However, that made me note that I think basecode.c
has some bugs. It looks to me like the functions starting with
"lslot_" (dst is a long) should be using slot_alloc2tmp and move_anylong
in the TWO_OPERAND code, instead of the non-long equivalents. Does this
jit3/funcs.h was missing a number of prototypes.
jit3/registers.h was missing rreg_ideal_ref, to correspond to other
jit3/icode.c is using something cast through an integer as a pointer.
That's bad news, I think. However, I haven't quite figured out if the
"ref" type is supposed to always be a pointer or not.
One thing I've noticed, while looking at tableswitch issues, is that a
register used as an int will then be added to a ref, without being
spilled and reloaded as a ref. On amd64, that int has all zeroes in the
top 32 bits of the reg, so the addition of a negative number ends up
adding a large positive number. Shouldn't things be spilled and
reloaded between use as different types?
Also, IWBNI jitBasic.c was aware of what the return type for failed
functions was and printed it as the right type. I haven't figured that
Anyway, here's the patch, in one huge pile. I'm going to go play with X
for a bit.
Eric Anholt eta at lclark.edu
http://people.freebsd.org/~anholt/ anholt at FreeBSD.org
More information about the kaffe