Looks like I forgot to submit this bug report...
After the introduction of rebuilding Kaffe library while making kaffe
(after 21/07/2002), we can not simply cross compile kaffe. It is
because libraries/javalib/rebuildLib (which is used to generate
library) tries to invoke newly compiled 'kaffe'
Dalibor wrote:
You could profile a benchmark run,
Today, I tried. And I noticed '-prof' option does not work for m68k ;-
Kiyo
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
In-Reply-To: [EMAIL PROTECTED]
I'm sure everybody already knows this, but we're in a freeze now.
OK, first try the easiest for me.
$ uname -a
Linux gibson 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux
This is RedHat-8.0 (full installation)
And simple 'configure; make'
Hi,
The story may be worse than I expect...
I'd like to resolve 'kaffeh' incompatibility issues and delete old 'kaffeh'
installed in '/usr/local/bin'. Then, new native build installs 'kaffeh' into
'/usr/local/kaffe/bin'.
And of course for cross-compiling, 'configure' says,
checking for
Hi Michael,
Does debugging kaffe still work?
As far as 'gdb' is concerned, yes it is.
If it does work, can someone tell me how to setup my
environment?
Setting environment variable 'KAFFE_DEBUG' to a debugger (mentioned
in FAQ.debugging) is one idea, but I usually do different way for
debug
The current libraries/clib/net/InetAddressImpl.c and some others
cannot be compiled on my poor old Linux (2.0.38) machine.
Same for me on m68k-linux.
I am afraid Linux 2.0 should be deleted from the list of supported systems.
Sigh... Then I have to find some other JVM :-
Kiyo
Hi Dalibor,
* kiyo's tim's ssize_t vs size_t patch: unresolved.
I noticed that some 'old' linux boxes have 'ssize_t' definition. The real
problem is, it is not included when ByteToCharIconv.c or CharToByteIconv.c
are compiled. So my propose for fixing this problem is the patch attached.
Could
Hi,
kiyo's getifaddr.c patch: unresolved.
It is discussed recently, and my idea is to detect the existence of
/usr/include/netpacket/packet.h. I attached a patch based on this
idea but I am not sure whether there are some system which
1) does not have 'getifaddrs'
and
2) linux based and have
I wrote:
I have some doubts for the result but, my linux box says
It may take a while how 'InetAddressImpl' issue is settled, and I
don't want to destroy some efforts I made (by debuging jit code
etc...), I send tentative patch for Super-H. This patch is against
CVS 030515 (just one day before
Hi,
--- Dalibor Topic [EMAIL PROTECTED] wrote:
--- Tony Wyatt [EMAIL PROTECTED] wrote:
Hi all,
I thought this little gem should be shared with other M68k owners. There was
only one big problem that made the JIT3 crash on the Amiga and native m68k
Linux on my machine, and this patch fixes
Hi,
Here, you can find 'FAQ.cross-compiling'. If someone can kindly improve
my description, it is very welcome.
Kiyo
-
diff -Naur kaffe-snap-030529.orig/FAQ/FAQ.cross-compiling
kaffe-snap-030529/FAQ/FAQ.cross-compiling
---
Annung haseyo,
=?ks_c_5601-1987?B?waTBvsH4X0tFVEk=?= [EMAIL PROTECTED] wrote:
I succeeded in building a kaffe CVS (about April 15 2003), and I tested a
java code in my target. It makes a good job..
But it generate the follwing Waning messagein both host(x86-i686) and my
target.
Hi,
Since I can not play with Kaffe tomorrow (I hope 'only'), if someone
can give me some hints for current problem for sh3-linux.
If I use,
Engine: Interpreter Version: 1.1.x-cvs Java Version: 1.1
Configuration/Compilation
Hi Dalibor,
I assume this is caused by the initial class loader changes back then. The
resulting problems should have been fixed with 2003-05-27 Helmer Kraemer
[EMAIL PROTECTED]. So I hope that a later version should work again.
Your assumption is correct. But unfortunately 2003-05-27's mod
Ito Kazumitsu [EMAIL PROTECTED] wrote:
Needless to say, as discussed before, some features needed
for the current kaffe are missing in Linux 2.0.38.
Same (I think) thing happens for RedHat-5.2 (Linux 2.2.5, glibc-2.1.1).
The error messages while compiling is
In-Reply-To: [EMAIL PROTECTED]
I said,
Same (I think) thing happens for RedHat-5.2 (Linux 2.2.5, glibc-2.1.1).
Sorry, this is RedHat-6.0.
Kiyo
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Hi,
As I previously reported, there are two problems for this target made by
cross-compiling, but the result is '2 of 136 tests failed'.
The failed tests are 'DosTimeVerify.java' and 'ZipTest.java', and skipped one
is 'NetworkInterfaceTest.java'. Failed two tests are actually caused by
the lack
Hi Tony,
Tony Wyatt [EMAIL PROTECTED] wrote:
Sadly the configure script will not run on my AmigaOS platform. The script
crashes the machine, leaving only a file configure.lineno behind. This
file has 30,690 lines.
That's too bad... For this specific issue, I am sorry to say I can not
help at all
Thanks Dalibor, but as others mentioned they are not enough.
See details attached.
Kiyo
-
m68k-linux-gcc -DHAVE_CONFIG_H -I. -I../../../../kaffe-snap-030612/libraries/clib/net
-I../../../config -I../../../include
Also, I know that this bugs is fixed in recent kaffe-cvs.
So, If use the latest kaffe-cvs, it doesn't matter.
Thanks.
Or simply use latest released version (1.1.0). Saying 'latest kaffe-cvs'
can be sometimes mislead, especially when time passed :-)
Kiyo
Hi,
I understood your message as the following
,which is supposed to run on SYSTEM-B (--host)
: it means System-B s the system where cross compiler is
installed and works.
Your description is corerct, but you may misunderstand, still...
Let's say SYSTEM-A to be super-fast machine
Hi Jim,
At the moment, the web page just has the FAQ files from 1.1.0.
That's funny. 'FAQ.cross-compilation' is in the 1.1.0. But it is not
listed in documentation.shtml. This is same for 'FAQ.jit3'. Are
you talking '1.0.7' rather than '1.1.0'?
Kiyo
Hi,
I've not tried MIPS port for 1.1.0, but are there someone who did it?
I have already succeeded in compiling kaffe( it is kaffe-1.0.7 and may be
version of cvs-about April.)
If you have workable version, why don't you try to compile it with
cross-compiled environment, first.
Is not the
Hi Gerlando,
void _slot_slot_fconst(SlotInfo*, SlotInfo*, double, ifunc, int)
shouldn't there be a float instead?
I am hesitate to reply for this, but if old story is still true, any
c function arguments are converted to double from float. See, pp.137
of C a reference manual.
# There should be
Hi,
Still jit3 for m68k does not work properly, but one small improvements.
After 2002/11/12, even HelloWorldApp.class does not print any proper
output, and I checked what was changed at that time. There are many
changes in one day, but finally I found new 'ConverterAlias.java'
introduced this
Hi again,
I also tries to use newer versioin of clib available with debian-2.2,
but still the compilation does not work.
The clib version used for debian-2.2 is 2.1.3 and in this release (of
clib), sockaddr_in6 (defined in 'linux/in6.h') does not have
sin6_scope_id field. I think one more check
Hi Dalibor,
That's weird, since the last change to
...
That is the code :-) When I try to fetch from repository by specifying
date, (-D option) '2002-11-11' gives the older version and I used this
date. Maybe, still I may use cvs in wrong way...
. The diffs contain only more character set
Hi
Kiyo's http://www2.biglobe.ne.jp/~inaba/trampolines.html and
http://www2.biglobe.ne.jp/~inaba/sysdepCallMethod.html
Are they still needed to be mentioned? They are not out of date
(fortunately) but equivalent issues are mentioned in more detailed
documents. Mine are just a quick hack to help
Hi,
For LDFLAGS and the others it's ok but CFLAGS is hardcoded in
config/m68k/linux/config.frag,
Humm, all flags in CFLAGS should not be mandatory, we can delete
this line at all.
Kiyo
___
kaffe mailing list
[EMAIL PROTECTED]
I mean: can I say something to ./configure (or somewhere else...) to
automatically made the changes to kaffe when building for my target??
Yes there is.
Add one more 'AC_CHECK_FUNCS' in 'configure.in' (not in 'configure')
with corresponding 'HAVE_???' is the first thing to do. You may have
to
Hi Ric,
i had a temporary absence here, I did some upgrading on my hardware, had
a failure.. and well even put my real name when I began tracking news
here again.
I'm still 'planning' to go back to m68k-NetBSD issue when I finish
jit bug in sh3 but it pushed so many stack, and may take a while
Hi,
Thanks for the official support of crosstools in the latest NetBSD,
I tried to compile all Kaffe configurations available for NetBSD
(alpha, arm, m68k, mips, powerpc, sparc).
Attached patch deleted unneeded defs in config.frag files for these
configurations. I think similar mods can be
Hi Dalibor,
thanks again for the patch. since I'm not sure whether you've got your
CVS write access already, I've commited it myself. Would you like to
clean up the other platforms as well? AFAIK, freebsd comes with another
cross-compilation toolset similar to netbsd's.
As you guessed, I have
This should work...
./configure --with-staticbin --with-staticvm --with-staticlib
That should give you a static binary.
Unfortunately NO.
Or, depends on the definition of 'static binary'. My definition is 'a
binary which does not need any extra files to be executed' and recent
auto-tools makes
Hi,
Today's snapshot can not be compiled on i686-linux (and maybe all other
platforms) with
--with-staticbin --with-staticlib --with-staticvm --without-x --without-sound
Hi,
We fixed i386-netbsd by copying the definitions over from i386-freebsd2.
That's hardly going to work for the other 50+ platforms, so we may need
something more general ;)
Of course, it can be done. But I agree it is not the way to go, once
we think the numbers of CPU's and OS's we support.
Hi all,
I am not sure whether it is the only GPL'ed JVM written in some HDL or not,
but maybe it should be interested to someone in this ML.
http://shimizu-lab.dt.u-tokai.ac.jp/pgm/traja2/index.html
Shall we make one more sections in links page for 'Free Hardware JVM(s)'? ;-)
Kiyo
Hi,
As the subject line says, configure.in version 1.200 introduced existence check
for 'mktemp' command, but it does not change anything for configure script.
This command is used in 'kaffe' shell script and if we don't have mktemp
(well, this is the case for me on Solaris) the final 'kaffe'
Oops, my previous report is too terse.
I said,
As the subject line says, configure.in version 1.200 introduced existence check
for 'mktemp' command, but it does not change anything for configure script.
This command is used in 'kaffe' shell script and if we don't have mktemp
(well, this is the
Hi again,
Since mktemp command in 'www.mktemp.org' is BSD style license, aren't there
any possibilities to include it into kaffe tree?
Kiyo
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Hi Richard,
I would like to trace bytecode in kaffe. AFter search the mainling
list, I try to use fprintf( ... ). But I insert fprintf( ... ) in
RunVirtualMachine function. The error message always display, internal
error, or CLASSPATH problem.
Well, if you just want to get bytecode trace use
Kiyo Inaba looked at that one, it seems to be a bug in kaffe's m68k
assembler sources, namely the COMPARE_AND_EXCHANGE macro. See
http://gcc.gnu.org/ml/gcc-bugs/2003-04/msg00753.html
Right. I am (partially) guilty. Usually, deleting optimization can solve
this problem. Well, I will make another
Thanks Fu,
The Nihonsoft homepage is at http://www.nihonsoft.jp , it is in Japanese.
please take a look at it and tell us how you feel. Thanks!
Yes, I knew this page. For the benefit of persons who can not understand
(or does not trust machine translation tools available on the net), I
will make
While trying to get the latest kaffe for m68k, I become wondering what is the
purpose of 'NEED_sysdepCallMethod' macro defined in several machine dependent
codes. That means, this macro is not needed to compile m68k-linux (CVS head)
and it WAS needed for 1.1.4, but still several other ports have
Riccardo wrote:
In [EMAIL PROTECTED] Kiyo Inaba wrote:
BTW, one more question.
For m68k-linux, gcc complains that sysdepCallMethod can not be inlined
because of alloca. When the compilation finished, I will test whether
this kaffe works or not.
I cannot get kaffe to work on linux/m68k
Dalibor Topic wrote:
Kiyo Inaba wrote:
While trying to get the latest kaffe for m68k, I become wondering what is the
purpose of 'NEED_sysdepCallMethod' macro defined in several machine dependent
codes. That means, this macro is not needed to compile m68k-linux (CVS head)
and it WAS needed
Riccardo and m68k-linux lovers,
on 4/14/04 10:10 AM, Kiyo Inaba at [EMAIL PROTECTED] wrote:
I have slightly different behavior, but the result (kjc is not useable)
is same. Let me investigate more...
OK, self compiling finished (after, say, 10 hours of configure/compiling)
and it started
Dalibor,
My earlier patch I posted is just to verify where we have
problems. I am still thinking whether macro version is better
or switch to inlining.
Any idea?
Kiyo
P.S. I can not test modified inlining version right now, because
it may take another several hours to finish compiling
I wrote:
OK, self compiling finished (after, say, 10 hours of configure/compiling)
and it started to compile javalib by using kjc. I attached a patch
against cvs-040408 (maybe ok for cvs-head also).
I tried twice but building 'rt.jar' stops at
According to Dalibor's suggestion, I modified to use inline but still
-
../../../config/../../kaffe-snap-040408/config/m68k/linux/md.h: In function
`sysdepCallMethod':
In file included from ../../../config/md.h:1,
Riccardo wrotes:
I am wondering this comes from relatively old compiler like
-
$ gcc -v
Reading specs from /usr/lib/gcc-lib/m68k-linux/2.7.2.3/specs
gcc version 2.7.2.3
Hi all,
I made small test program for inline with alloca (list at the bottom),
and try to compile it on several platforms including sparc, i686 etc,
but all warn 'function using alloca cannot be inline'.
So I propose to make sysdepCallMethod for m68k back with macro version.
Kiyo
My compile
Dalibor wrote:
I made small test program for inline with alloca (list at the bottom),
and try to compile it on several platforms including sparc, i686 etc,
but all warn 'function using alloca cannot be inline'.
Yes, even if you use __builtin_alloca on i386, gcc 2.9x seems to warn
about alloca.
In configure.ac we have 'AC_TYPE_IN_PORT_T' to check existance of in_port_t,
but when it is expanded, we get following code segment.
--
echo $as_me:$LINENO: result: $ac_cv_type_in_port_t 5
echo ${ECHO_T}$ac_cv_type_in_port_t
Hi,
I finally can start to compile kaffe for m68k/linux and m68k/netbsd.
And I noticed m68k/linux build (for current) faild because of some
compilation failure while making rt.jar. It happens by floating point
handling, and I have noticed this for long time on debian-hamm. But
it looks it still
Regression for woody finished.
50 of 144 tests failed
Please report to [EMAIL PROTECTED]
Well, so many errors, and so many things I can play with ;-)
But, the biggest problem should be compilation errors like,
error compiling:
Riccardo,
Thanks to make regression tests for so many different types of
machines.
but I checked probably CVS before syscCall patches were merged in.
On linux, I recompiled again with those but found no difference (kjc
hangs forever); although I haven't analyzed the log further.
As far as
I am now investigating kaffe for i386/netbsd and found very latest version was
broken.
For 'ChangeLog head: 2004-04-30 Guilhem Lavaux [EMAIL PROTECTED]',
regression failed for
140 of 144 tests failed
Please report to [EMAIL PROTECTED]
For m68k/NetBSD, I found one fuzz which makes jit does not work.
In 'config/m68k/jit.h', the struct methodTrampoline looks like
--
typedef struct _methodTrampoline {
unsigned short call;
int fixup;
struct
Hi Dalibor,
First, thanks to check in my code fragment, and sorry not to prepare
'ready to checkin' format (with ChangeLog).
Short report, even with this mod, still my mac does not want to compile
rt.jar. I start to investigate this when I finish other work.
the definition of fixup in jit.h
OK, at least jit properly calls 'soft_fixup_trampoline'...
# But just after that, it crashed again ;-
Dalibor wrote:
Riccardo wrote:
Could this be cause of my grief on OpenBSD/68k too? should I try to
import this chaneg in the OpenBSD m68k header (which, for testing
purposes, is still separate
I wrote:
OK, at least jit properly calls 'soft_fixup_trampoline'...
# But just after that, it crashed again ;-
Two more fields also need 'packed' attribute, how silly I am :-
Anyway, mac starts to recompile everything (if I touch jit.h, even
libraries are re-compiled, the dependency is another
I wrote:
Regression for woody finished.
...
P.S. I will check intrp first, by the way.
After several DAYs of compiling rt.jar (by intrp engine), it aborted.
-
[ parsed kaffe/util/Timer.java in 186,890 ms ]
[ parsed
Hi Dalibor,
I wrote:
I know that kaffe side has not been changed. My wondering is NetBSD
might change its gcc's behavior at some stage.
I can not find differences which might cause the different behavior
of packing short in gcc's builtin-specs for m68k/{linux,netbsd}, and
I am now trying to
Dalibor,
thanks a lot for testing it. Should I add the packed attribute to the
two remaining fields anyway?
Could you please wait for a moment. I am looking several other ways
to fix this problem, and have not yet decided which is the best.
Kiyo
___
On NetBSD/68k:
The 'm68k/netbsd' configuration has never been worked with 'jit3'.
Specify other engine.
# Anyway, there are no workable engine right now...
Kiyo
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
For m68k/linux (debian woody)
Anyway, I will start the regression test using pre-built rt.jar.
OK, another several days passed. And the regression finished with
the result of
32 of 144 tests failed
Please report to [EMAIL PROTECTED]
Several days ago, I reported,
For a very tentative solution, I put addql #4, %sp just before the
subroutine call in sysdepCallMethod macro. Of course it is not so clear,
and it's better to find out some other way...
But, this does not help so much.
So, I go back to very old version of
Hi all,
I'm not sure it was reported or not, but anyway.
Current snap does not work with x86/netbsd1.6.
It failed to compile rt.jar by
gmake[1]: Entering directory `/usr/proj/src/kaffe-snap-040610-netbsd/libraries/j
avalib'
rm -rf lib
mkdir lib
/usr/local/bin/bash ./rebuildLib @essential.files
I have no experience to work with ARM's jit, but have some experience
with other ports.
There is no jit3-md.h in config/arm/linux. But jit3-icode.h and jit3-arm.def exist.
Does JIT3 works on ARM?
In general if you find jit3-*.def but not find jit3-md.h, someone tries
to make JIT3 work
Hi,
Even though m68k/linux with non statically linked works in some sense,
this port with static{bin,lib,vm} failed. I've not yet to investigate
the reason (I am busy seeing Eurosport for Le Mans...) but the log
is
-
make[1]:
Hi all,
Short log:
--
(gdb) r HelloWorldApp
Starting program: /proj/src/kaffe-1.1.5-rc1-m68k-netbsd-sssj-O0/kaffe/kaffe/kaffe-bin
HelloWorldApp
Hello World!
Program exited normally.
(gdb) r -fullversion
Starting program:
.
---
diff -Naur kaffe-1.1.5-rc1.orig/ChangeLog kaffe-1.1.5-rc1/ChangeLog
--- kaffe-1.1.5-rc1.orig/ChangeLog Sun May 2 18:53:50 2004
+++ kaffe-1.1.5-rc1/ChangeLog Mon Jun 21 16:22:14 2004
@@ -1,3 +1,15 @@
+2004-06-27 Kiyo Inaba [EMAIL PROTECTED]
+ * config/m68k/common.h
When I made modification for m68k/netbsd, I noticed syscalls.c include
macro 'ENOTSUP'. Even though this macro is defined for solaris and so
on, this is not defined for NetBSD. In case of Linux, there's a definition
for this in '/usr/include/bits/errno.h' to be same as 'EOPNOTSUPP'.
For NetBSD,
with 'HelloWorldApp.class' by directly invoking kaffe-bin, I can
not make the regression test work.
I found this is because I use cross compiling and the path for
shell is different. After fixing this
gmake check-TESTS TESTS=HelloWorldApp.class.save
works. But still
gmake
I am updating my base for NetBSD/m68k to more recent version from CVS.
And I found recent addition of check for kaffe/kaffevm/mem/gc-mem.c
make it can not be compiled.
Error log is attached.
Kiyo
---
m68k--netbsdelf-gcc
Hi all m68k lovers,
Dalibor just committed modifications needed for m68k/netbsd.
I'd like to summarize some notes about this. These modifications make
m68k/netbsd ports works again in some sense, but still there are
several issues remained.
1) Supported engines: only 'intrp' and 'jit'.
I tested my patch applied to kaffe-1.1.4, and configure it with
--with-staticbin --with-staticlib --with-staticvm --disable-shared
--enable-pure-java-math --disable-sound --without-x
--with-engine=jit
and got
23 of 144 tests failed
Please report to [EMAIL
Chao Riccardo,
In [EMAIL PROTECTED] Kiyo Inaba wrote:
Hi all m68k lovers,
Apart me and you I wonder who is left. TOny has been silent a lot lately.
But I hope in any case that there are many silent users in old
computers or on embedded apps.
I hope too ;-)
It remains if any of your
Hi,
After the modification of sender field of archive, the indentation for some
messages (mainly from cvs-commits at kaffe.org) becomes wrong.
For example http://www.kaffe.org/pipermail/kaffe/2004-April/097570.html
may not have any 'In-Reply-To' field, but not been displayed at root.
Can
Hi,
For older gcc (like 2.95.4), current code can not be compiled. These
gcc are still used with m68k/linux (debian-woody) or netbsd-1.6*.
Patch is attached.
Kiyo
diff -Naur --exclude CVS kaffe-snap-040701.orig/kaffe/kaffevm/verifier/verify-type.c
Sorry, I miss this mail.
I'd like to rename the config/superh directory to config/sh to go with
the usuall gnu toolchain names for superh processors (sh*).
Yeah, everytime I think we have to change it to be compatible with
gnu toolchain. I am not sure why Transvirtual's guy use this name
but in
Hi all,
NetBSD uses some special treatment for structure with 'long long'...
We need one more mod for the md.h.
I'm afraid whether this patch can be applied or not, but anyone can
understand what I mean from this patch.
Kiyo
diff -Naur kaffe-snap-040610.orig/config/m68k/netbsd1/md.h
still intrp or jit3 may not work for m68k/netbsd.
diff -Naur kaffe-snap-040708.orig/ChangeLog kaffe-snap-040708/ChangeLog
--- kaffe-snap-040708.orig/ChangeLogWed Jul 7 21:58:43 2004
+++ kaffe-snap-040708/ChangeLog Tue Jul 13 13:20:55 2004
@@ -1,3 +1,9 @@
+2004-07-13 Kiyo Inaba [EMAIL
Dalibor wrote:
sorry for the slow tests. Maybe we should add the ability to use a
prebuilt test.jar, too, so that you can just run the tests without
having to compile them.
Prebuilt 'test.jar' is a cute idea. But even right now, I first
test new build with pre-compiled classes. Things I have to
Hi Dalibor,
I'll have a go at converting them right now,
Please go ahead.
Kiyo
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Hi Helmer,
Thanks for your patch, and I applied it, but the behavior has not
been changed. I also noticed some dependency was broken, that's
why just modifing 'machine.c' does not let make to recompile it.
So, I have to re-compile it explicitly delete 'machine.{o,lo}' by
hand... (But still have
Hi Helmer,
Still I don't have enough knowledge of register spill, but I found
one type mismatch in your patch...
Is
t-u[i].slottempinfo
to be
t-u[i].slottempinfo-slot
?
With this mod, both becomes same data type (SlotData*), and at least
it solve the current problem on
-snap-040708.orig/ChangeLog2004-07-07 21:58:43.0 +0900
+++ kaffe-snap-040708/ChangeLog 2004-07-15 20:14:49.0 +0900
@@ -1,3 +1,14 @@
+2004-07-21 Kiyo Inaba [EMAIL PROTECTED]
+
+ * kaffe/kaffevm/jit3/machine.c:
+ Remove unneeded (and incorrect) code emitted
Hi,
Sorry for my little knowledge of jit3, I found 1 more similar bug in
jit3 for m68k.
While trying to execute HelloWorldApp, it uses java/lang/String and
for m68k/jit3 goes to wrong way compared with any other correct
implementations.
The original java code is
To be precise,
I said:
The same code fragment exists in jit but it looks that
cmp_ref_const itself has naver been invoked for jit.
The cmp_ref_const itself was invoked in jit, but only with v == 0.
Which means this function calls op_tst_a (test 0 for register) rather
than calling incorrect
-snap-040708/ChangeLog 2004-07-15 20:14:49.0 +0900
@@ -1,3 +1,14 @@
+2004-07-21 Kiyo Inaba [EMAIL PROTECTED]
+
+ * kaffe/kaffevm/jit3/machine.c:
+ Remove unneeded (and incorrect) code emitted.
+ This mod is suggested by Helmer.
+
+ * config/m68k/jit3-icode.h
Hi Helmer,
Do all of the methods that are not compiled correctly contain
exception handlers (or synchronized(foo){} blocks)?
For the time being, the answer is YES. The second problem I found
also related to synchronized. It happened in
java/lang/String.init(StringBuffer)V
I will continue
I am so glad that some other persons are interested in m68k instruction :-)
I think your question may be best answered by the source as usual,
but I will summarize this.
In [EMAIL PROTECTED] Kiyo Inaba wrote:
I made a patch file to solve some problem on m68k jit3. In this patch
you can find
Hi Helmer,
As the subject line says, your patch solve my problem :-)
So I jumped into using kjc, but it seg-faults in
java/util/Locale.getCountry()Ljava/lang/String
I will submit detailed error report later.
Thanks again for your cooperation.
Kiyo
Hi again,
I made a mistake. The function which causes SEGV is
ResourceBundle.tryBundle
BTW, I compared the performance between jit and jit3 for m68k.
This was once discussed in this ML for several years (...) ago,
but I think there were no conclusion.
Simple test to use
, but for the time being, I just
let it be in the repository.
Kiyo
diff -Naur kaffe-snap-040708.orig/ChangeLog kaffe-snap-040708/ChangeLog
--- kaffe-snap-040708.orig/ChangeLogWed Jul 7 21:58:43 2004
+++ kaffe-snap-040708/ChangeLog Thu Jul 15 20:14:49 2004
@@ -1,3 +1,14 @@
+2004-07-27 Kiyo Inaba [EMAIL
Hi Michael,
I have noticed that all (except for qnx and win32) include
sysdepCallMethod.h. I have attached a patch file that will add the
sysdepCallMethod.h to common.h and remove it from the md.h files. qnx
and win32 undefine NEED_sysdepCallMethod since they have their own
implementations.
Ciao,
Riccardo said,
PS: Kyio when do you submit your improvments? I'm eager to test them on
OpenBSD and Linux
Which improvements? I think I have already submitted all my modifications
(with so many suggestions from Helmer) for m68k. As I said in the
'm68k/jit3 can print Hello World!' thread,
Hi Jim,
You said,
2) Release 1.1.5 (when it passes regression tests)
Is it possible to add patches targeted to Release_1_1_5_Branch?
I would like to make 1.1.5 workable with m68k/{linux,netbsd}/{intrp,jit,jit3}
Of course this has not been passed with all regressions but at least
better than
1 - 100 of 292 matches
Mail list logo
