[kaffe] Support for jit3 on arm/netbsd

[Kiyo Inaba]

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.