InfoQ

News

Catching up with Phoenix

Posted by James Vastbinder on Aug 19, 2007 11:19 PM

Community
.NET
Topics
Research,
.NET Framework
Tags
Phoenix,
Code Generation,
C#,
CLR,
C++

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
    • whole program
    • post-link
    • 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.

1 comment

Reply

Rumors by Greg Young Posted Aug 21, 2007 5:06 PM
  1. Back to top

    Rumors

    Aug 21, 2007 5:06 PM by Greg Young

    It is rumored that 4.0 will involve a move of the .NET JIT to use the Phoenix back-end

Exclusive Content

Rationalizing the Presentation Tier

Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.