1

Possibly related questions:

I come from the land of cross-platform languages. I'm pretty decent at Python and abysmal but productive with Java. I know that a .pyc file will, more or less, work on any system that runs the same version of Python, and that a .jar file will, more or less, run on any machine that runs Java (excluding literal toasters). I am wondering if .msil files will work similarly in .NET environments.

So to fully extrapolate on my question:

While x86 is currently the dominant architecture, there are Windows machines out there that run on ARM. Will a Visual Basic file (or, more generally, a file that uses the .NET framework) compiled to MSIL run natively on an ARM-powered Windows machine? e.g. Windows Phone, or one of the RT tablets. EDIT: Also wondering if these files will run natively in Mono, as I just learned that that is a thing. EDIT: Is it generally better to ship code to be compiled later or pre-compiled code?

If I am not understanding what an MSIL file is, I apologize. I'm going off the tetbook for my class next quarter, and I might just be misunderstanding what MSIL is.

Community
  • 1
  • 1
b4ux1t3
  • 439
  • 1
  • 6
  • 21

1 Answers1

4

IL is an intermediate language. There is no processor that understands the MSIL produced by the VB.NET or C# compiler. Not an x86 proc or an ARM.

This intermediate language needs to be JIT (Just-in-Time) compiled into machine instructions that a processor can actually understand. The JIT in this case is part of the Common Language Runtime of the .NET Framework. So, if there is a JIT/CLR for that platform, then yes, you can execute MSIL on it but only through the CLR. This is also called the virtual machine.

That said, there is a CLR/JIT for the more popular platforms, like x86, x86-64, and ARM (though WoA is restricted in many ways), even Itanium at one point.

There are some other things to consider though. C# and VB.NET don't have to compile to MSIL, that's just how they have traditionally worked. In some cases, they do not. For example, the Xamarin compiler will compile C# to ARM using ahead-of-time compilation to produce ARM code directly from C# for iOS, there is no "intermediate" language in that case.

Is it generally better to ship the code to be later compiled, or to compile ahead of time for the target platform?

This depends entirely on your tooling support and what you are trying to develop. Historically, C# and VB.NET could only compile to MSIL. Microsoft didn't make a compiler that compiled C# to native code. Xamarin does it specifically for ARM iOS devices. As far as I am aware, you aren't able to AoT compile it for any platforms other than iOS. JIT compilation has some significant advantages, theoretically. For example, there are a lot of differences between an Intel Core 2 Duo processor and a 4th generation i7. The i7 has a lot of instruction sets and features that Core 2 Duo does not. The JIT could then produce very optimized CPU instructions that wouldn't be portable to other CPUs, even if they were the same architecture.

Windows Store Apps however, are another thing. While they can be developed in C# and VB.NET, users download them from the Store pre-compiled for their architecture using the recently announced .NET Native.

vcsjones
  • 138,677
  • 31
  • 291
  • 286
  • That is extremely helpful, but let me ask for a bit more information: Is it generally better to ship the code to be later compiled, or to compile ahead of time for the target platform? I ask because, in my mind, I feel like a JIT on an ARM device will be better able to handle corner-cases where, for instance (*and this is super oversimplified, I barely know what I'm saying*) the ARM chip needs a specific command, but Xamarin doesn't know exactly how to compile that part, leading to an error that could have been resolved with the JIT compiler. Does that make sense? I can reword if it didn't. – b4ux1t3 Aug 29 '14 at 18:55