Phoenix Compiler and Shared Source Common Language Infrastructure

prolj

Results from from the past Compilers, Languages, and Runtimes initiative

For the last several years, we have encouraged and supported research and teaching in the areas of compiler construction, virtual machines, program analysis, and tools that improve understanding of these paradigms. The result has been extensive research and reporting, based on these key tools for researchers.

http://research.microsoft.com/en ... cus/cs/phoenix.aspx

prolj

http://www.infoq.com/news/2008/05/Phoenix-Compiler-Framework

Andy Ayers, an architect on the Phoenix Framework, tries to explain what the Phoenix Compiler Framework is and how it works in a video made by Channel9. Phoenix works as compiler, but it is more than that. It is a software optimization and analysis framework that can be used by other compilers and tools. It can generate binary code, but it can also write MSIL assemblies. The source code can be analyzed and is represented into an IR (Intermediate Representation) form, which can be later analyzed and manipulated with various tools. It does not work as a JITter.

Like any other compiler, Phoenix takes the source code and transforms it into binaries. One main difference is that Phoenix groups all the Microsoft compilers (more than 25 of them) into one, generating the binaries or MSIL code for all the languages and platforms Microsoft supports.

Phoenix is not just a compiler, it's a framework with an API and being extendable via plug-ins. One can use the API to write tools making use of the Phoenix features. For example, one can write his own tool which analyzes the IR files and generates some conclusions on how the source code should be optimized. The plug-able feature is also very handy. Andy says that Microsoft usually needs 1-2 years to generate all the compilers for a new hardware chip that appears. Now, the hardware manufacturer can deliver a Phoenix plug-in used to compile the source code for the new chip when the chip is released to the market.

As any other major Microsoft compiler, Phoenix must pass the test of compiling Windows, Office, Visual Studio, and other several large products which push the compiler to its limits. This is done to ensure the compiler is tested against real-world, complex software in order to detect any bugs existing in it.

The compiler is internally multithreaded resulting in faster build time depending on the platform used for compilation. On a four processor machine, the build time can be 5 times faster than on a single processor one.

Microsoft Connect has recently released the Phoenix SDK - April 2008 CTP. This release has many enhancements and bug fixes over the previous pre-release version made available on July 2007. More information about Phoenix can be found on Microsoft Connect.

prolj

http://www.infoq.com/news/2007/08/phoenix-dotnet;jsessionid=07BF5D1AA6D7F07DEC85FD419350D54C

Phoenix started in Microsoft Research as a project for building compilers and code analysis tools.  First released as a research development kit to educational institutions it is now being readied to be released to the community at large.  Back in February of this year Sarah Derstadt, a Program Manager at Microsoft, announced Phoenix as a Commercial Development Kit:

    Use of Phoenix within the industry is still very restricted to internal research.  Over the next 6 months, the Phoenix team will be transitioning from the RDK/CDK release to our SDK.  This SDK will be available through a Beta program up until we ship with a future version of Visual Studio.

Kang Su provides a brief history of Phoenix:

    Several years ago the Visual C++ was cranking out compiler backends, much as we do today, but there was a growing concern about the cost of retargeting the backend to generate code for new platforms (such as Itanium and the CLR, POWER, ARM, and later x64).  Doing this retargeting was a painful process, and a small group in the VC team decided that it would be worth creating a new backend infrastructure that would allow rapid retargeting to different platforms.

On how the VC++ team and MSR team connected Kang Su continues:

    On the other side of the galaxy in Microsoft Research (MSR), they were doing some of the worlds most advanced binary rewriting and static analysis research.  This took place in different groups with largely overlapping functionality, yet no sharing of code.  When MSR got a whiff of this new project in Visual C++ land they were intrigued.   Eventually, Visual C++, MSR, and the CLR  teams decided they should join forces to create a new project which not only would be a rapid retargeting backend, but a new platform for doing program transformation and analysis.

And on the intended result of their joint work he concludes:

    Additionally, the teams agreed Phoenix should be the code generation platform for all of Microsoft.

