[kaffe] mipsel JIT3

[Timothy Stack]

> Hi,

hi,

> I've started hacking around the JIT3 sources, and have found at least
> the first point of failure: spill() in jit3/register.c is being called
> in such a way that reginfo[s->regno].ctype is 0, i.e. it's type field
> is unset. This causes an immediate ABORT because there is (obviously)
> no way to spill an untyped register. s->regno has always been 12 when
> this happens, and this is the first time this register is ever
> spilled.

What method is being jitted?  Does the MIPS jitter pass all of the tests
in the test/internal directory?

> Along the culprit's trail is a call to slotAlias (jit3/machine.c),
> which increments the reference count of reginfo[12], but leaves the
> ctype field untouched, so when that register is requested (push_float
> does this) it will be incorrectly spilled.

Hmm, I'm a little concerned that the register set specification
(REGISTER_SET in jit.h) is not quite right.  Specifically, the regno 
fields are not unique, but the jitter is using them as an index into 
reginfo[].  Looking at the other jitters, I see both cases:

  The ARM and MIPS ones reuses the regno numbers.
  The i386, alpha, m68k, powerpc, and probably a few others use unique 
    numbers.

The safest bet is probably to renumber them and make sure any code that 
outputs floating point does the correct thing.

> So far I can't tell whether or not this is the fault of the 
> mips-specific code, since I can't really get a stack trace far back 
> enough.

This isn't really related, but are you using the xdebugging 
infrastructure (see FAQ/FAQ.xdebugging)?  I've found it quite helpful when 
working on the jitter.

> My suspicion is that the mips code doesn't properly free a register or
> slot, but I wanted to ask if anyone here has any idea why this
> situation might come up.

Seems like integer register twelve was being used at the same time as
floating point register twelve and there was some kind of conflict.  But,
it seems a little unlikely to have that many registers active...  I'd have
to see what code was being generated.

> Secondly: if I hack slotRegister() to fill in ctype if it is blank, I
> get further, but then Float.isNaN returns false when given NaN,
> causing toCharArrayWithPrecision to barf. This has got to be a
> mips-specific bug.

Well, the most used code is the i386 stuff, which is pretty easy since it
has so few registers.  So, it is very possible that there is brokeness
that has not been noticed yet.

> Cheers,
> 
> - -- 
> Casey Marshall || rsdio at metastatic.org

tim stack