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.
Here’s my quick chat with Lorenzo
Does that sound interesting?