In July, Microsoft released a pre-release version of the SDK on Connect.  Phoenix provides a wide variety of building blocks for implementing a common intermediate representation such as:

    * block analysis
    * memory tracing
    * code coverage
    * fault injection
    * run-time profiling and feedback
    * ahead-of-time compilers
    * just-in-time compilers
    * code optimization
          o whole program
          o post-link
          o runtime

Microsoft intends to move from their current list of over 25 code generators to a single platform based on Phoneix.  What further makes Phoenix potentially groundbreaking is the introduction of transparency into the compiler and code generation process.  Thus, breaking the traditional model where the compiler is a black box.

cjaizss

MS一直在集中精力搞定这类东西

jqbsx

c c++ =>  vb  java  c#  ..     now  they  unite  those to  one  .   
waste time and money.

prolj

原帖由 cjaizss 于 2009-2-25 12:56 发表
MS一直在集中精力搞定这类东西

这会给 MS 带来巨大的好处，29 个编译器统一，自己不用再维护那么多 port ，代码质量的提升，更好的反馈纠错。这一切，和 LLVM 简直如出一撤。

原帖由 jqbsx 于 2009-2-25 13:40 发表
c c++ =>  vb  java  c#  ..     now  they  unite  those to  one  .   
waste time and money.

呵呵，这是你的看法。

abutter

原帖由 prolj 于 2009-2-25 17:33 发表

这会给 MS 带来巨大的好处，29 个编译器统一，自己不用再维护那么多 port ，代码质量的提升，更好的反馈纠错。这一切，和 LLVM 简直如出一撤。


呵呵，这是你的看法。

期待 LLVM 赶紧替代 GCC

prolj

原帖由 abutter 于 2009-2-25 20:52 发表
期待 LLVM 赶紧替代 GCC

5 年之内不太可能， clang 还远远不能兼容 GCC 那些 BT 的语法，而 GCC 前端还有一些小瑕砒，使用 GCC 4.2.1 前端我在自己的机器上无法编译 LLVM （现在没时间去找问题所在），也没人有兴趣维护 GCC 前端，都指望 clang 呢。
不过在 BSD 和 Mac 里面是肯定的， Mac 需要一个编译器就像 MS 一样。好不掩饰我是 Jobs 的信徒，我就当他是教主。
更多的新项目也必然会采用 LLVM ，代码清晰啊，速度快，生成代码质量好。文档丰富。咱不玩儿假大空， GCC 的别名分析很难搞， LLVM 通过在 IR 上的限制使得别名分析可以更好一些。同样的无用代码删除，要在优化中执行多次，在 LLVM 这种统一 IR 中只要实现一个就好，可是 GCC 中要实现 GIMPLE 和 RTL 两个版本，虽然 GIMPLE 和 RTL 尽可能的共用一些数据结构，但始终是两种 IR ，优化遍也分为 GIMPLE 遍和 RTL 遍，别名分析也是两种...

cjaizss

原帖由 abutter 于 2009-2-25 20:52 发表


期待 LLVM 赶紧替代 GCC

影响力远不够吧

jqbsx

－－－更多的新项目也必然会采用 LLVM ，代码清晰啊，速度快，生成代码质量好。文档丰富。

除非对LLVM有深入了解，LLVM的自吹自擂亦或道听途说皆不可信。放大优点，缩小缺点，词语模糊笼统，是open和non-open的潜规则。经常上了船，才知道船内部怎么样，想下船就没那么容易了。

－－－咱不玩儿假大空， GCC 的别名分析很难搞， LLVM 通过在 IR 上的限制使得别名分析可以更好一些。同样的无用代码删除，要在优化中执行多次，在 LLVM 这种统一 IR 中只要实现一个就好，可是 GCC 中要实现 GIMPLE 和 RTL 两个版本，虽然 GIMPLE 和 RTL 尽可能的共用一些数据结构，但始终是两种 IR ，优化遍也分为 GIMPLE 遍和 RTL 遍，别名分析也是两种...

(我猜想）GCC 的别名分析有他存才的原因。 LLVM 的方法是有好处，但是有没有前提条件，和潜在的负面影响呢？