I have recently digged a bit into the Microsofts NET MF porting kit. Looks like Microsoft had implemented a Just in Time compiler in the early days on NET MF. At some point they realized that on devices with very low memory usage a JIT compiler actually reduces performance due to the constant compile & trashing of compiled code to free up memory. Jitted (so native compiled) code is around 8x larger than MSIL code.
So the JIT was disabled and has been dormant for long. Enabling it causes the NET MF build to fail.
In the meantime there are quite a few devices with lots of ram available (EMX, ChipworkX, Meridian, etc). These could greatly profit from an enabled JIT. It should be possible to enable the JIT even on low memory devices like the Panda, if the JIT compiler could be configured at runtime: eg why not just tell it which methods/assemblies shall be Jitted? Enabling the Jitter on code fragments could be a really nice feature.
Well, I must say I have almost zero experience with the NET MF PK, and C++ is not really my world, but nevertheless this could be fun and very helpfull for NET MF.
Is anyone interested to help?
I got a short reply from Lorenzo Tessione (Microsoft PK team) who said he cannot really get his hands dirty with this since their schedule is tight, but he promised some help to get started. He also welcomed the idea of resurrecting the JIT.
What is needed to help?
a device with BSP is probably needed. GHI does not offer the BSP sources for their devices unfortunately.But I guess FEZOpen and a Panda could do the trick.
Netduino has full BSP
I still have no idea what is needed to debug the PK at this lower level, I don’t know if JTAG is needed - maybe
other than that some C++ knowledge, patience and time shall do it.
Why is there is no reply for that thread. It’s THE missing feature, for .NETMF and FEZ. There is always one function or two that need to be JIT. We would greatly benefit from that on my current project. I don’t know if I can help a lot, but I would really like to keep posted.
Such a project would however need vendor support from FEZ to be sure everything is compatible.
Because there is RLP that gets you what you need. JIT would be great but it is major feature with months of dedication. Will likely get into NETMF because of its importance but will take time.
RLP is great, but you have to use two toolchain and it’s not really built-in, and not that easy. You basicly have to do manually what the interpreter do live but do not save in memory…
Exemple, for one my project, we used FEZ, because C# is great, make good software, and easy to maintain. Now, we have to use RLP, for some really important feature, and we lost more time, doing stuff in c#, and then redoing it in RLP and learning a new toolchain, that the time we would be using c#, vs arm-dev.
But I understand that it might be difficult. But also, the FEZ community can’t do it by itself because we would require non-fez hardware, since we don’t have all your source. That’s what I meant by vendor support.
I think a C# to RLP cross-compiler on the development machine (integrated with Visual Studio) would actually be more useful. Perhaps this could be done with the Mono compiler?
I suspect a JIT compiler would swamp the program memory (and possibly also the RAM) on the USBizi chips.
Yeah, I use the combined RLP/C# template mentioned elsewhere. Nice and simple. Edit RLP and C# in one solution, Build builds both and deploys both.
The USBizi will not have space to store the compiled code to reuse later, so it will have to be recompiled every time, which means you will not gain speed. Might work on the bigger devices, but I don’t think it’s worth the effort, and it will be LOTS of effort. Which I will rather spend porting MF to PIC32 chips…
