[kaffe] mipsel JIT3

[Casey Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Kevin" == Kevin D Kissell <kevink at mips.com> writes:

>> I must have still been confused about using CVS properly back then.
>> Could you repost the patch, so that I can check it into CVS HEAD?

Kevin> The system I use for kaffe development is down, and I'm up
Kevin> against some other deadlines that make it far from certain that
Kevin> I'll get around to reconstructing the environment and the patch
Kevin> any time soon.  I'd strongly suggest that Casey try the
Kevin> following on his sources, rather than wait for me to get around
Kevin> to it.

Kevin> Go into kaffe/config/mips and edit jit.h.  In the definition of
Kevin> REGISTER_SET (which goes on for a ways) where you see the
Kevin> string RFD in the rows for the FP argument passing registers
Kevin> f12 and f14, change that to "RFD|Reserved".  It would also be
Kevin> wise to change "RIL" to "RIL|Reserved" in the rows for integer
Kevin> registers i4, i5, i6, and i7.  This will prevent a spill bug
Kevin> which causes arguments passed to JIT functions to be clobbered.
Kevin> Or at least it used to in the 1.0.7+ sources.

This doesn't quite get around my initial problem (spilling a register
with no ctype).

Right now these are my suspicions/ideas:

   * The register managment code (spills/allocs/restores) appears to
     have changed to the point where it is incompatible with the way
     the MIPS backend presents its registers. Specifically, it looks
     like the register code likes to assume that the `regno' field is
     an index into the reginfo array, which isn't true for MIPS (it
     numbers its int registers from 0 to 31, then its float registers
     from 0 to 31 again).

     *Maybe* the register functions need to be a little smarter, by
     first choosing any register whose regno field matches the ideal
     number, then choosing the best register out of that set that fits
     the other criteria best.

     (This is all crash-course hacking I'm doing, so I might be
     totally mistaken).

   * If I renumber the float registers from 32 to 63, the spill
     problem doesn't happen, but I get a bus error when the `call'
     instruction is reached. This happens because the constant pool
     code tries to restore register gp from fp, and it looks like fp
     gets clobbered before this can happen.

   * If I disable the JIT constant pool, I get a segmentation
     fault. This happens because load_constant_int writes the
     return value of Float.isNaN(I)Z into register a0 (aka i4), and
     back in Float.toString [1] this register is used to reload itself
     (i.e. `lw a0,24(a0)'). This fails because that register now
     contains the result of a boolean method (1 or 0).

     So, it looks like there are some missing restores. These
     registers are spilled when they are used, but aren't restored.

At any rate I'm still optimistic that this code is fixable without too
much headache.


[1] The stack that leads to this error is this:

        at java.lang.Float.toString(Float.java:98)
        at java.lang.StringBuffer.append(StringBuffer.java:432)
        at java.util.Hashtable.<init>(Hashtable.java:267)
        at java.util.Hashtable.<init>(Hashtable.java:122)
        at java.util.Properties.<init>(Properties.java:31)
        at java.util.Properties.<init>(Properties.java:27)
        at java.lang.System.<clinit>(System.java:44)
        at java.lang.Throwable.<clinit>(Throwable.java:403)
        at java.util.HashMap.<init>(HashMap.java:255)
        at java.util.HashMap.<init>(HashMap.java:113)
        at java.lang.ClassLoader.<clinit>(ClassLoader.java:78)

   And this looks very bad because I think the check
   !(DEFAULT_LOAD_FACTOR > 0) fails, which is horribly, horribly
   wrong.

- -- 
Casey Marshall || rsdio at metastatic.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQFASM/lgAuWMgRGsWsRAjKZAJ0WAyT+NrzFLdOwZ3TBdEJi3+PMjACdE8lZ
n9Yqzd9Q8gO4I4aiCKrrKG8=
=QNt2
-----END PGP SIGNATURE-----