Comments (5)
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.
Related Issues (20)
- The .Net Micro Framework 4.4 CLR freezing and compile errors with GCC
- Networking Interface Question - CC3100 WIFI Module HOT 1
- Problems regarding to .Net Micro Framework 4.4 running on STM32F7 HOT 15
- Micro Framework Project Options do not render correctly on Hi Resolution Ultrabooks
- Is .Net MF being discontinued? HOT 3
- Visual Studio 2017 HOT 67
- Branches HOT 1
- Split flash block smaller
- Code In NETMF Operating System Does Not Transfer to C# DLL's HOT 3
- Error signing assembly -- Access is denied.
- File System - High capacity Micro SD Cards HOT 1
- ASSERT in String::Concat - Debugging Help
- How to speed up Graphics Performance HOT 6
- ExtendedWeakReference data on flash is deleted after calling GC HOT 2
- Extended Weak Reference Not Recovered - Data not on 16bit boundary
- LwIP's sys_arch realization calls prohibited osSemaphore* functions from ISR HOT 1
- Last Sources !!! HOT 1
- Creating file on SD that has been successfully through SD/Blockstorage initializations causes exception in FileStream
- δΈεζ΄ζ°δΊεοΌ HOT 2
- Visual Studio 2019 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from netmf-interpreter.