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
