Re: [Sablevm-developer] problem with divisions, float, double

[Grzegorz B. P. <ga...@de...>]

On (13/05/04 13:42), Fabien Renaud wrote:
> I use --with-thread=direct on ARM and that doesn?t wotk. On my x86, that 
> works with default options.
> I?ll try with --enable-debugging-features.

This will not help.  ARM is the last architecture that needs ironing out
of these arithmetic CPU-specific quirks.  Basically ARM doesn't catch any
special cases, so you have to check for them yourself, by hand.

The practical problem here is that all Debian ARM machines are
unaccessible since some weeks, so I don't have access to a system where
I could finish the port.  I tried iPAQ cluster at handhelds.org, but
software there is much too old and installing newer versions of a dozen
of tools in home directory would be a lot of work.

So, if you knew of an up-to-date ARM system where I could get an account
- let me know.

You could also try to fix it yourself.  Compile SableVM in testing mode by
passing --enable-inlinability-testing [*] to ./configure and run BTF tests
ex. from http://devel.sablevm.org/arm/btf.tgz ('sablevm -Y
BytecodeVerificationTest') and then look into instructions.m4.c
to fix the instructions that give us problems on ARM.  It's not terribly
complicated but it practically impossible to do it w/o access to hardware
(unless you want to spend time reading StrongARM specs to find out which
cases you have to catch yourself).

I wish I could help you more,

				Grzegorz B. Prokopski

[*] This is not ideal, as this testing mode was designed to help
porting *inlined engine* and not to track portability issues like
arithmetic problems.  It is a side effect, but this will help, becaue it'll
catch pretty much all unexpected signals and will try to recover from them
- thus allowing the tests to run further.  The only problem would be that
you'd have mixed "inlining failures" with "bytecode implementation failures".

PS: Regardless of the impression you can get from the above description,
finishing ARM port is *not* a problem per se.  Given proper access to
hardware, this should be an hour or a few hours at most of not very
challenging work.

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM