Sunny Ahuwanya's Blog

Mostly notes on .NET and C#

I Want a Native C# Compiler

Wouldn’t it be nice if C# code could be compiled directly to machine code? Having such a compiler would position C# as a serious system programming language.
Developers would be able to write system software for routers, for instance, in C#.

I don’t see any reason why such a compiler should not exist. In fact, the creation of a native C# compiler will be well justified.

C# is a well designed programming language. It would be a shame if the language is stuck forever with the .NET/Mono frameworks, especially if you consider that there is no reason why the language has to be inextricable tied to these frameworks.
There is no requirement that C# code must compile to IL and there are no language-level assumptions that the compiled code has to be machine-independent.
High-level features routinely used by developers such as threading and reflection, are .NET library calls and have no connection to the language itself. The only high-level feature that the language implies is a garbage collection system. In fact there are language-level hints that C# can be a system-level programming language -- how often do you use the volatile, stackalloc and fixed keywords?

The C# developer base is huge, so a native C# compiler will push the language even further to new platforms and projects that are currently unsuitable for development with C#. It will enable developers to write ALL their code; high-level and low-level in C#. Higher-level code will be compiled to IL, whereas lower-level code will be compiled to machine code.

A native C# compiler would be great for coding libraries, for instance, a proprietary encryption or compression algorithm. With a native C# compiler, an algorithm can be coded in C# and compiled as a native code library. This library can be linked to and used in systems without any .NET (or alternative) frameworks.
The best part is that if this library is needed for a .NET/Mono project -- all that is needed is recompilation and the algorithm will scale to managed code without having to port the library or use unmanaged calls. It will work great in both managed and unmanaged worlds.

The language is an open standard, so anyone with the time, expertise and resources can create a native C# compiler. Also, to be successful, this compiler only needs to support C# version 2.0.
Language features introduced in versions 3.0 and 4.0 are not that important and can be considered “Microsoft extensions” to the C# language. Indeed, Anders Hejlsberg admitted that features added in C# 2.0 were features they didn’t have time or didn’t know how to properly implement in C# 1.0.

If you are still not convinced about the viability of such a compiler, take a look at the compilers available for the D language. They are living proof that such a compiler is feasible and will compile a modern language directly to machine code, complete with a (small) runtime, memory management and type system.


Comments (9) -

  • jsh

    1/29/2009 1:04:11 PM | Reply


  • Apalmer

    1/29/2009 1:23:43 PM | Reply

    Mono, actually can be compiled directly to a binary executable for certain platforms. In fact that was how they were able to get Mono apps running on the IPhone.  Some of what you want done can be accomplished with ngen.exe, which will directly generate the native machine code for your .Net assembly.  

  • ATC

    1/19/2010 11:28:52 AM | Reply

    I agree with you 100%. This looks like it's going to happen soon. There ARE products which "post-build" your IL modules to x86 and statically link .NET dependencies. But of course, this has some serious overhead (namely size). Everyone is quick to shout "Ngen!", but Ngen doesn't make you a native executable. You still need the original .NET module to use the application, and it's only valid for the machine it is generated on. Try using Ngen to make a bootloader or something... :-/ Yeah, really...

    Surprisingly, I know of two operating systems written in C#: Cosmos and Singularity. The former is an open-source project and the latter was a MS research project (and source is now available). I've played with them a bit. They're very bare-bones, but do work! It's very cool! Cosmos has a special build tool which emits .asm (assembler files) which is fed into Nasm (but mind you, it's quite seamless). Then it's Nasm -> x86 binary. They're hoping to refine the process and emit straight native binary soon. I suggest playing with it if you're up for a challenge and some mad fun! Just beware of using high level .NET libraries like System.Threading with Cosmos, or you're in for some disappointment.

    But, this is still not what the C# world (and the programming world for that matter) needs. We need a professional and powerful means of compiling our code straight to native binary; without the need for hacks and expensive deployment tools with major overhead. C# is fully capable, which both of those managed operating systems demonstrate. Microsoft does some brilliant things, but some of the dumbest things they do are the brilliant (and often obvious) things they never did. Regardless of "justification" behind a C# -> native compiler, people want it. Demand = $$$; Some people want it to target low level problems, some people want it to satisfy their delusion that their code will be "hard to crack", some people want it "just cuz" and some people want it because 'native' sounds cool. Who cares why?! Let's just agree it can and should exist, and if you don't want it, don't use it! Smile Simple! The hard part is creating it, which I'm not trying to downplay.

    I have a lot of the knowledge, and all of the ambition... but I have none of the experience and not enough time, lol. So I doubt I'll be the "hero" who creates it, lol. :S But a good first step would be to take the 'simple' route. Create a pre-compiler to process either the C# or IL into assembly op codes, and feed it through something like Nasm (basically, just like the Cosmos people). Then refine the process as much as possible, and spit out a new version when a better way is found. Repeat. Gotta start somewhere, or we'll always wonder what could have been! Frown

  • Sanders

    5/18/2010 6:43:09 PM | Reply

    Maybe someone would produce a GCC based C# compatible compiler... One can dream.

  • digital scale

    6/4/2010 4:27:45 PM | Reply

    I agree with you on the subject. I've always considered to be rather inefficient to have only the IL compiler for the C#. The language itself gives a relaxed environment to the programmer and it's a shame it doesn't have a native compiler.

  • C++ Source Code Directory

    1/14/2011 7:37:31 AM | Reply

    Some of what you want done can be accomplished with ngen.exe, which will directly generate the native machine code for your .Net assembly.

  • Muhammad Shaaban

    9/9/2011 12:10:28 AM | Reply

    You are right sir. c# is limited for .net. and a good programmer does not accept limits like this. c# mus have a compiler for native programing.

  • Jordan

    3/15/2012 6:43:43 AM | Reply

    I have been working with a native version of the .NET framework under C++ and have invented a trick for every c# feature, but it would be nicer if it was just C#.  C# is just a much better version of C++.
    Again, besides the compiler, the .NET framework is the best design out there, if you compare Java and stl, and boost.
    For my native .NET, I inherited from STL and also used LoMsvcrt and LoSTL to bring the size down.  I can make small EXEs with no depencies at all run from XP to 7 and be under 10K.
    The reasoning for this was that we must use both native and .NET code in all our projects.  I found it easier to port the C# code to C++ than the other way around.
    Of course a garbage collector was an option, but instead we use auto_ptrs and just are careful.  A garbage collector would add about 4k to the exe size, and slow the code down.  Our Framework is only implemented as needed, so it's very tiny.  The nice think about the linker is that it only takes what is needed.

  • Eduard

    3/16/2014 5:43:02 PM | Reply

    What about compiler preallocation of the stack when it comes to generic particularisation with value type arguments  ? And I'm not talking about int and bool, I'm talking about any custom struct that one would write. One might respond: the compiler could go ahead and detect all imminent particularisations. How about indeterministic just in time particularisations ? i.e. my code never mentions List<Subscriber> (where Subscriber is a struct which does appear in my code) but at one time, after running 2h and 30 minutes, my process deserialises an instance of List<Subscriber>. This scenario is functional and useful in .NET. Imho if with a native C# we intend to give up on this functionality then that particular C# is a lesser C#.