Microsoft Starts Working On an LLVM-Based Compiler For .NET
125
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.
Developers, Developer, Developers (Score:5, Insightful)
Re:Developers, Developer, Developers (Score:4, Interesting)
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)
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.
I think that the people at OpenCOBOL... (Score:2)
...would beg to differ, with this fact from the COBOL wiki:
I would bet you that COBOL environments have had 1/10th, and perhaps 1/100th of the security problems as systems based on C.
So cancel GNUCobol then. (Score:2)
Did you have directory delete permissions?
http://savannah.gnu.org/projects/gnucobol [gnu.org]
Re: (Score:1)
How about 2009 then?
https://cis.hfcc.edu/faq/cobol
Re: (Score:2)
I would believe these numbers if they pertained to the financial sector but there's no way they account for 80% of the business code running today (in 1997-99, probably). If it's true then I wrote 1 / 2,000,000 of the business code in use.
There was a huge shift towards web technologies in the early 2000. The % of market share for COBOL would have started to drop significantly within the last 10-15 years. One sign is the removal of COBOL courses in universities and colleges.
COBOL has slumped to 12% as of 2011 (Score:2)
Still nothing to sneeze [qsm.com] at.
Re: (Score:2)
The fact is that COBOL is in decline. It isn't used for new projects and most projects are probably in maintenance mode (that's me speculating based on people I know who work for financial institutions). Maybe nothing to sneeze at BUT I wouldn't pick COBOL for a new project..
Re: (Score:2)
I'll agree with you: COBOL systems have much fewer security problems as C systems. This is because nobody used COBOL to do anything fancy. If you wrote a device driver or piece of web software in both COBOL and C, I'd expect a lot more security problems in the COBOL system. Writing a financial reporting program in C is going to give you a lot fewer security problems than something like SSL.
Re:Developers, Developer, Developers (Score:5, Interesting)
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.
Re: (Score:3)
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)
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)
.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)
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.
Re: Developers, Developer, Developers (Score:2)
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)
"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)
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)
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?
Re: (Score:2)
Re: (Score:1)
Nope streams only offers the lambda, not expression (= half-compiled code which may be translated into SQL and XML and many other uses), and it's NOT compatible with existing iterable/collection APIs which means its use is very inconvenient and limited. If you really want to use those features you have to try my library jxtn.core.axi [github.com] which modifies system interfaces to add such functionality.
The expression stuff can be done by runtime bytecode analysis (not officially), i.e. reverting your bytecode back int
Re: (Score:3)
The nice thing about LINQ is that it covers more ground than just basic map/filter/reduce; notably, joins - which makes it possible to actually reasonably translate expression trees to SQL and such. And joins are a pain in the ass to write using raw lambdas, the sugar is very welcome there.
Deep nested queries are also often convenient with sugar, because it has "let" for temporary values.
Re: (Score:2)
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
Re: (Score:3)
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: Developers, Developer, Developers (Score:2)
Yeah just target .net 2.0 and compile it on the server.
Re: (Score:1)
Re: (Score:2)
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)
I anticipate Stallman may have a heart attack soon.
Re: (Score:3, Insightful)
http://developers.slashdot.org/story/15/02/08/210241/rms-objects-to-support-for-llvms-debugger-in-gnu-emacss-gudel
Re: Anticipating RMS response (Score:2)
Rms won't sleep until gcc outputs gpl. (write that in bash)
Re: (Score:2)
but nobody sensible develops .NET without Visual Studio. .NET is becoming true to its Java roots - write once (on a Windows box with Microsoft tools and you might as well use Outlook and Office too) run anywhere.
Re: Few understand this (Score:2)
Xamarin is actually a VERY nice visual studio alternative. Not just for mobile either..
Re: (Score:2)
Im not arguing whether SecureBoot is good or bad, but you're making several false technical statements and Im not a big fan of arguments premised on BS.
Bootsector malware is (or was) exceedingly common on Windows XP and 7, to the point where I was regularly using tools like aswMBR and GMER to remove it. Thats why there are so many tools to detect it-- it was quite common. Sinowal, TDSS, Whistler, and several other rootkits infect the boot sector.
In any case Microsoft is not forcing OEMs to do anything. T
Hard to trust them (Score:2)
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
Re: (Score:2)
You could not exchange documents with someone with a 4 years older Office. And this simple feature, exchanging data, had to be enforced by legal pressure...
Say what? Uh, no. Office has always allowed exchanging data to where ever, from where ever. I think you've drank too much of some funky cool aid. Word has always allowed saving to and from the 1997 version (.doc), or to other formats (.txt, .rtf, .xml, .xps, .wps), it also allows saving to .pdf, and the newer .docx format in both strict and non-strict. You could always access the document via COM/OLE as well, and read and manipulate it, and there were public hooks for writing your own code to read/writ
Re: Hard to trust them (Score:2)
http://m.youtube.com/watch?v=P... [youtube.com]
Re: (Score:2)
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)
Re: (Score:2)
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)
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)
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)
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.
Re: (Score:2)
Or if you want to get evil, asm.js ..
Then write a javascript interpreter in C#
Re: (Score:2)
This is in support of CoreCLR, the version of .NET without any Windows dependencies (or that's the plan, anyway, they're not there yet, I don't think).
Re: (Score:3)
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)
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)
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
Re: (Score:2)
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.
Re: (Score:2)
I think that "by their proprietary compiler", he was referring to the JIT compiler.
Open source attempts (Score:1)
Or perhaps MS wants out of the language biz (Score:1)
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
Re: (Score:2)
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.
Re: Or perhaps MS wants out of the language biz (Score:2)
Tell that to the office team. When we get C# as the embedded language in office, maybe then VB can die. For now, it lives on like a zombie dragged, toothless, by an ex-lover through the programming landscape by its old OLE apis.
EEE (Score:1)
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.
Re: (Score:2)
Where do you see "their version of LLVM" here anywhere?
Re:I didn't get the memo (Score:2)
Re: (Score:2)
Don't believe what Anonymous Cowards say. They are typically clueless. The next version of .NET should be released in the next 1-6 months (I'm guessing around 4).
Re: (Score:2)
The IP of the MS update server must have been set to 0.0.0.0 in his hosts file. Mystery solved.
Re: Holy acronyms Batman! (Score:2)
You're not. This is a tech website. Click the link near the box where you typed 'Google.com' marked 'Martha Stewart'
This makes a LOT of sense for Microsoft (Score:3)
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.