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