[kaffe] mipsel and jit3

[Dalibor Topic]

Mikolaj Habryn wrote:
> 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