Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Microsoft Intel Programming

Microsoft Starts Working On an LLVM-Based Compiler For .NET 125

Posted by timothy from the spreading-like-bamboo dept.
An anonymous reader writes Are the days of Microsoft's proprietary compiler over? Microsoft has announced they've started work on a new .NET compiler using LLVM and targets their CoreCLR — any C# program written for the .NET core class libraries can now run on any OS where CoreCLR and LLVM are supported. Right now the compiler only supports JIT compilation but AOT is being worked on along with other features. The new Microsoft LLVM compiler is called LLILC and is MIT-licensed.
This discussion has been archived. No new comments can be posted.

Microsoft Starts Working On an LLVM-Based Compiler For .NET More

Microsoft Starts Working On an LLVM-Based Compiler For .NET

Comments Filter:

  • Developers, Developer, Developers (Score:5, Insightful)

    by CSHARP123 ( 904951 ) on Tuesday April 14, 2015 @10:49AM (#49470929)
    The old CEO was shouting developers, developers and pushing them aside. This CEO doesn't make a peep but quietly bringing in the developers

    • Re:Developers, Developer, Developers (Score:4, Interesting)

      by Richard_at_work ( 517087 ) on Tuesday April 14, 2015 @11:01AM (#49471059)

      How did Ballmer push developers aside? Under the latter part of his reign, Microsoft started open sourcing a lot of their developer frameworks etc (ASP.Net MVC in 2012, Entity Framework in 2013 etc) and we saw fairly large shifts in developer conferences and support.

      • Re:Developers, Developer, Developers (Score:5, Interesting)

        by neilo_1701D ( 2765337 ) on Tuesday April 14, 2015 @11:25AM (#49471249)

        How did Ballmer push developers aside?

        He pushed them aside by killing development systems (VB6,FoxPro), introducing new technologies with the promise of how critical they were to the future (Silverlight), and allowing the crown jewels of Windows development, the Win32 API, to slowly become more irrelevant with endless layers of cruft built on top (eg. .net, although a wonderful system, becomes more and more incompatible with the underlying OS; eg. GDI+).

        Microsoft started open sourcing a lot of their developer frameworks etc (ASP.Net MVC in 2012, Entity Framework in 2013 etc) and we saw fairly large shifts in developer conferences and support

        By your own words, we can infer that Ballmer's middle-empire period required large shifting from where it was to what it became.

        Ballmer wasn't bad; his jumping around on stage shouting "Developers!" showed that he knew what the true value of Windows was: the external developers who wrote Win32 code for retail products or company-internal developers. However, his middle-empire stage was a shift to focusing on selling to enterprise customers. This isn't a bad things by itself, but by taking his eye off the "Developer!" ball and focusing elsewhere, he guaranteed that plenty of developers went elsewhere. For example, with the death of VB plenty of developers shifted to Java rather than .net. The fact that it needed a large shift in support shoes just how far developers had slipped in Microsoft's priority.

        It's interesting to see how Nadella is shifting the focus again and broadening it (Windows 10 on Raspberry Pi, for example). Time will tell if Nadella is simply being an anti-Ballmer or if this glasnost is signs of a more fundamental shift in the way Microsoft does business. I hope it's the latter.

        • Re:Developers, Developer, Developers (Score:5, Interesting)

          by Anonymous Coward on Tuesday April 14, 2015 @12:09PM (#49471775)

          VB6 and FoxPro served their purpose and needed to end. They were prototypes for various parts of what became .Net.

          VB6 was discontinued right away when Microsoft combined VBRUNxxx.DLL with their Java implementation that got shitcanned by the anti-trust courts. Then they refined it into a common language runtime for a VB variant, a Java variant, and a heavily modified variant of C and all of the object oriented stuff that has cropped up around it. Later, they dropped the Java variant. Later still, they added a functional programming language.

          FoxPro was discontinued when they released LINQ, which basically mimics the one thing FoxPro had going for it that nothing else did.

          Win32 has not become "irrelevant", since all of the newer technologies still rely on those older ones. (.Net "winforms" simply packages up the old Win32 WNDCLASSEX and window class registration and instantiation into a handy Form object, so instead of 80+ lines of boiler-plate code, you use a simple new Form() and be done with it. I fail to see how this is anything but progress.)

          And .Net uses GDI and GDI+ [microsoft.com] directly, and has done so since day 1. More recently, it also uses Direct3D [microsoft.com] and Windows Media Framework [microsoft.com] directly.

          It's actually rather amazing that otherwise well-informed people on tech sites keep parroting this panicky crap that naysayers said years ago without doing any research into whether it's correct or not. It seems that the one thing Microsoft hasn't been able to change is the level of trust people place in them. A good portion of that was earned, but it's also about time that some people at least brush a few of the chips off of their shoulders.

          • VB6 was discontinued right away when Microsoft combined VBRUNxxx.DLL with their Java implementation that got shitcanned by the anti-trust courts.

            I though it was because VB6 was a COM product?

            ... Later still, they added a functional programming language.

            Nice sledge :)

            Win32 has not become "irrelevant", since all of the newer technologies still rely on those older ones. (.Net "winforms" simply packages up the old Win32 WNDCLASSEX and window class registration and instantiation into a handy Form object, so instead of 80+ lines of boiler-plate code, you use a simple new Form() and be done with it. I fail to see how this is anything but progress.)

            And .Net uses GDI and GDI+ [microsoft.com] directly, and has done so since day 1.

            I completely agree with everything you've written... if you're a .net programmer, you're fine. But if you're a C programmer sitting directly on top of Win32, you're screwed

            My point, and I guess I didn't make it clearly, is that although these new technologies are fantastic, there is older code out there that is company-critical to companies who invested heavily in the creation of a solution, based on Microsoft's past history of obsessive backward

            • Re: (Score:1)

              by Anonymous Coward

              VB6 was a COM object that implemented a "runtime" component. The same could be said for Microsoft's Java implementation. The runtime that backed VB6 and earlier (VBRUNxxx.DLL) was no less a runtime than the JRE or CLR. OK, it was "less", but it was still a runtime.

              My point was that .Net is an inner platform (as all interpreted-bytecode runtimes are), and thus everything it does can be done, albeit less elegantly, with the underlying native Win32 and COM libraries that it uses.

              I encourage you to read up on w

              • Re: (Score:2)

                by godefroi ( 52421 )

                .NET isn't an interpreted-bytecode runtime. It never has been. It's always been JIT compiled. Always.

            • Re:Developers, Developer, Developers (Score:4, Interesting)

              by Dutch Gun ( 899105 ) on Tuesday April 14, 2015 @03:18PM (#49473517)

              I completely agree with everything you've written... if you're a .net programmer, you're fine. But if you're a C programmer sitting directly on top of Win32, you're screwed

              Lots of cutting-edge applications are still written in C or C++ and directly use the Windows API (it's not called Win32 anymore). In fact, I'd go so far as to say the majority of large commercial applications you can think of are native apps: Photoshop, Microsoft Office, most videogames, web browsers, media players, etc, etc. Nearly all the new APIs released with new versions of Windows are available to native applications. There's no reason a company has to abandon their legacy C codebase if they don't want to. BTW, the "way forward" for C developers is called C++, and it's conveniently backwards compatible with your C codebase.

              The major reason one would consider switching to .NET from native code is productivity, not new functionality. The .NET APIs are much easier to use than the much older Windows APIs, and the languages .NET supports like C# are far easier to use as well. You don't even have to completely abandon your C or C++ code either. It's pretty simple to write interop layers to communicate between C# and C, and have done so many times at work.

        • VB lives on in .NET although it looks like it might finally be dropped in vNext. Silverlight was dropped because technology moved on but is still supported for another 5 years.

        • Re: (Score:2)

          by Xest ( 935314 )

          "He pushed them aside by killing development systems (VB6,FoxPro)"

          Except VB6 and Foxpro were never really developer tools. They were tools for non-developers to get basic programming tasks done. That was kind of exactly why they were developed- things like Visual C++ were always the tools targeted at professional developers.

          "the Win32 API, to slowly become more irrelevant with endless layers of cruft built on top"

          Win32 API became irrelevant, because it's become increasingly irrelevant. Why on earth would yo

    • Re:Developers, Developer, Developers (Score:5, Interesting)

      by ranton ( 36917 ) on Tuesday April 14, 2015 @11:19AM (#49471209)

      Well I can say these announcements have brought me back to developing in .Net. C# has been my favorite language by far ever since v3.5 (and was my favorite by a little since v2.0) but its vendor lock was becoming too much of a liability.

      The moment I can go back to C# and easily have my code run on *nix servers I will drop Java in a heartbeat. Just being able to use LINQ again in my professional life will be a blessing. And going back to Visual Studio over Eclipse / Netbeans / and even IntelliJ is also something I have been longing for.

      • Re: (Score:2)

        by OzPeter ( 195038 )

        Just being able to use LINQ again in my professional life will be a blessing.

        Is there any other language that has something comparable to LINQ?

        • Python list comprehension, which is OK for simple queries but doesn't scale as nicely as LINQ

        • Re: (Score:2)

          by ndykman ( 659315 )

          Not really. Sure, many languages have things like LINQ Select/Where (map/filter), but that's just for objects. It's the expression trees where things get interesting. Expression trees allow a provider to generate a different artifact than a map call over objects. LINQ to Entities creates calls which the Entity Framework turns into SQL.

          You can make a custom provider against any data source, really. There is an example of LINQ to Twitter that turns LINQ queries into Twitter API calls (http://linqtotwitter.cod

      • Depending on what dependencies you use in your code you could have had it running on Linux years ago using Mono.

        I've had good experiences running ASP.NET MVC and console apps on Linux in production environments.

      • Re: (Score:1)

        by Ed Avis ( 5917 )
        So... what is it you need that Mono doesn't do?

    • Different scopes.

      The old CEO wanted to enable developers in house. The new CEO seems to want to enable developers in the community.

  • Anticipating RMS response (Score:3)

    by krel ( 588588 ) <krellNO@SPAMmac.com> on Tuesday April 14, 2015 @10:52AM (#49470965) Homepage

    I anticipate Stallman may have a heart attack soon.

  • I would like to believe that Microsoft really has turned a new corner with this more open strategy but it really is hard. We had to put up with so much rubbish from them over the years with Windows. As someone getting into web development it is also just blatantly obvious they tried to sabotage the adoption of a common standard for a long as possible to prevent the web becoming a cross-platform environment (IE6 I am looking at you). And then there was the whole changing Office pointlessly every two years so

    • I would like to believe that Microsoft really has turned a new corner with this more open strategy but it really is hard.

      "Only Nixon could go to China." How can you ever improve relations with a former enemy if you don't begin to trust them? It takes a bit of a leap of faith, then trust can be built in small steps over a period of time. We see the same sort of thing happening recently with Obama and Raul Castro. They're both taking small steps forward.

      In Microsoft's case, we see them taking a series of small steps toward building credibility in the Open Source world. That won't happen instantly, and there are some folks

      • Re: (Score:2)

        by fisted ( 2295862 )
        They're doing whatever they perceive to be most profitable. If they are assuming closed source is the way to go, then closed source it is. Who gets to decide that, ultimately? The shareholders. What are the shareholders' objectives? Hint: It starts with R and ends in OI

    • Don't conflate "open source" with "good guys". There's nothing inherently bad about a business wanting their own products and platforms to succeed. You'd be a pretty lousy business if that wasn't your goal. It's the *methods* they use to achieve succeed which are the critical factor in that determination.

      It's clear they're serious about their open source strategy, but that's because it makes good business sense, not because they're suddenly embracing all things FOSS. It's just an acknowledgement that th

  • I don't understand (Score:5, Interesting)

    by Blaskowicz ( 634489 ) on Tuesday April 14, 2015 @11:45AM (#49471475)

    With LLVM using an intermediate representation of code (LLVM IR) and CLR another : MSIL, now called CIL, does that mean it goes C# -> LLVM bytecode -> .NET bytecode?, does the JIT does both steps at once, why doesn't that mean every single language with a LLVM target can now run on the CoreCLR?, was LLVM modified, was what's in my first question horribly wrong?

    • Re: (Score:2, Informative)

      by Anonymous Coward
      Other direction; the C# -> .NET bytecode step happens elsewhere, this project handles the .NET bytecode -> LLVM bytecode part:

      LLILC is an Open-Source project that Compiles msIL (.NET) code to native binary, using the LLVM compiler framework. We pronounce it "lilac". The project will provide both a JIT ("Just-In-Time") and an AOT ("Ahead-Of-Time") compiler targeting CoreCLR.

      From the Background [github.com] page of the linked wiki.

    • Re:I don't understand (Score:5, Interesting)

      by HyperQuantum ( 1032422 ) on Tuesday April 14, 2015 @12:22PM (#49471931) Homepage

      I didn't look into the details of the project, but to me it seems to like the following:

      A JIT compiler is used in a virtual machine to run a function/method by compiling it from some sort of bytecode or intermediate representation to native code and then jumping to the generated code to execute it. So in this case this would be when the Common Language Runtime wants to run a CIL method for the first time: it generates LLVM intermediate representation from the CIL, then uses LLVM to compile that to native code.

      So it would be: CIL --> LLVM data --> native code

      This means that the CLR, and thus all code compiled for .NET, can run on all platforms that LLVM can generate native code for.

    • C# -> MSIL / CIL (CLR) -> LLVM bitcode -> machine code.

      The summary is slightly misleading. Though they are working towards using LLVM, they currently have about 90% of their core JIT tests working with LLVM on windows x64, the rest fall back to their current JIT. So you won't be able to use this to run C# on linux / arm for a while yet.

      There's been quite a bit of recent development on JIT support in LLVM. They had an old JIT a few versions ago which had it's own machine code generation pipeline.

  • Make sense, actually (Score:3)

    by Dutch Gun ( 899105 ) on Tuesday April 14, 2015 @11:48AM (#49471517)

    I think it's important to understand that the .NET JIT compiler should probably be considered more part of the .NET *runtime*, not necessarily part of the development platform for .NET. Since they want to port .NET to non-Microsoft operating systems, it makes sense to utilize LLVM to target those platforms for the JIT compiler rather than trying to write a new one from scratch. They needed a solid compiler to accompany their open source .NET platform for it to be a more complete open-source solution. Moreover, they've been extending Visual C++'s support for alternative platforms like Android, so it also makes sense that they'd be gaining expertise with LLVM.

    It's probably not the end of their proprietary compiler, or even necessarily an indication they're thinking this way, but it may make more sense for them to utilize LLVM so as to target a larger number of platforms. They just recently rewrote their own .NET compiler a couple of years ago [infoworld.com] and released it as open source, so it's sort of odd to see a new project so soon. I'm guessing they figured it would be more work to extend that project to support all the platforms they're releasing CoreCLR for than using LLVM. Hard to say.

    Also, there's still the native compiler, used for C/C++, and they've been sinking an enormous amount of development resources into making it compliant with the recent advances in those languages, so it also seems unlikely they're going to toss that work.

    • Re: (Score:1)

      by Anonymous Coward

      I think you misundertand how .NET is split. The new .NET compiler (Roslyn) is actually a program to convert source code (C#, VB) into CIL (common intermediate language). It is the CIL that is contained in a .NET executable file, and the JIT compiler turns this IL code into machine code. The LLILC project is intended to use LLVM as the JIT, and to give you the ability to compile to machine code ahead of time (rather than at runtime).

      dom

      • Ah, I see... ok, that makes a bit more sense then. So Roslyn is more or less the front end of the compiler tool chain, while LLVM is the back end, so to speak. Thanks for the clarification.

      • I think that "by their proprietary compiler", he was referring to the JIT compiler.

  • There is a couple of open source projects doing this already: http://csnative.codeplex.com/ [codeplex.com] https://github.com/xen2/SharpL... [github.com]

  • What better way to no rid themselves of an annoyance than to open source everything? Microsoft's treatment of their own development community over the last decade has ranged from apathetic to clueless to abusive. No automated migration path to move code from one platform to another. Dead ending VB6. Effectively dead-ending Winforms. Basically telling ISVs with established businesses and skill sets that their only option is an expensive recoding project, after they re-educate themselves.

    I'm pretty sure this

    • Dead ending VB6? Are you kidding? They had been saying that it was being phased out before VB6 was released. It's been dead for 17 years now. Give it a rest already. VB6 SUCKED.

  • Embrace, Extend, Extinguish.

    Though they won't achieve the third one because LLVM is BSD licensed they WILL add incompatible extensions that will be only compilable with their version of LLVM. It will happen.

  • This makes a LOT of sense for Microsoft (Score:3)

    by jonwil ( 467024 ) on Tuesday April 14, 2015 @04:36PM (#49474111)

    Right now Microsoft has a JIT compiler running on a few platforms that translates .NET byte code into native code. Instead of reinventing the wheel and writing their own JIT compiler for a bunch other platforms they want to be able to run .NET code on, they are instead using something that already exists in the form of LLVM.

    They aren't abandoning anything, just using LLVM instead of rolling their own JIT compiler on certain platforms where doing so makes sense.

Slashdot Top Deals

If all else fails, lower your standards.

Close