[kaffe] mipsel JIT3
stack at cs.utah.edu
Fri Mar 5 16:20:04 PST 2004
> But...but...the "rreg_ideal" variants are just invocations of slotRegister
> (in kaffevm/jit3/registers.c) with a non-NOREG value in the idealreg
I know, I've been trying to figure out what I was talking about... Gotta
remember to be more explicit next time.
> While having the NOREG value (i.e. using rreg_int() in
> the examples below) will make it more likely that there's no need to
> realocate and clobber a register, it doesn't guarantee it. And if there
> *is* a need to reallocate, the same path will be taken for both the
> ideal and non-ideal cases, the only difference being that in the
> non-ideal case it will reallocate and clobber the least-recently-used,
> rather than the specifically requested register.
*shrug* The only difference I can see is that allocRegister() behaves
differently if there is an idealreg and when there isn't.
The last part of the comment about the function sync is something I never
noticed before, "kaffe.def" and "icode.c" disagree about the order of the
calls. Here's an excerpt from kaffe.def:
/* Push arguments & object */
build_call_frame(method_sig(), stack(idx), idx);
/* Call it */
low = method_returntype();
/* Pop args */
And, now from icode.c:
softcall_checkcast(SlotInfo* objw, SlotInfo* objr, Hjava_lang_Class* class)
/* Must keep 'obj' */
Notice the difference? The "kaffe.def" calls do the pushargs before the
begin_func_sync and the "icode.c" calls do the pushargs after the
> I could believe that
> the hack below may have helped some bug that PPC was seeing,
> and it might help MIPS as well, but if rreg_ideal_int() can be fatal,
> I would think that rreg_int() could be as well.
Yeah, I might've just gotten lucky somehow...
More information about the kaffe