[kaffe] JIT3 Questions
Timothy Stack
stack at cs.utah.edu
Mon Mar 10 08:10:02 PST 2003
ops, sorry about the previous email....
>
> I've been looking at the problem with JIT3 on MIPS platforms,
> and have come across something distinctly suspicious that I know
> how to fix in the abstract. I could use some guidance from other
> more experienced JIT hands as to how to best deal with it in practice.
>
> In the generated function prologue in config/mips/jit3-mips.def,
> we have...
>
> =============== Begin Source Fragment ================
> define_insn(prologue, prologue_xxC) {
> label* l;
> Method* meth;
> int limit;
> int haveint;
> int j;
> int i;
> int fi;
> int a;
>
> /* Max_args is the maximum number of arguments this method pushed
> * onto the stack (allowing for alignment). We always allow for
> * the 4 argument registers.
> */
> max_args = NR_ARGUMENTS;
>
> debug_name(("prologue:\n"));
>
> /* Save and move sp, fp & r31 */
> insn_RRR(_ADDU, REG_i1, REG_fp, REG_i0);
> insn_RRR(_ADDU, REG_fp, REG_sp, REG_i0);
>
> /* Remember where the framesize should go */
> l = (label*)const_int(1);
> l->type = Lframe|Labsolute|Lgeneral;
> l->at = (uintp)CODEPC;
>
> insn_RRC(_ADDIU, REG_sp, REG_sp, 0); /* framesize */
> ldst_RRC(_SW, REG_ra, REG_fp, -4); /* save $ra */
> ldst_RRC(_SW, REG_i1, REG_fp, -8); /* save old $fp */
> ldst_RRC(_SW, REG_gp, REG_fp, -12); /* save $gp */
>
> debug((" mov i1,fp\n"));
> debug((" mov fp,sp\n"));
> debug((" addiu sp,sp,-framesize\n"));
> debug((" sw ra,-4(fp)\n"));
> debug((" sw i1,-8(fp)\n"));
> debug((" sw gp,-12(fp)\n"));
>
> #if defined(USE_JIT_CONSTANT_POOL)
> /* Get pointer to constant pool */
> insn_RRR(_ADDU, CONSTPOOL_BASE, REG_i25, REG_i0);
> ldst_RRC(_SW, REG_gp, REG_fp, -16);
> debug((" move gp,i25\n"));
> debug((" sw gp,-16(fp)\n"));
> #endif
>
> /* Save callee save regs */
> for (i = 0; i < 8; i++) {
> ldst_RRC(_SW, REG_s0+i, REG_fp, -SLOTSIZE*(5+i));
> debug((" sw %s,%d(fp)\n",regname(REG_s0+i),-SLOTSIZE*(4+i)));
> }
> ================== End Source Fragment =======================
>
> Now, as it happens, the offset generated to save register $16, i=0 in the "for"
> loop above, ends up being -16. Which is to say, if USE_JIT_CONSTANT_POOL
> is defined (which it is by default), the same storage location in the frame is used for
> both $16 and $25. Unfortunately, if I undefine USE_JIT_CONSTANT_POOL
> in jit.h, where it is defined, the resulting JIT doesn't work. In the abstract, it should
> be a simple problem of upping the frame size by 8 bytes (8 not 4, to preserve alignment),
> and using a new offset for $25. However, in the code above, the frame size seems
> to be generated automagically to replace a zero constant in the instruction generation
> macro with some method-dependent frame size that I speculate somehow already
> allows for some number of saved registers in the frame. Where is this defined?
I think the 'label' stuff does what you want. In the mips case the code
that does the replacement is defined in jit.h:
#define LABEL_Lframe(P,V,L) \
{ \
int framesize = FRAMESIZE; \
assert((framesize & 0xFFFFF000) == 0); \
*(P) = (*(P) & 0xFFFF0000) | ((-framesize) & 0xFFFF); \
}
...
#define EXTRA_LABELS(P,D,L) \
case Lframe: LABEL_Lframe(P,D,L); break; \
...
And the label is setup with this line from the prologue:
/* Remember where the framesize should go */
l = (label*)const_int(1);
l->type = Lframe|Labsolute|Lgeneral;
l->at = (uintp)CODEPC;
Then, when the jitter is doing post processing of the code it will
execute the LABEL_Lframe macro to replace the value at 'l->at'.
> Is the relationship between the saved register context and other values on the
> frame fixed, such that I cannot insert a new storage element between them?
Not really. You determine the layout of the stack frame so you can do
whatever you want. Its mostly a matter of tweaking the label macros
appropriately.
> I've been trying to code something really sneaky to save/restore the register
> "behind the back" of the rest of the frame management code in a sort of
> sub-frame, but the first cut at that doesn't work, and frankly, it's not what
> I would consider to be wholesome coding.
hmm... Can it not be worked into the existing frame management stuff?
This would benefit other architectures as well.
> How can I adjust the total frame size to add a new element?
Just pump the 'framesize' value in the LABEL_Lframe() macro.
> Kevin K.
tim
More information about the kaffe
mailing list