Discussion:
[Mono-dev] Mono:MIPS patch
Yoichi NAKAYAMA
2007-10-18 00:41:51 UTC
Permalink
Hello,
I'm trying to use Mono runtime on MIPS architecture. Attached change mend
some problems, but I'm not confident of the changes (especially the 2nd one),
and I want to ask for the review.

1. At first, compilation fails since there is no definition for mips
in mono/mono/utils/mono-membar.h. I uses
__asm__ __volatile__ ("" : : : "memory");
as for ARM.

2. basic-long.exe stopped at

** ERROR **: file mini-codegen.c: line 224 (mono_spillvar_offset_int): should not be reached

When I remove the g_assert_not_reached, another assertion fails:

** ERROR **: file mini-mips.c: line 3190 (mono_arch_emit_prolog): assertion failed: ((alloc_size & (MIPS_STACK_ALIGNMENT-1)) == 0)

Below the assertion,

/* re-align cfg->stack_offset if needed (due to var spilling in mini-codegen.c) */
cfg->stack_offset = (cfg->stack_offset + MIPS_STACK_ALIGNMENT - 1) & ~(MIPS_STACK_ALIGNMENT - 1);

/* stack_offset should not be changed here. */
alloc_size = cfg->stack_offset;
cfg->stack_usage = alloc_size;

implies spilling may break alignment and alloc_size is reset by aligned value,
so I just removed the assertion, then basic-long.exe runs without aborting.

I'm not sure what is the correct fix here. The second comment says 'stack_offset'
should not be changed. Should we keep stack_offset and align alloc_size alone?

3. Wrong code genered for conditional branching, e.g.

using System;
class CompareIntegers_simple
{
public static void Main() {
long i64 = 0;

if (i64 < Int32.MinValue) {
Console.WriteLine("True");
}
}
}

I found there are some mistakes in mono/mono/mini/inssel-long32-mips.brg.
I've fixed it and added some related tests.

With those changes, I've checked that "mono --regression basic-long.exe"
passes except test_0_conv_to_r4 (tested on Debian-MIPS on qemu).

Sincerely yours,
--
Yoichi NAKAYAMA
Pixela Corporation
Yoichi NAKAYAMA
2007-10-19 08:11:05 UTC
Permalink
Hello,

At Thu, 18 Oct 2007 09:41:51 +0900,
Post by Yoichi NAKAYAMA
With those changes, I've checked that "mono --regression basic-long.exe"
passes except test_0_conv_to_r4 (tested on Debian-MIPS on qemu).
Then I've investigated test_0_conv_to_r4 failure.
Dump of __emul_lconv_to_r4 generated by "mono -v -v" is:

00000000 <System_Object___icall_wrapper___emul_lconv_to_r4>:
...snip...
e8: 8fc20154 lw v0,340(s8)
ec: 8fc30150 lw v1,336(s8)
f0: 00602020 add a0,v1,zero
f4: 00402820 add a1,v0,zero
f8: 3c190056 lui t9,0x56
fc: 27392f44 addiu t9,t9,12100
100: 0320f809 jalr t9 # 0x562F44 == mono_lconv_to_r4
104: 00000000 nop
108: 462004a0 cvt.s.d $f18,$f0
10c: e7d20020 swc1 $f18,32(s8)
110: c7c00020 lwc1 $f0,32(s8)
114: 46000021 cvt.d.s $f0,$f0
118: f7c00028 sdc1 $f0,40(s8)
...snip...

At 108, it assumes return value of mono_lconv_to_r4 is stored
on f0 as double precision float. Although, it is stored as single
precision float, then wrong value seems to be returned.

% objdump -r -d jit-icalls.o
00000234 <mono_lconv_to_r4>:
234: 3c1c0000 lui gp,0x0
234: R_MIPS_HI16 _gp_disp
238: 279c0000 addiu gp,gp,0
238: R_MIPS_LO16 _gp_disp
23c: 0399e021 addu gp,gp,t9
240: 27bdffe0 addiu sp,sp,-32
244: afbf0018 sw ra,24(sp)
248: afbc0010 sw gp,16(sp)
24c: 8f990000 lw t9,0(gp)
24c: R_MIPS_CALL16 __floatdisf
250: 00000000 nop
254: 0320f809 jalr t9
258: 00000000 nop
25c: 8fbc0010 lw gp,16(sp)
260: 8fbf0018 lw ra,24(sp)
264: 00000000 nop
268: 03e00008 jr ra
26c: 27bd0020 addiu sp,sp,32

I've changed mono_lconv_to_r4's return type to double,
and confirmed that mono passes test_0_conv_to_r4 on MIPS.

Is it a correct fix? I wonder why this was not a problem on
other platforms (arm, hppa, ppc, s390 and sparc where
MONO_ARCH_EMULATE_LCONV_TO_R4 is defined).

Regards,
--
Yoichi NAKAYAMA
Pixela Corporation
Yoichi NAKAYAMA
2007-10-24 01:50:49 UTC
Permalink
At Fri, 19 Oct 2007 17:11:05 +0900,
Post by Yoichi NAKAYAMA
Post by Yoichi NAKAYAMA
With those changes, I've checked that "mono --regression basic-long.exe"
passes except test_0_conv_to_r4 (tested on Debian-MIPS on qemu).
[...]
Post by Yoichi NAKAYAMA
I've changed mono_lconv_to_r4's return type to double,
and confirmed that mono passes test_0_conv_to_r4 on MIPS.
It was bad. pinvoke also has the problem. I refer HPPA port
and found that it seems to insert conversion after call.
Fixed patch attached.

* inssel-mips.brg, mini-mips.c: Fix handling of single-float
return value of native call.
* inssel-mips.brg: Remove duplicate items.

Best regards,
--
Yoichi NAKAYAMA
Pixela Corporation
Yoichi NAKAYAMA
2007-11-14 01:45:27 UTC
Permalink
Hello,
After the previous post, I adjusted calling convention and added missing
code emission, etc (see details in ChangeLog entry). Now it passes:
tests/{even-odd.exe, handleref.exe, pinvoke.exe, pinvoke3.exe, pinvoke11.exe,
pinvoke13.exe, pinvoke17.exe, appdomain1.exe, appdomain2.exe,
appdomain.exe, appdomain-exit.exe cross-domain.exe, test-dup-mp.exe}
in addition to mini/(*.exe except exceptions.exe). Tested on Debian/qemu-system-mips.

I'd like to contribute attached patch to the Mono project.

Best regards,
--
Yoichi NAKAYAMA
Pixela Corporat
Zoltan Varga
2008-02-27 13:51:41 UTC
Permalink
Hi,

Sorry for forgetting about this. This is now checked in.

Zoltan
Post by Yoichi NAKAYAMA
Hello,
After the previous post, I adjusted calling convention and added missing
tests/{even-odd.exe, handleref.exe, pinvoke.exe, pinvoke3.exe, pinvoke11.exe,
pinvoke13.exe, pinvoke17.exe, appdomain1.exe, appdomain2.exe,
appdomain.exe, appdomain-exit.exe cross-domain.exe, test-dup-mp.exe}
in addition to mini/(*.exe except exceptions.exe). Tested on Debian/qemu-system-mips.
I'd like to contribute attached patch to the Mono project.
Best regards,
--
Yoichi NAKAYAMA
Pixela Corporat
_______________________________________________
Mono-devel-list mailing list
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Loading...