Questions about the vision of NETMF in relation with dotnet?

• What is the relationship between NETMF/llilum and dotnet/llilc?
• With CoreCLR getting cross-platform ARM support, CoreCLR building on ARM dotnet/coreclr#1210, what is the difference between NETMF/netmf-interpreter's JIT and dotnet/coreclr's JIT?
  • Probably one commonality is (and please correct me if I am wrong), both .NET framework and .NET µFramework have dropped the support for MIPS architecture at some point after WindowsCE got RIP'd: https://github.com/dotnet/coreclr/issues/969.

[cpfister]

Also, the positioning of NETMF Interpreter vs. NETMF Llilum should be clarified a bit, in the interest of managing expectations.

My guess is that Llilum will not be a complete replacement for the existing NETMF any time soon, nor will its APIs be a strict subset of NETMF 4.3.x, or of NETMF 4.4.x. If true, NETMF may not stop at version 4.4? So in my mind, Llilum is - at least for this and probably next year - more something like a ".NET Nano Framework". But I may be completely wrong on that.

[lt72]

Over the medium term, we are looking at re-using some solutions the LLILC team is pushing to LLVM, e.g CoreCLR GC. Over the long term we may be seeing even more convergence, depending on business needs and opportunity. The netmf JIT has never been used in production, to the best of my knowledge, but rather netmf always ran as an interpreter. Generally speaking there is little relation between NETMF codebase and the desktop framework and runtime codebase. Our general intent is to seek more convergence between llilc and llilum than there previously was between .NET MF interpreter and the desktop CLR.

To Cuno's question: you are pretty much on track. Llilum is merely at the proof-of-concept stage, and that is also why I cannot add more details RE: convergence between llilc and llilum. We do know that we will not support features such as dynamic loading with llilum, and that alone suggests that llilum will never replace .NET MF. At this stage we are looking at finishing implementing the basic features in llilum and get a good grip on code size and performance, so we can move forward in the right direction and leverage any synergy in the most effective way.

What I can say right now, is that netmf will have a RTW for 4.4 around end of August, and we are looking carefully at reviving the community and its ecosystem. Netmf 4.4 is all about reliability for the TCP/IP stack, and other related features such as Alljoyn. As llilum gradually comes online, we will see how to integrate llilum into both the netmf ecosystem and the llilc technology. It will definitely take a while to get there and Cuno's guess is likely a good one.

[smaillet-ms]

@jasonwilliams200OK- To say NETMF dropped MIPS is partially incorrect. While we no longer have any samples for MIPS targets there isn't anything in the core of the framework that prevents someone with current modern hardware from taking up the torch on that. The reality is that most customers were using ARM and most have or are switching to Cortex-M based SoCs so that's where our major engineering efforts are. What we did have was for legacy hardware no longer available. We needed to focus so we do so where the majority of users were. We'd be glad to help and support anyone with the desire to get NETMF running on other processor families.

As to the JIT. NETMF doesn't use one, it's an interpreter. While there is old code for an ARM JIT we found that on most real world microcontroller SoCs there's more flash than RAM available for executing code. Thus the jitter spent a lot of time re-jitting the same code as it has to keep pitching out old code to make room for the current function. This ended up taking more time than just interpreting the IL instructions. With Llilum the goal is to do the conversion to native machine code entirely ahead of time off line on the development workstation instead of on the fly on the device. Add to that a number of optimizations and we hope to generate extremely lean and mean native executable with all the benefits of C# and .NET that targets Micro controllers.

[aL3891]

A lot of time has passed since the original post, are you able to share any updates om this issue now? How does it relate .net native for example?