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!
Yeah :) Otoh, it means you can have a great new year's eve, and still phone your friends back in germany to wish them a nice evening :)
Are you in Sydney, by chance?
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 :)
Great! Pending self-embarassment is a wonderful motivator :)
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.
Yeah, they seem harmless. But cleaning them up would still be welcome, as then the big mistakes would stick out more :)
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"
Very nice trick, I like it. Makes me wonder how that would work with endianness issues. It would be also interesting to test how much that would impact the speed of jitting. Adding a tiny piece of doxygen-ish documentation what the _mjh_OUT macro does would be cool, too. Please, please :)
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*
Uh. Weird. I've seen stuff like that when I was fixing some mips jit breakage, but didn't want to touch it without access to a mips. :(
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.
Maybe these warnings should be the priority, actually.
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 ;)
coughpleasesendapatchcough. :)
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.
Would NFS over wireless to your dev box work?
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.
I've CC:ed Tim & Guilhem, who've both used that code to debug jitters. Maybe they can give you a brief tutorial :)
cheers, dalibor topic
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
