[kaffe] JIT3 Questions

[Timothy Stack]

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