Oh well, I am working through similar issue. To make Kaffe workiing
somehow set into configuration
'--with-engine=interp'. It'll solve your problem but makes your kaffe
working terrible slowly. The real problem is somewhere into JIT3 module
and it is a memory management issue. I've sent
A better question might be whether Kaffe's JIT supports
any architecture other than x86. I had it 98% working
for MIPS under Linux a couple of years ago, failing only
a handfull of tests and working well enought to run
the embedded caffeinemark (with very good results,
I might add), but
This may have nothing to do with your problem,
but
note that the Lexra processors aren't really
100%
MIPS compatible - they don't implement the
"load
left" and "load right" instructions used to
handle
unaligned (typically, packed) data. Unless the
OS
It's my understanding that Jazzelle requires some enabling software hooks
that are only available under paid, non-open-source license from ARM.
But then again, I work for one of their competitors, and may have been
misinformed. Anyone from ARM on this list?
- Original Message -
From:
As a MIPS guy who beat his head against the wall of the broken JIT3
a couple of years ago, I'm really interested in this, and I'm really concerned
that I never saw the original message from Makolaj to which the message
below is a reply, though I did see Timothy's message explaining how to
manually
The threads about MIPS jit with Kevin from 2002 (March-June, I
believe), 2003, and 2004 with him Casey also may contain some patches
that haven't been applied yet. If you, or Casey are aware of patches
that I have let slip under the floor, please point me to URLs, and I'll
be very glad
The one serious comparison I ever made
showed the Kaffe JIT to be almost 20 times
faster than Kaffe INTRP, but that was on
a benchmark that was very favorable to JITs.
- Original Message -
From: Paul [EMAIL PROTECTED]
To: kaffe [EMAIL PROTECTED]
Sent: Tuesday, June 29, 2004 2:59 AM
Casey Marshall wrote:
Ok, more info:
1) __mipsGetNextFrame tries to determine the previous frame's
program counter and frame pointer, based on the current pc and
fp and walking up the code.
[Begin hooting of alarm klaxon]
2) When it tries to do this when walking back from a `soft'
Casey == Casey Marshall [EMAIL PROTECTED] writes:
Yeah, ok, I was pretty wrong with the implementations of fcmpl and
friends. I think I have it sorted now.
One question about that: Did you implement those operations because
you thought it would be good for performance, or did you have the
Kevin == Kevin D Kissell [EMAIL PROTECTED] writes:
Kevin Do you have decent documentation on the MIPS ABI?
The gcc web pages have links to all kinds of stuff like this:
http://gcc.gnu.org/readings.html
For MIPS it points to:
http://www.mips.com/publications/
I don't
Notice the difference? The kaffe.def calls do the pushargs before the
begin_func_sync and the icode.c calls do the pushargs after the
begin_func_sync. Arghh!!
Now, if only I knw what begin _func_sync really meant, I'd know
whether that was really a problem! ;o)
I could believe that
Kevin The code generation in jit3-mips.def is going to generate all
Kevin sorts of broken code if you allow those values to go above 31,
Kevin I think. There is no masking of the shifted values as the
Kevin instruction words are being created.
I masked all the registers when generating
I must have still been confused about using CVS properly back then.
Could you repost the patch, so that I can check it into CVS HEAD?
The system I use for kaffe development is down, and I'm up against some
other deadlines that make it far from certain that I'll get around to reconstructing
the
Right now these are my suspicions/ideas:
* The register managment code (spills/allocs/restores) appears to
have changed to the point where it is incompatible with the way
the MIPS backend presents its registers. Specifically, it looks
like the register code likes to assume
But...but...the rreg_ideal variants are just invocations of slotRegister
(in kaffevm/jit3/registers.c) with a non-NOREG value in the idealreg
parameter. While having the NOREG value (i.e. using rreg_int() in
the examples below) will make it more likely that there's no need to
realocate and
So this actually doesn't surprise me much: there appear to be bugs in
the way float parameters are passed (and this, like isNaN, is static,
so this probably limits the possibilities of what's wrong).
In the period before kaffe 1.1.0, I identified a FP parameter passing
problems in JIT3 for
Are you trying to use the JIT? So far as I know, the JIT3 engine is still
broken for MIPS/mipsel, and generates code which ends up dereferencing
uninitialized pointers embedded in internal data structures. There have
been times when building the development CVS sources would produce
a
Sure looks and sounds like a memory leak to me...
- Original Message -
From: jrandom [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 21, 2003 10:31 AM
Subject: [kaffe] bug report: core dump after eating cpu (gc related?)
Hi all,
After the last round of gc updates,
No one seems to have replied to this message a
month ago. I missed it at the time.
First of all, I'm really suprised to see that
you're running on an MIPS R6000. That's
an multi-chip ECL CPU from the 1980s that was
mostly installed in CDC servers.
Is that really correct? The R6000 was the
I have noticed in libnative.la it sets the variable dependency_libs.
For my intel static build this points to an empty directory, but for
the mips build it points to the directory
/opt/hardhat/devkit/mips/lexra_fp_be/target/usr/lib
which contains many libraries; there is not enough space
I am working on issues regarding porting of Kaffe on
Cray machine and I was just wondering if there are
some suggestion regarding that, Cray is a 64 bit
machine so the obvious changes will be related to
porting kaffe on 64 bit machine.
What kind of Cray machine are you talking about
here?
Our of curiousity, I configured the MIPS/Linux interpretive kaffe
with --disable-debug, for speed, and ran the Embedded CaffeieneMark
benchmark. Comparing the result with an equivalent 1.0.7-based build,
we can see that a bunch of things have improved a little, some things
have stayed the same,
Our of curiousity, I configured the MIPS/Linux interpretive kaffe
with --disable-debug, for speed, and ran the Embedded CaffeieneMark
benchmark. Comparing the result with an equivalent 1.0.7-based build,
we can see that a bunch of things have improved a little, some things
have stayed
Could you please check confirm that the 4 regression tests
which succeed on alpha-linux are the same 4 that succeed
with MIPS/Linux under jit3, i.e.
HelloWorldApp.class.save
CatchLimits.class.save
TestFloatDouble, and
ThreadStop?
The 133 out of 137 number just seems like more than a
coincidence.
Could you please check confirm that the 4 regression tests
which succeed on alpha-linux are the same 4 that succeed
with MIPS/Linux under jit3, i.e.
HelloWorldApp.class.save
CatchLimits.class.save
TestFloatDouble, and
ThreadStop?
FYI, these tests almost always succeed (They have
With ./configure --with-engine=intrp, we get
All 137 tests passed
With the default configuration, which is jit3, however,
HelloWorldApp.class.save and CatchLimits.class.save
passe the make check, but the local compilation of
almost all the regression
From the traces you've sent in this thread, I would assume
that this assertion failure only occurrs when you get a
NullPointerException, is that correct?
The past two times, that seemed to be the case. However, it's
different today, as shown below.
There are actually two
What I'd dearly like some help in understanding is:
1) Why on earth is a distinct register pair needed for
each frame-to-frame copy of the arguments?
The lifetime of those registers is limited to the
reload/push sequence.
2) How can I either (a) prevent f12/f14 from being
I'm still fumbling and grepping around, but for the moment it
certainly looks to me as if whoever wrote the jit3-mips.def
code is using the higher-level register management code
inappropriately, with the consequence that there is a lot
of memory traffic that could be eliminated by the simple
I'm still wrenching intermittently on the MIPS JIT code,
without a whole lot of success so far. Today, I was looking
at why the TestNative regression test was failing, and I finally
understand why. I just don't see what can be done about it.
Perhaps one of you could help me.
The TestNative test
A few days ago, I wrote:
Correct, the intrp engine works fine (albiet *SO* much slower).
The test are now passing.
Kevin, since you seem to implicated as being the MIPS assembly guru, is
there any way that I can assist with the JIT3 engine fixed?
Maybe. See below.
Since our
Note that the problems you reported on Feb 3 were
not
the same as those that I'm seeing with the
MIPS/Linux
platform. In your case, you had 3 regression
failures.
I had the same problem :
java/lang/Double.java:25: error:Double literal
4.9406564584124654418e-324 is too small
Helmer Kraemer writes:
In order to be able to store large constants that cannot
be inlined in the instruction stream, kaffe's jitter uses
a per method constant pool (_not_ to be confused with the
constant pool of a java class file). This constant pool is
prepended to the generated native
I've been looking at the problem with JIT3 on MIPS platforms,
and have come across something distinctly suspicious that I know
how to fix in the abstract. I could use some guidance from other
more experienced JIT hands as to how to best deal with it in practice.
In the generated function
Never mind. It looks as if there was a bug in the JIT diagnostic trace
that isn't in the generated code itself. Note:
/* Save callee save regs */
for (i = 0; i 8; i++) {
ldst_RRC(_SW, REG_s0+i, REG_fp, -SLOTSIZE*(5+i));
debug((sw
Interestingly enough, if I run either an interpretive kaffe 1.0.7
plus my MIPS patches, or an interpretive MIPS build of the
current kaffe.org CVS sources on a little-endian MIPS/Linux box
(a MIPS Malta board with a 5Kc processor on it), I get::
[EMAIL PROTECTED] BUGS]$ javac Test.java
[EMAIL
Correct, the intrp engine works fine (albiet *SO* much slower).
The test are now passing.
Kevin, since you seem to implicated as being the MIPS assembly guru, is
there any way that I can assist with the JIT3 engine fixed?
Maybe. See below.
Since our application is running on an
First, an unmodifled Kaffe.1.0.7 release source
tree
will not give you a
working MIPS version of Kaffe.
The necessary patches to the release sources should
be in
ftp://ftp.paralogos.com/pub/kaffe/mips/kaffe-1.0.7.patch_kevink_021001
The changes were also merged with the
Kaffe.org
CVS
Note that some of the stuff that I filed as MIPS patches
is either identical or equivalent to some of Dylan's PS2
patches - indeed, one of the reasons I got seriously
engages was that I could see that Dylan was labeling
fixes PS2 that were actually pretty generic to MIPS
(that's not a bad
Let's say I have a shared library and a static library.
And if i call a variable of a static library from a shared library
the value which is previously set through a static library, the same
copy is not there in the shared library. I mean every variable
in the static library has a copy
]
To: [EMAIL PROTECTED]
Sent: Thursday, October 10, 2002 3:42 AM
Subject: Re: [kaffe] MIN_VALUE of java.lang.Double
In message Re: [kaffe] MIN_VALUE of java.lang.Double
on 02/10/09, Kevin D. Kissell [EMAIL PROTECTED] writes:
I don't have the revised Java Language Specification handy to
see
From: Patrick Tullmann [EMAIL PROTECTED]
Kevin wrote:
Alas, while the resulting kaffe builds and executes a lot of code,
there are more, not fewer failures for the JIT regression tests, and
even the interpretive build fails quite a few (12 out of 117)
The interpreter seems to have a
From: Patrick Tullmann [EMAIL PROTECTED]
Kevin wrote:
Alas, while the resulting kaffe builds and executes a lot of code,
there are more, not fewer failures for the JIT regression tests, and
even the interpretive build fails quite a few (12 out of 117)
The interpreter seems to have a
43 matches
Mail list logo
