On Wed, 12 Mar 2003 11:57:06 +0100 "Kevin D. Kissell" <[EMAIL PROTECTED]> wrote:
> As long as I have your attention, there's one other > oddity I've found in the MIPS JIT3 support that you > might be able to explain. In jit3-icode.h for MIPS, > we have > > #define HAVE_fakecall_constpool fakecall_xCC > > but in jit3-mips.def we have > > define_insn(fake_call, fakecall_xCC) > { > label* tol = const_label(2); > label* froml = const_label(1); > > froml->type |= Lfuncrelative|Llong16; > froml->at = CODEPC; > ldst_RRC(_LW, REG_ra, REG_gp, 0); > debug((" lw ra,?(gp)\n")); > > tol->type |= Lfuncrelative|Llong16; > tol->at = CODEPC; > ldst_RRC(_LW, REG_i25, REG_gp, 0); > debug((" lw t9,?(gp)\n")); > > insn_RRR(_JALR, REG_i0, REG_i25, REG_i0); > debug((" jr t9\n")); > > NOP(); > } > > Which follows the model of the i386 definition pretty > closely, and the i386 jit3-icode.h defines HAVE_fakecall, > not HAVE_fakecall_constpool. > > So...Is the situation in MIPS-land normal, should the > jit3-icode.h definition be for HAVE_fakecall instead > of HAVE_fakecall_constpool, or should the definition > in jit3-mips.def be of fake_call_constpool instead of > fake_call? On a hunch, I tried the modification to > jit3-icode.h, but the result was neither better nor worse > on any of the regression tests I'm studying. In order to be able to store large constants that cannot be inlined in the instruction stream, kaffe's jitter uses a per method constant pool (_not_ to be confused with the constant pool of a java class file). This constant pool is prepended to the generated native code, so it can be accessed with pc-relative addressing. Both, the HAVE_fakecall and HAVE_fakecall_constpool macros are meant to create a call to some function, but with a different return address than the current pc. As such, they get two labels as their argument, the label of the function to be called (const_label(2)) and the label of the return address (const_label(1)). If it is possible for the architecture (as with i386) to inline these labels into the instruction stream, the arch should define HAVE_fakecall, causing the labels to be inlined into the instruction stream. It is the responsibility of HAVE_fakecall to set the location of the labels (l->at). If it is not possible for the architecture to inline these labels into the instruction stream, it should #define HAVE_fakecall_constpool. This causes kaffe to put the labels into the beforementioned constpool. Again, it is the responsibility of HAVE_fakecall_constpool to set the location of the label (l->at) properly. Not sure whether this helps you any further , though :( And as always - I might be totally lost and completely wrong ;) Greetings, Helmer _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe