Why IL?

re: Why IL?

Kunal Pathak — Tue, 22 Nov 2011 18:44:57 GMT

The concept of introducing intermediate language in middle is few years older than last 1960s. It was evolved with UNCOL

by Melvin E. Conway in 1958. Here is the interesting link homepage.ntlworld.com/.../uncol.html.

re: Why IL?

Andrey — Tue, 22 Nov 2011 15:54:58 GMT

The CIL is all good, but there is one problem with it - can it evolve? I guess it should evolve for 2 reasons. First, to allow for more optimizations preserving more of the higher language code structure. Second, to move things like WeakReference into CIL itself an make it native higher languages feature.

re: Why IL?

Bob — Mon, 21 Nov 2011 16:44:46 GMT

Looks like I was a victim of the invisible blog posting timeout, so I'll try again.

In the late 80's, DEC (Digital Equipment Corporation) had compilers for almost a dozen languages on its CISC-based VAX architecture and was about to run into the m x n problem as it was developing it's RISC-based Alpha architecture. It developed a CIL for its compilers and turned it into a 12 + 2 problem.

re: Why IL?

CodeInChaos — Sun, 20 Nov 2011 17:31:32 GMT

The LLVM language is at a much lower level than the .net IL. It isn't a replacement for the CIL, but could rather be used as a common backend for .net, java and low level(c like) languages. A common backend and optimizer for VC++ and .net would sure be nice.

This way compilers for different source and target platforms can share large parts of the optimizer and code generator, it's possible to add additional optimization passes or backends as a third party,...

In fact mono uses it as one of its backends which leads to very fast code (but I think it's traded for a higher JIT time).

I think Microsoft's equivalent of LLVM would be part of Phönix, and not the traditional .net stack. I remember a talk about Phönix mentioning such a low level intermediate language.

The equivalent of Roslyn would be something like MonoDevelop's NRefactory.

re: Why IL?

Estevan Cruz — Sat, 19 Nov 2011 15:44:22 GMT

Its all in the name isn't it? "Common Language Runtime" tells you all about the "why" and the benefits :D .

re: Why IL?

Tanveer Badar — Sat, 19 Nov 2011 09:02:03 GMT

Eric, I guess you are going to bring a nitpicker's corner very soon, much like Raymond Chen. Imagine some random tech site posting this tomorrow

"Eric Lippert's Claim to Fame!

In a recent blog post over the newest hot potato Roslyn, Eric discloses that he is "the" expert on C# language's semantic analysis.

Anders Hejlsberg declined to comment on the said post. You can find Mads Torgensen's counter post here <link>."

To add my 2 cents, imagine Reflection giving you complete semantic knowledge of which symbol means what in source code. And more importantly, running as you type, refactor, bring up immediate window, go to definition or find all references. Roslyn is to an IDE what is reflection + type verifier to runtime, but obviously the services offered and needed in each case are different.

re: Why IL?

CarlD — Sat, 19 Nov 2011 00:17:11 GMT

Even the native VC++ compiler has used this architecture since inception. If you look at the components of VC++, there's c1.dll (C front-end, c1xx.dll (C++ front-end) and c2.dll (backend). The front-ends produce an intermediate language (historically also known as CIL - C Intermediate Language) which the backends consume to produce native machine code. As Eric mentioned, this design is not new - it goes back decades and has been used on many, many compilers.

Perhaps the most important PC-based compiler that did not use this pattern was Turbo Pascal, which was a one-pass compiler that went directly to native machine language and which was, itself, written in assembler (by the one and only Anders Heilsberg of C# fame).

re: Why IL?

Rick C — Fri, 18 Nov 2011 23:19:35 GMT

If I'm not mistaken, GCC does more or less the same thing: All the compilers generate an intermediate code, and the backend generates machine code.

re: Why IL?

Brent M. Spell — Fri, 18 Nov 2011 22:34:15 GMT

Another benefit for application developers is that they don't have to build and distribute binaries for each target machine architecture. Instead, there is a single set of IL-compiled binaries to distribute. This simplifies ALM and deployment significantly. In addition, users don't have to know which architecture they are running in order to download/run the application.

re: Why IL?

Gabe — Fri, 18 Nov 2011 21:40:13 GMT

PaulTDessci: Imagine you wanted to write your own IDE (like Visual Studio) for C#: you want syntax highlighting, IntelliSense, refactoring, squiggly lines to show up under syntax errors, the "go to definition" feature, an immediate mode window, and so on. Right now, creating all of these features essentially requires you to write almost a complete C# compiler because there's no way to get anything out of the current C# compiler other than assemblies or error messages. You have to write a parser to do syntax highlighting, a semantic analyzer to be able to go to definitions, etc.

What Roslyn is intended to do is allow you to create these features without having to write your own compiler. It will give you a syntax tree, perform semantic analysis, and more. You can simply give Roslyn the source code and ask it for a syntax tree or what symbol the user's hovering their cursor over. Of course, there's no need to restrict its features to code editors; it's also intended for use by static analysis tools, and obviously it will be used for actually compiling source code to assemblies (whether to compile your project to an EXE or to compile ASPX files in memory).

What Roslyn is not intended to do is allow you to create new languages on top of C#, whether it's macros, metaprogramming, aspects, or whatever. Just because it's not intended for such things, though, doesn't mean you can't or shouldn't do it.