On Fri, 2004-10-08 at 11:38, Dalibor Topic wrote:
> Mikolaj Habryn wrote:
> i went to bed before you popped in on irc last night :(

Living in Australia does make one timezone disadvantaged!

> It would take a bit of excerising the 
> jit regression tests and debugging by a motivated hacker to fix it. 
> Would you be interested in having a go at it?

Decidedly. I offered to do a talk about running web applications on this
box in a few weeks and it's currently looking just a little embarrassing
:)

> You could try crosstools, I believe that it has a mips toolchain. I 
> don't know if specialized gdb is a part of it, though. You could ask on 
> the linksys lists about pointers for a gdb capable of dealing with it.

That particular problem was caused by the debian patches to gdb 6.1, for
the archives. A stock 6.1 builds just fine for a mipsel target.

> The other very welcome thing would be to clean up the compiler warnings 
> in config/mips directory.

Argh. I'm in a twisty little maze of macros, all alike. Is it a problem
that there's a bunch of HAVE_*_ref functions aliased to HAVE_*_int? Lots
of 'redundant redeclaration' warnings for those, but it all looks
harmless.

The cast warnings can be removed with something like the following (for
consideration only, not to be applied, not endian-sensitive)

--- kaffe/kaffe/kaffevm/jit3/funcs.c.~1~        2004-07-12 05:03:04.000000000 +1000
+++ kaffe/kaffe/kaffevm/jit3/funcs.c    2004-10-09 09:25:27.000000000 +1000
@@ -57,11 +57,25 @@
 #define        QOUT(v) do { 
DBGEXPR(JIT,(void)printCodeLabels(),0),*(uint64*)&codeblock[CODEPC] = v; CODEPC += 8; 
} while (0)
 #else /* !  defined(KAFFE_VMDEBUG) */
 #undef OUT
+#define _mjh_OUT(v, count) do { int _mjh_i; \
+    for(_mjh_i = 0; _mjh_i < count; _mjh_i++) { \
+      codeblock[CODEPC] = (((v) >> (8 * _mjh_i)) & 0xff); \
+      CODEPC++; \
+    } \
+  } while(0)
+#if 0
 #define        OUT(v)  do { codeblock[CODEPC] = v; CODEPC++; } while (0)
 #define        BOUT(v) do { *(uint8*)&codeblock[CODEPC] = v; CODEPC++; } while (0)
 #define        WOUT(v) do { *(uint16*)&codeblock[CODEPC] = v; CODEPC += 2; } while (0)
 #define        LOUT(v) do { *(uint32*)&codeblock[CODEPC] = v; CODEPC += 4; } while (0)
 #define        QOUT(v) do { *(uint64*)&codeblock[CODEPC] = v; CODEPC += 8; } while (0)
+#else
+#define        OUT(v)  do { codeblock[CODEPC] = v; CODEPC++; } while (0)
+#define        BOUT(v) _mjh_OUT(v, 1)
+#define        WOUT(v) _mjh_OUT(v, 2)
+#define        LOUT(v) _mjh_OUT(v, 4)
+#define        QOUT(v) _mjh_OUT(v, 8)
+#endif
 #endif /* defined(KAFFE_VMDEBUG) */

 #include "jit.def"

There's a bunch of 'no previous prototype' for fdiv_*, cvt* and
call_xCC, which appears to be due to the appropriate HAVE_* macros not
defined in mips/jit3-icode.def, despite the functions themselves
existing. There's an annotation against some of the cvt functions saying
that they're done by hand instead, which makes the presence of the
implementing functions a little bit of a puzzle. *shrug*

Some of the 'cast doesn't match prototype' warnings are downright scary
and I don't understand how the code can work with them, but they don't
appear to be MIPS-specific anyway.

That's the bulk of the warnings, I think. There's some missing
initializers which seem to be due to y'all being a bit lazy with
array-of-struct initializations ;)

> Finally, do all regression tests pass for you with interpreter engine?

Erm - I'm trying to run these, but, frankly, it's all a bit puzzling. My
basic problem is that I'm cross-compiling on my x86 desktop and
transferring binaries on the Linksys box to run. Said box having 8 MB of
flash and 32 MB of RAM, I can't actually build on it or access the full
build tree.

So, trying to run them, deducing environment setup etc. from scripts.
internal/jitBasic appears to work, but doesn't actually seem to do
anything. stracing it on x86 also doesn't appear to do anything
(anything with the list of classes passed in TEST_CLASSES, anyway), so
no idea what's going on there.

Haven't worked out how to run test/regression yet. test/jni/jniBase is
okay, the other two in jni/ fail with FindClass problems, but that's
probably my setup.

Hmm. Having noticed KAFFE_VMDEBUG, I'll go play with that for a while.

m.


_______________________________________________
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

Reply via email to