> > 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
> > I would appreciate if you could share some thoughts and/or
> > knowledge about Jazelle and its performance and adoption.
>
> For all I know, Kaffe doesn't use it, so it's hard to say what its
> performance impact is. I don't know any free software VM or compiler
> toolchain actually using
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 subsequen
(B
(B
(BThis may have nothing to do with your problem,
(Bbut
(Bnote that the Lexra processors aren't really
(B100%
(BMIPS compatible - they don't implement the
(B"load
(Bleft" and "load right" instructions used to
(Bhandle
(Bunaligned (typically, packed) data. Unless the
(BOS
(Bk
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: "
> 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
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 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
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' C
That's the Evil Maxist Thoughts trap. Someone was questioning
capitalism too close to the machine. ;o)
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 12, 2004 12:44
Subject: [kaffe] need help. what is "EMT trap"?
> Hello,
>
> i cross-compil
> Kevin> That's not at all surprising. The trickiest thing that I had
> Kevin> to fix to get the kaffe interpreter working for MIPS was to fix
> Kevin> the calling convention stuff. Argument passing in MIPS *is*
> Kevin> pretty baroque, and worse, there are variants that we'll have
> Kevin> to de
> >>>>> "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
&
> Kevin> One question about that: Did you implement those operations
> Kevin> because you thought it would be good for performance, or did
> Kevin> you have the impression that the JIT was failing because of
> Kevin> their absence? They did not seem to be broken when I was
> Kevin> working on jit3
> > "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 y
> >> the correct fix is probobly to fix register.c to not assume that
> >> regno is an index into reginfo.
>
> Timothy> I'm hesitant to mess with the register allocator too much,
> Timothy> especially since it might break the other backends...
I have a very hard time believing that any backend co
> 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 gener
> 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 believ
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 clobb
> 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 a
> 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
th
> 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 M
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 JIT-enable
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 upd
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
Register allocation in JIT3 seems to deliberately allocate
cyclicly through the full available register set. This was
presumably so that the last N values would always be
available for re-use. Unfortunately, this includes registers
used as temporary intermediate registers which will never,
ever,
> 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 s
I would think that the biggest problem is
going to come from a lack of GNU infrastructure.
Do you have gcc and gnu make working on that
platform? If you've got that in place,
given that 64-bit ports have already been done, an
interpreter port ought not to be too
difficult. A JIT3 implementa
> 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
her
> > 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 s
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.
> > 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
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, an
> could you do a
>
> kaffe -verbosegc -verbosemem at.dms.kjc.Main HelloWorldApp.java
>
> and put the memory stats up somewhere? It'd be interesting to see where the
> leaks are coming from.
Alas, all one gets is (after a long pause):
[EMAIL PROTECTED] regression]$ kaffe -verbosegc -verbosemem
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 te
> On Thu, 29 May 2003 13:42:07 +0200
> "Kevin D. Kissell" <[EMAIL PROTECTED]> wrote:
>
> > > > > From the traces you've sent in this thread, I would assume
> > > > > that this assertion failure only occurrs when you get a
> > >
> > > 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 act
> 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 sim
> 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 fro
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
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
> > 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
Dalibor writes:
> --- "Kevin D. Kissell" <[EMAIL PROTECTED]> wrote:
>
> > And as an FYI to developers, I don't know what's
> > been changed elsewhere
> > in the tree that would account for it, but while I
> > can build and debug a JIT3
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.
>
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
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 prologue
> 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 e
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
Matthew,
I've tested with both my build of last October (essentially 1.0.7
with my patch) and I just did a check-out of the current Kaffe CVS
repository,and built kaffe from scratch, native, on a little-endian
MIPS Linux box, specifying --with-engine=intrp on the configure line.
I cut, paste
By a coincidence, I've re-opened Kaffe after working on other
stuff for the last several months, with the intention of trying to
get to the bottom of the remaining JIT problems. So maybe,
*maybe*, I can investigate this problem further, but please
note that I'm much more a machine-code-and-OS kind
> Hi guys,
> does anyone know the latest situation of Kaffe on MIPS platforms
> (I'm sure Dalibor knows:).
> I know Kevin Kissell was working on MIPS Kaffe issues and
> some other guys were working on a PS2 port.
> Kevin, do you know if gcc + Kaffe v1.0.7 has problems running on standard
> MIPS ins
> I dont want to FUD kaffe-folks, but please think a bit about my ideas
> why developing kaffe is a waste of time.
>
>
> Kaffe is not powerful enough to be a java-replacement, in many part gcj
> beats kaffe in both, performance and plenarity.
Kaffe is a virtual machine. gcj is a native runtime
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 repo
> There is a linux kernel for my velo, 2.3.99 something
> from linux-vr, but I am not a kernel hacker, and
> support for the philips mips chip hasn't been merged
> into any of the two current linux kernel mips trees
> yet, as far as I know.
The Philips chip is of the same basic design
as the Toshi
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 reflect
> 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 co
> Thank you for your reply, dalibor.
>
> I have investigated javaVM with JIT on superh architechure.
> And I tried pocketlinux's kaffe, but didn't work fine.
>
> Does JIT works on superh?
There is certainly no JIT support in the standard distributions
or CVS of kaffe. Someone on the "outside" m
t; <[EMAIL PROTECTED]>
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]>
The 1996 edition of the Java Language Spec calls out 5e-324
as java.lang.Double.MIN_VALUE, but the 1997 Java 1.0.2
VM spec calls out 4.94065645841246544e-324 as the minimum
value for the JVM Double type. So one can see how this sort
of discrepancy could have crept in. The problem arises from the
I refreshed my kaffe.org sources today to pick up Pat's
latest check-ins (which allowed me to get rid of my local
patch to exception.c), and rebuilt my MIPS/Linux
interpreter. Using the 1.0.7 sources with my previously
posted patch applied, I had been able to get the full
set of SPEC JVM98 bench
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
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
I attach an updated patch to kaffe 1.0.7 that works
well on MIPS/Linux in *interpreted* mode, i.e.
when configured --with-engine=intrp. For those of
you who have problems with attachments, I have also
put it up on my ftp server at
ftp://ftp.paralogos.com/pub/kaffe/mips/kaffe-1.0.7.patch_kevink_02
[I had forgotten which of my email accounts was registered with the mailing list.
There's a copy of this message that was sent from my paralogos.com account
that's awaiting the moderator's attention. Hopefully, he'll have seen this first
and will spare the rest of you the tedium of seeing it
63 matches
Mail list logo
