Microsoft officially released the .NET Micro Framework Software Development Kit, today. The new, low-end member of Microsoft’s embedded software lineup extends the company’s reach into high-volume, cost-sensitive devices and subsystems with severely constrained processor and memory resources.
I don’t know why but this combination makes me scared…have you guys ever seen a fast small light-weight .NET program?
.NET is good for UI based applications but it does not make much sense in high performance or low resources applications. I don’t know why Microsoft is so hell bent on pushing .NET our throats…similar to like how SUN was trying with Java..
In my experience interpreted languages are good for things like scripting and UI but not at all for big applications that need high performance like for example a media player etc…
You’d be surprised how low a VM can go. The desktop (really, server) CLR and JVM are pretty heavyweight, but that’s largely because they trade memory for execution speed. An embedded JVM can make a different set of trade-offs. First, the JIT can be small and simple. Embedded CPUs are usually single-issue designs with short pipelines, so you don’t need the overhead of a fancy optimizer. Second, you can leave most code as bytecodes, JIT’ing only critical inner loops that fit into the cache. On an embedded platform, memory is both slow and expensive (16-bit memory bus, usually). So leaving most things as bytecode, which is much smaller than machine code, saves both time and money. Third, many embedded CPUs like an MMU, and consequently memory protection. Thus, the “safe code” guarantees of a VM help both stability and security.
The JVM has proven to work quite nicely on embedded platforms — most newer phones have a JVM of some form or the other.
Most of your comment is right on the mark here, but…
Third, many embedded CPUs like an MMU, and consequently memory protection.
The article states that .NET MF supports CPUs without an MMU, so it must handle memory protection some other way.
That was supposed to be “lack an MMU” not “like an MMU”. My point was that since C# programs cannot cause out of language errors, some level of program isolation can be achieved even without a hardware MMU.
I can understand why you’d say that, but really, I’d bet that an embedded .NET would be much tighter, neater and cut back. It really doesn’t have much choice to be anything other than that.
There is only mention of C#. What about other .NET languages?
I’m thinking how is a VM going to run on a Z80 with 1kb of RAM and 16kb ROM attached to it?
I think Zork’s Z-Machine VM works on a Z80!
http://en.wikipedia.org/wiki/Z-machine
Most embedded software has real-time requirements. This means that for certain tasks it must be possible to guarantee that they finish within a given time. This is possible when using a language like C++ on operating systems like Linux RT or Windows CE, since the C++ language does not perform garbage collection, and since there are upper limits defined on the time the OS spends inside an interrupt. Garbage collection is an essential part of the .NET CLR however. Does Microsoft guarantee anything about the real-time behavior of the .NET micro framework ?
It is right that most new phones contain a JVM. But is the JVM used for more than games in these phones ?
According to the FAQ, the micro framework is not real-time. However, that’s probably less a function of the language and more a function of development priorities. It’s entirely possible to create a GC that has bounded pause times. IBM’s Metronome has pause times on the order of a few hundred microseconds, which is good enough for most soft-realtime tasks, including audio and video.
In general most good incremental collectors have a maximum pause time that’s a function of things like the stack size, register count, static data area size, and maximum array size. In real-time applications, these will all be known, bounded values. As a result, your 99-th percentile GC pauses will be bounded. Now, 99th percentile isn’t good enough for some things (running a nuclear reactor), but it’s good enough for a lot of other things.
The smallest thing I’ve ever seen them do is Windows CE…If only they would shrink the binaries down for XP or Vista we’d have a small footprint OS that runs much faster than what we have today…
Our embedded programmers are optimizing critical code in assembler on the target platform and finding that in most cases the code the C/C++ compiler generated is actually better than the stuff they wrote due to its better knowledge of the processor.
In their opinions, .NET C# and CLR is a bad joke pooped out by people that have never had to write code for real world embeded hardware such as cell phones and digital cameras…