CODEWITHSUNDEEP
c#compiler-constructionruntimeilnative-code
Rohan
Rohan

Reputation: 359

Are there any other purposes for compiling IL

I'm pretty sure one reason for compiling down a high-level language into some bytecode is so the VM (Java or .NET) can generate machine dependent native instructions.

Is that the only reason? If there was some way (in theory) to generate machine dependent instructions before program execution (on different computers), would there be any purpose for compiling down to bytecode? Could we just compile down to machine code and execute those instructions at runtime?

To clear it up:

If the compiler could just generate perfect instructions for every computer, is IL needed?

Upvotes: 2

Views: 333

Answers (3)

Lambda Fairy
Lambda Fairy

Reputation: 14676

It simplifies compilers, because now we can target just one simple assembly language – CIL – rather than four or five complicated ones.

You must not take this benefit lightly. x64 assembly, as an extension of an extension of an extension of an 8-bit instruction set from almost four decades ago, is full of special cases and design flaws. CIL is magical unicorn rainbows in comparison.

It eases development, because we no longer need to set up convoluted cross-compilation toolchains just to build a phone app. A single library will work on both desktop and mobile, no recompilation required.

Yes, you can just bundle multiple versions of your code, one for each architecture, into a single file. Apple did this in their PowerPC-to-Intel transition. But the resulting binaries are often large, which doesn't work well for mobile.

It increases the scope for optimization. Any optimizations in a AOT compiler only affect the code it compiles. But optimizations in a JIT will speed up all programs.

The JIT also has an extra source of information – the running program itself. By watching how the program runs, the JIT can target the areas of code that need it the most. The Java HotSpot VM uses this technique extensively.

I think there are more advantages, but those are the obvious ones.

Upvotes: 1

James
James

Reputation: 2453

So you're wondering why use an intermediate language at all?

Byte code (IL, Java byte code, even VB6's p-code) offers several advantageous. These come from the fact that the byte code is not immediately compiled and run on the target CPU. In IL's case, it is just in time compiled (JIT) to machine instructions on demand.

While this seems inherently more complicated than just compiling down to native code right away, we get a bunch of useful features from this, like reflection, garbage collection, type safety, and exception handling.

You could get those nice fancy managed features without IL by JITig C# code to native code, but then you'd have to implement those features and and write a JITer for each language you want (C++/CLI, VB.NET, etc.).

Additionally, it's much easier to write those managed features for a machine based language then try to write those features for a language that is primarily designed for human consumption.

Upvotes: 0

Nicholas Carey
Nicholas Carey

Reputation: 74177

CLR assemblies contain IL/MSIL/CIL/whatever the term du jour is these days. That is to make the compiled code hardware and operating system independent. So long as the target system supports the specified version of the CLR (and the code isn't doing anything funny with P/Invoke or the like), the assembly should run on the target system. When the assembly is loaded, it is JIT'd into native machine code (or you could ngen it to produce a machine specific binary.

The reason for having portable executables should be fairly obvious (which see Java).

Upvotes: 0

Related Questions