.NET/CLR都開源了，VC++還遠嗎？

01-14

據說CLR在x64下的RyuJIT是從VC++的後端改來的，MS最近把.NET/CLR開源了，不知道有沒有計劃把VC++編譯器一起開源了。

TL;DR：雖然我也跟題主一樣很期待MSVC整體開源，但目前還看不到這方面的動靜。真心希望不久的將來微軟會證明我看錯了——真的把MSVC開源出來 &>_&<

關於RyuJIT與JIT64、MSVC的UTC的關係，請參考下面倆傳送門：

JIT編譯器雜談#1：JIT編譯器的血緣（一） - 編程語言與高級語言虛擬機雜談（仮） - 知乎專欄
RyuJIT為什麼比JIT64編譯速度快？ - 代碼豆的回答

這就是 @代碼豆的回答說的：

老版本CLR在x64（和Itanium）上用的JIT編譯器——JIT64——跟MSVC共用一個編譯器後端——UTC。

新的CLR與CoreCLR的JIT編譯器RyuJIT主體源自老CLR在x86上的JIT——JIT32，基本上就是把改進的JIT32代碼生成部分插在了新寫的前端上；這前端跟JIT64的前端部分有不少相似之處（特別是為了要保持兼容性），不過IR形式改為使用樹形而不是線性。

.NET Native倒是繼續使用UTC作為後端。而其對應開源的CoreRT卻沒有使用UTC，而是默認用RyuJIT，可選用LLILC或ILCompiler（IL-to-C++編譯器）。

下面純廢話，跟MSVC沒直接關係。

=========================================================

開源的背景

商業公司開源一個項目總是得找到個對自己有利的story才合理。像是最近IBM宣布要以OMR項目的形式將其商業的J9 JVM中高性能的組件開源出來，用的story是PaaS——IBM的雲策略。

詳細請跳這個傳送門：如何評價 IBM 的 Ruby + OMR？ - RednaxelaFX 的回答

微軟近來高調開源了許多以前大家都沒想過能開源的東西；相信就算是微軟內部的同學們也不一定能想到，開源會來得這麼快。

但這些新開源的項目都是在同一個主題下的——微軟的雲策略。不只是要吸引別人把程序放在微軟的「雲」（狹義的Azure）上運行，微軟也要把影響力要擴展到各個平台上。

這點 @周航的回答已經提到了。我只是想稍微補充一點。

拿幾個微軟開源的相關項目來看：

CoreCLR: dotnet/coreclr · GitHub
LLILC: dotnet/llilc · GitHub
CoreRT: dotnet/corert · GitHub
ChakraCore: Microsoft/ChakraCore · GitHub

它們都包含從某種源語言編譯到機器碼的編譯器。把編譯到MSIL的Roslyn也算上的話，微軟最近開源的項目里包含產品級編譯器的還真不少。

但我上面列舉的編譯器，開源出來不只是為了賺個吆喝——所謂提升公司形象、社區影響力——而是有求於開源社區幫忙：

高質量的bug report，
或許還能有人幫忙修bug，
但更重要的是，尋求社區資源協助微軟將它們移植到微軟原本不直接支持的平台（OS/CPU）上。

從我的角度看，像ChakraCore這種看似跟IE、Windows綁得死死的的東西，現在決定開源出來，其實跟CoreCLR希望能擴展到其它平台s上是一個道理：

Microsoft Edge』s JavaScript engine to go open-source

ChakraCore is already designed to fit into any application stack that calls for a fast, scalable, and lightweight engine. We intend to make it even more versatile over time, both within and beyond the Windows ecosystem. While the initial January release will be Windows-only, we are committed to bringing ChakraCore to other platforms in the future. We』d invite developers to help us in this pursuit by letting us know which other platforms they』d like to see ChakraCore supported on to help us prioritize future investments, or even by helping port it to the platform of their choice.

現在Windows程序員就可以用JavaScript來寫WinRT / UWP程序，底下執行JavaScript的就是Chakra。那麼假如一個WinRT / UWP程序使用了某些Chakra特有的功能（例如說bytecode caching），而它又想移植到Android或iOS上的話，沒Chakra用多不爽啊——所以要是能把Chakra移植到其它平台也就有用處了。

（當然現實是iOS與Android上好用的app遠多於Windows Phone上，移植通常是從前兩者到後者而很少有反過來的。不過微軟至少得讓技術上能更好的支持反過來的移植才行嘛）

=========================================================

Visual C++與開源？

說了半天背景，跟MSVC有啥關係？

重點就是：微軟在C++編譯器方面也有跨平台策略，但目前看來並不需要開源MSVC來尋求開源社區的支持。

Visual Studio現在就支持開發iOS / Android上的C++應用（現在甚至連Android上的Java應用也支持了）。當編譯目標是iOS / Android時，微軟直接用整合在Visual Studio里的Clang編譯器來做代碼生成。

為了讓用戶在使用Visual Studio開發跨Windows / iOS / Android平台的C++程序時有更一致的體驗，微軟甚至還把Clang與MSVC的後端UTC整合到了一起，做了名為「Clang with Microsoft CodeGen」項目（也叫做clang+c2）。

Bringing Clang to Windows
Clang with Microsoft CodeGen in VS 2015 Update 1
如何評價Clang with Microsoft CodeGen？

所以，把「雲策略」應用在微軟的C++編譯器上，會發現：

在自家的Windows平台上，微軟有

傳統的、閉源的MSVC；
Clang with Microsoft CodeGen：對Clang修改的部分開源，UTC部分閉源；
Clang on Windows：微軟直接參与到把開源的Clang移植到Windows上的項目。當然這個Clang on Windows整個都是開源的，直接貢獻到上游的Clang里。

在iOS / Android等「其它平台」上，微軟

直接用Clang來編譯

這麼一來，Clang已經完全解決了雲策略中覆蓋其它平台的需求。Clang自身是完全開源的，微軟也投入了技術力量進去來讓Clang在Windows上也可以正常使用，這樣就夠了。

所以很難想像微軟會有什麼story來支持把MSVC開源出來…Jim Radigan在CppCon 2015上介紹clang+c2時也提到目前沒有任何計劃開源UTC。

給題主更正一個錯誤，RyuJit是從jit32改過來的，老的jit64確實是從C++的後端改過來的

「Visual C++的開源已經在地平線上了。」

換句話說，它好像在那裡，但永遠到不了。

個人感覺不會 .net開源是基於微軟雲策略

不過cl一直都是免費的學編譯器llvm夠你研究的