.NET and ARM
Over the last few years, Microsoft has spent a lot of effort pushing the .NET environment. .NET applications are not shipped as native binaries; although they often call native DLLs, they are shipped as bytecode. This can be interpreted, compiled at install time, or JIT compiled as it runs.
The hype surrounding .NET was that it was platform-agnostic, and you'd be able to take your .NET applications and run them anywhere, just like Java. In practice, this is rarely the case but while it isn't platform-agnostic, it is architecture-agnostic.
If you write a C# or VB.NET application and compile it to .NET assemblies, you can run it on any platform that Windows supports. In some cases, you can already run it on Windows Mobile, although this takes some care. The bytecode can be compiled to native ARM code just as easily as it can be compiled to x86 code.
In fact, it can be compiled slightly more easily to ARM code. Slightly older ARM chips had special instruction set, called Jazelle. When in this mode, they ran most Java bytecodes directly, causing a trap on the few that weren't equivalent to simple machine instructions. This meant that you didn't need to JIT compile Java bytecode to get reasonable performancea very important feature when mobile phones shipped with Java 2 Mobile Edition but only 16MB or less of RAM.
Most modern ARM chips no longer include Jazelle for two reasons:
- It is now possible to fit a JIT compiler into RAM quite easily.
- Java is no longer the only bytecode that people care about.
Instead, they provide Thumb Execution Environment, an extended version of the Thumb 2 instruction set designed to be easy for JIT compilers from dynamic languages to target. This includes features like checking for NULL pointers in load and store instructions, support for bounds checking in arrays, and so on. They are relatively simple features, but ones which dramatically reduce the amount of checking code required when compiling a Java-like language.