-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Kevin" == Kevin D Kissell <[EMAIL PROTECTED]> 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 || [EMAIL PROTECTED] -----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----- _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe