[kaffe] mips jit3 bug

[Kiyo Inaba]

Update, summary: "28 of 150 tests failed".
  (You have to interpret this message as "122 of 150 tests passed".
   We are salespersons for shoes who happened to arrive to an island
   in which no one wear shoes.)

OK, detailed info (maybe part 1)

There were several guys (including Kevin D. Kissell, Casey Marshall and
Yoshiharu Oba) who tackle to make mips jit3 workable in old good days,
and I misunderstood this port continues to be better than arm. When I
installed qemu for mips recently, I noticed this understanding is not
correct :-< Of course, I can switch to make m68k machines workable again
to have some reference for arm port, but the current lab where I am
working can not afford spaces for my lovely Macintosh, sigh. (I found
'aranym' is good candidate to make m68k port working without having
real hardware, but this is absolutely another story.)

So, before tackling arm's problem, I decided to tackle mips.
# Long introduction? Sorry about that...

The first bug is very easily found. According to the changelog, the rev
1.15 of config/mips/jit.h got 'Fixed some inefficiencies' mod, which in
reality, destroys trampoline code completely by filling one instruction
in the delayed slot. I am not so confident whether there are some mips
machines who can handle jump instruction without delayed slot or not,
but at least typical mips arch needs this delayed slot :-< My guess is
the guy who posted this 'fix' had never tested his fix prior to post,
and I don't think it's a good idea to put such proposed fix in to the
repository.

The second bug is harder to fix. Once I believe this is for converting
functions only (like cvtif, cvtfi) but later I noticed this has a close
relationship with very famous 'floating number registers numbering problem'.
('Famous' for whom? Only for me?)
Please read, http://www.mail-archive.com/kaffe@kaffe.org/msg04827.html
for example, you may understand the treatment of 'regno' are different
between mips or arm with m68k or i386, and the truth is 'do not reuse
regno for floating point'. Of course there is a way to reuse regno
and determine its type by some other way, (actually, this was the way
I tried first, but need so many fixes) assign unique regno for all
registers are the easier solution. If my memory is correct, I did 
similar fix about 10 years ago for m68k :-<

So, the last and biggest issue... (Which is usually called 'boss charscter'
or 'bosu-kyara' in Japanese gamers, by the way.) When you have exception
handling, 'callee saved' registers does not have automatic restoration.
Usually, 'callee' function saves these registers at the begining, and
restores them when it exits, but in the case of exception, the later
(function epilogue) shall never been executed. So the caller (or exception
handling function) shall properly restores these values back from callee's
stack. I am not so sure why with inproper handling of this, i386 or m68k
are ok, but at least this is not ok for mips or arm. Yes, the reason why
arm jit3 can not have GR to be set non zero comes from this problem!

Finding the problem and fixing it is sometimes much different, and this
is the case. For the time being my modification is heavily rely on the
structure of callee saved stack frame, and this mod does not have any
generality. I have to think better solution for this while I made the
next business trip ;-)

Anyway, the test result is
    http://www.kaffe.org/~inaba/kaffe-1.1.8-0918.log
and the patches against 1.1.8 for this log is
    http://www.kaffe.org/~inaba/kaffe-1.1.8-0918.patch

For the next 2 monthes (maybe), I again have not enough time to play
with them but hope someone may be interested for my findings. Except
for the last ugly fixes, I will put back to the repository for my
fix, before I was fully involved in the real business.

Kiyo