[kaffe] Support for jit3 on arm/netbsd
Hi, Yesterday, I've committed 'partial port' of kaffe to arm/netbsd/jit3. This port is different from arm/linux port, because NetBSD port does not use (1) any floating point instructions. The current linux port uses slightly old FPA instructions (with hardware support or software emulation resides in the OS), even though there are very few arm hardwares shipped with real FPAs (2). The reasons I said this as a 'partial port' are 1) I just make float support, and not double. This is OK to execute the most basic 'HelloWorldApp.java' test in kaffe's regression, but of course double related tests all fail. 2) Since the latest snap needs extra libraries and installing all of them take long time (3), I just use relatively old snap (precisely speaking, 2007/05/10 version) as a base for this modification. 3) I did not ifdef'ed all unneeded functions in 'jit3-arm.def'. For example, the function 'fmove_RxR' is not needed when 'HAVE_NO_FLOATING_POINT' macro is defined. 4) I still set _GR_ (4) as 0 in 'jit.h' file for arm :- Currently only two functions (fspill_Rxx and freload_Rxx) which handle float values (5) are activated. I tested this modifications on 'gxemul' emulator available from http://gavare.se/gxemul/ with NetBSD 4.0 for cats and more than 100 regression tests in kaffe can be passed. I may continue improving this port (6) in some day, but my 'summer of code' season is over, and may take long time... Kiyo 1) As usual, NetBSD does things right, linux does things #. (Fill in the sharps with your favorite term, please) 2) You can read some story for arm's history of flaoting point support hardware in http://wiki.debian.org/ArmEabiPort. And you may find why kaffe still has '__XSCALE__' define in several places. (In Xscale processor the FPA instruction overlaps with their own extension, and the linux port on Xscale should be compiled with soft-float) 3) Especially, atomic support. To install 'glib', I first install several other gtk libraries... 4) The _GR_ macro is used to set properties of arm's registers. Since I set _GR_ to 0, which means (in jit3) there are no global registers available right now. Of course, this is a major reason why jit3 is slower than jit in arm port. 5) Of course there are no floating point registers (even in emulation) on arm/NetBSD, the emitted code by these functions are changed (ifdef'ed). I select to modify these two functions but the other idea is to keep these two functions same, but change the property of values from 'float' to 'int' (and 'double' to 'long') when register allocation is invoked. The latter may make my modifications to be architecture independent. 6) As some may remember, ARM is not my favorite architecture. I attack this port because I want to make m68k (well, Coldfire, these days?) or SuperH work for jit3 without FPU. So these may have higher priorities than fixing arm port. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Support for jit3 on arm/netbsd
Excellent! I think this is the first commit in 5 months since Dalibor did the last release. I notice that the CVS email script seems to be broken -- and I still need to fix Bugzilla. When I get some time, I'll try to setup gxemul so I can try it out! Cheers, - Jim Kiyo Inaba wrote: Hi, Yesterday, I've committed 'partial port' of kaffe to arm/netbsd/jit3. This port is different from arm/linux port, because NetBSD port does not use (1) any floating point instructions. The current linux port uses slightly old FPA instructions (with hardware support or software emulation resides in the OS), even though there are very few arm hardwares shipped with real FPAs (2). The reasons I said this as a 'partial port' are 1) I just make float support, and not double. This is OK to execute the most basic 'HelloWorldApp.java' test in kaffe's regression, but of course double related tests all fail. 2) Since the latest snap needs extra libraries and installing all of them take long time (3), I just use relatively old snap (precisely speaking, 2007/05/10 version) as a base for this modification. 3) I did not ifdef'ed all unneeded functions in 'jit3-arm.def'. For example, the function 'fmove_RxR' is not needed when 'HAVE_NO_FLOATING_POINT' macro is defined. 4) I still set _GR_ (4) as 0 in 'jit.h' file for arm :- Currently only two functions (fspill_Rxx and freload_Rxx) which handle float values (5) are activated. I tested this modifications on 'gxemul' emulator available from http://gavare.se/gxemul/ with NetBSD 4.0 for cats and more than 100 regression tests in kaffe can be passed. I may continue improving this port (6) in some day, but my 'summer of code' season is over, and may take long time... Kiyo 1) As usual, NetBSD does things right, linux does things #. (Fill in the sharps with your favorite term, please) 2) You can read some story for arm's history of flaoting point support hardware in http://wiki.debian.org/ArmEabiPort. And you may find why kaffe still has '__XSCALE__' define in several places. (In Xscale processor the FPA instruction overlaps with their own extension, and the linux port on Xscale should be compiled with soft-float) 3) Especially, atomic support. To install 'glib', I first install several other gtk libraries... 4) The _GR_ macro is used to set properties of arm's registers. Since I set _GR_ to 0, which means (in jit3) there are no global registers available right now. Of course, this is a major reason why jit3 is slower than jit in arm port. 5) Of course there are no floating point registers (even in emulation) on arm/NetBSD, the emitted code by these functions are changed (ifdef'ed). I select to modify these two functions but the other idea is to keep these two functions same, but change the property of values from 'float' to 'int' (and 'double' to 'long') when register allocation is invoked. The latter may make my modifications to be architecture independent. 6) As some may remember, ARM is not my favorite architecture. I attack this port because I want to make m68k (well, Coldfire, these days?) or SuperH work for jit3 without FPU. So these may have higher priorities than fixing arm port. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Support for jit3 on arm/netbsd
Hi Jim, I think this is the first commit in 5 months since Dalibor did the last release. I notice that the CVS email script seems to be broken -- and I still need to fix Bugzilla. Yeah, I wait for the CVS mail received, and reached to the same conclusion. If you can fix it, it is so helpful for us. When I get some time, I'll try to setup gxemul so I can try it out! I will release a image file which can be used with gxemul before I leave Japan. Since compiling gxemul itself is very straight forward, with this image file, you can easily play NetBSD4/arm on your machine! Keep in mind you have to get the very latest gxemul (which includes my patch) if you want to use gdb inside gxemul. Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
