Compiler error with array of structs in sdk 4.3 QFE2 and vs2015 rc about netmf-interpreter HOT 5 CLOSED

Thanks for the report. I've marked this as a bug, There are a number of such issues as the compiler is essentially a completely new compiler in VS2015 (e.g. Roslyn) so the code generation is bound to be different, and in a few cases it generates code the NETMF tooling or runtime can't handle. (Generics are not yet supported and a deliberate choice was made to block all "unsafe" constructs) Thus if the compiler is generating any of those we need to detect and re-write them in a compatible fashion.

from netmf-interpreter.

Given the provided sample code the problem is in the code generated for the Foo constructor. The new 'Roslyn' compiler generates the following:

.method public hidebysig specialname rtspecialname 
    instance void .ctor () cil managed 
{
    // Method begins at RVA 0x20e0
    // Code size 24 (0x18)
    .maxstack 2
    .locals init (
        [0] valuetype MFConsoleApplication1.Program/Foo/Bar[],
        [1] valuetype MFConsoleApplication1.Program/Foo/Bar
    )

    IL_0000: ldarg.0
    IL_0001: call instance void [mscorlib]System.Object::.ctor()
    IL_0006: nop
    IL_0007: nop
    IL_0008: ldc.i4.1
    IL_0009: newarr MFConsoleApplication1.Program/Foo/Bar
    IL_000e: stloc.0
    IL_000f: ldloc.0
    IL_0010: ldc.i4.0
    IL_0011: ldelem.any MFConsoleApplication1.Program/Foo/Bar
    IL_0016: stloc.1
    IL_0017: ret
} // end of method Foo::.ctor

While the older compiler generates:

.method public hidebysig specialname rtspecialname 
    instance void .ctor () cil managed 
{
    // Method begins at RVA 0x206c
    // Code size 53 (0x35)
    .maxstack 2
    .locals init (
        [0] valuetype MFConsoleApplication1.Program/Foo/Bar[] bars,
        [1] valuetype MFConsoleApplication1.Program/Foo/Bar b,
        [2] valuetype MFConsoleApplication1.Program/Foo/Bar[] CS$0$0000,
        [3] valuetype MFConsoleApplication1.Program/Foo/Bar CS$0$0001
    )

    IL_0000: ldarg.0
    IL_0001: call instance void [mscorlib]System.Object::.ctor()
    IL_0006: nop
    IL_0007: nop
    IL_0008: ldc.i4.1
    IL_0009: newarr MFConsoleApplication1.Program/Foo/Bar
    IL_000e: stloc.2
    IL_000f: ldloc.2
    IL_0010: ldc.i4.0
    IL_0011: ldelema MFConsoleApplication1.Program/Foo/Bar
    IL_0016: ldloca.s CS$0$0001
    IL_0018: initobj MFConsoleApplication1.Program/Foo/Bar
    IL_001e: ldloc.3
    IL_001f: stobj MFConsoleApplication1.Program/Foo/Bar
    IL_0024: ldloc.2
    IL_0025: stloc.0
    IL_0026: ldloc.0
    IL_0027: ldc.i4.0
    IL_0028: ldelema MFConsoleApplication1.Program/Foo/Bar
    IL_002d: ldobj MFConsoleApplication1.Program/Foo/Bar
    IL_0032: stloc.1
    IL_0033: nop
    IL_0034: ret
} // end of method Foo::.ctor

The problem comes from: IL_0011: ldelem.any MFConsoleApplication1.Program/Foo/Bar in the new code. The .NET Micro Framework does not support that particular form of the ldelem instruction. (All the forms that include the element type encoded in the instruction opcode are supported)

Re-writing this would require some fairly sophisticated analysis to determine the proper replace of the ldelem instruction in all cases the compiler could generate this. Thus, it would appear the better answer is to support the ldelem instruction (and it's mirror twin stelem). At this point it is unclear why the problematic form isn't already supported. The other instructions not supported are all related to "unsafe" pointer manipulation, which is excluded from NETMF by design.

from netmf-interpreter.

May I ask why unsafe instructions are deliberately not supported in NETMF? What is the reasoning behind that? In some cases they would help to achieve faster execution speeds.

from netmf-interpreter.

NETMF, in its current form, is an interpreter so the very idea of a pointer is a nebulous one at best. The original product design that NETMF was released for was the "Smart Personal Object" concept (a.k.a. SPOT) which supported, among other things a core framework on a device with arbitrary third party applications in C# running under the NETMF interpreter. Thus a strictly safe code model was desired. If performance requirements require it, interop to native code can handle the unsafe functionality in a safe manner.

When we move to Ahead of Time native compilation in our next major release, we'll enable higher performance just in the new compilation, but we'll also enable the unsafe support for real low level systems programming as well. Although, I think, we can achieve a story where very little hand written code will need to use unsafe constructs, which will help eliminate or avoid a large class of bugs. we'll see how that progresses.

from netmf-interpreter.

Nice. 👍

from netmf-interpreter.