[Mono-list] Re: Remaining S/390 JIT issues
Tue, 13 Jul 2004 17:51:57 +0200
On 07/13/04 Neale.Ferguson@SoftwareAG-USA.com wrote:
> I am now passing all but two of the regression tests using my JIT
> port. One is strange that I haven't fully diagnosed with appdomain-unload
> (the page containing one of the compiled methods seems to get freed);
This is likely a general problem and not specific to your port.
We need more work to make appdomain unload fully stable.
> the other is relates to single floating point numbers.
> The way I handle single floats is:
> 1. When loaded from storage I immediately convert them to double so that all operations work correctly
> 2. Before storing back to memory I convert them from double to single and then store
> 3. When passing in a call I convert from double to single
> 4. When coming back from a function call I convert from single to double
> This appears to work most of the time, but sometimes I get sequences like:
> (stind.r4 (add (ldind.ref regoffset[0xd0(s390_r11)]) iconst) (float_conv_to_r4 (ldind.r8 regoffset[0xc8(s390_r11)])))
> In this instance float_conv_to_r4 will convert from double to single
> and then stind.4 will try to convert from double to single as well:
> resulting in junk. How do other architectures handle single floats?
float_conv_to_r4 is supposed to change the precision, but since the
resulting value is still on the evaluation stack it should be still a
double. stind.r4 will convert the value to a float during or before
saving to memory. For some architectures this process creates more code
than necessary, but most of the cases can be optimized with the proper
Later we may want to track FP values on the eval stack both as floats
and doubles, so that in some architectures we can use 32 bit FP
registers since some ops there will be faster: this requires that all
the operand are floats and not doubles, though.
firstname.lastname@example.org Monkeys do it better