[kaffe] More JIT3 Questions

[Kevin D. Kissell]

I'm still wrenching intermittently on the MIPS JIT code,
without a whole lot of success so far.  Today, I was looking
at why the TestNative regression test was failing, and I finally
understand why.  I just don't see what can be done about it.
Perhaps one of you could help me.

The TestNative test invokes some native functions with
large numbers of arguments.  In emitting the JIT code
that will call the test functions, we thus need to copy the
arguments onto the stack frame, and, in the MIPS ABI,
put the first few in registers, according to some moderately
baroque rules.  The "prologue" MIPS JIT3 sequence uses 
the (generic) preloadRegister() function to bind/reserve the 
register.  The arguments are then copied "up" the stack,
using (in the interesting case) push_double. Where a fixed
register is used, register_reserve() is called on it.  For the
arguments passed on the stack, rreg_double(1) is used.
But for some reason, for each double-precision
value, a fresh pair of FP registers seems to be allocated. 
This skips over the 2 (reserved) FP argument register pairs 
(f12/13 and f14/15) *until* the allocator hits the end of
the FP register file (f30/31).  At that point, f12/13 get
recycled for the copy.  A spill_double *is* invoked, as
one would hope, before the register contents are destroyed
by the copy.  But there is never any restore, so the first
2 arguments are trashed whenever the JIT deals with a
large number of FP arguments.

What I'd dearly like some help in understanding is:

1) Why on earth is a distinct register pair needed for
     each frame-to-frame copy of the arguments?
     The lifetime of those registers is limited to the
     reload/push sequence.

2)  How can I either (a) prevent f12/f14 from being reallocated
      when I'm "out" of FP registers, or (b) force the value to be
     reloaded after a spill?  There is code to cause a reload if
     the *slot* associated with the value is flagged for rread
     use, but in this case the "slot" is the argument area of the
     incoming frame, which, empirically, does not seem to be
     so tagged.

Any clues would be greatly appreciated.

            Kevin K.