What can Phoenix do for us

I always like to start with litle history then answer the WHY question.

Phoenix History
Several years ago the Visual C++ was cranking out compiler backends, doing platform retargeting (x64, IA64) for example was a painful process, and a small group in the Microsoft VC team decided that it would be worth creating a new backend infrastructure that would allow rapid retargeting to different platforms. On the other side Microsoft Research (MSR) were did some of the worlds most advanced binary rewriting and static analysis research. Retargeting also done by CLR team. Then VC team, MSR, and the CLR  teams finally 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. For doing next generation of compiler. Additionally, this team agreed Phoenix should be the code generation platform for all of Microsoft.  At one point there was something like 25 distinct code generators at Microsoft.  For example, the current x86 JIT/NGEN uses a different codebase from the 64bit JIT/NGEN, which is different than the Visual C++ compiler codebase (though we do share a codebase for the x64, x86, and Itanium Visual C++ compiler).  Microsoft should find a way to leverage the investment in one product (or productization) into that of another as the core needs and requirements are very similar.  Phoenix was born, he is 4 years old.
 
Why Phoenix?
Now why should YOU learn Phoenix?  Because you dont want to use a “God-Given” compiler. You write your codes, you use some compiler switches (/Zi, /O1, O2 /Fa, etc…) during compilation, and at then you get DLL or EXE. As the developer you don’t have knowledge what compiler does, and ironically, you cant control compiler process. Once you get the final DLL/EXE, you cant to anything with it. ILDASM and DUMPBIN can help at this point, but, their use is extremely limited. After you use them, no programmatic way to change the IL or ASM. Why is EXE or DLL are so sexy?  You're their father who built them, yet to analyze your DLL/EXE's behavior or to make modifications to it is really critical.  If you have ever tried to do ASM codes, or binary rewriting, you know that it is hard. With CLR, it easier but, codes around the world is not just C#, J#,C++/CLI or VB.NET. Phoenix's job is to increase your controls to your son, assembly and CIL. Phoenix also shipped with framework as its tittle, means that, reusable for program analysis and transformation. Phoenix is a transparent box not black box like front end compiler we used. Actually not really black box, because in SSCLI, we can see the implementation codes of CL.EXE. Here's the typical flow of source code to program:
 
[C++ Codes] -> cl.exe -> c1xx.dll -> c2.dll -> link.exe ->  program.exe
 
With Phoenix, there will be hooks directly into the code generation process (pipeline), and we can alter our executable son even after it was built. 
 
Examples of Phoenix Use
Here are some ideas from Uncle Kang Su Gatlin blogs

1) You came up with a new algorithm that could automatically parallelize C++ programs.  How should you implement this? Today you'd have to either (A) write your own compiler from scratch, which will almost certainly make it a toy compiler (unless you have a small army of developers), or (B) tap into some existing hard-to-use open-source compiler infrastructure and modify their code.  And if you've ever tried to do this in the past with the popular existing compiler infrastructures, you'll quickly learn that doing option (A) is almost easier. Phoenix has a plug-in model in the back-end, which allows the developer to insert or reorder compiler phases.  Now, you can simply implement a "parallelization" phase (or it may make sense to break it up into multiple phases), and simply hook that phase in-between existing phases.  That's pretty darn cool if you ask me.  In future postings I'll go into more detail on how to do plug-ins to Phoenix, how to add a new phase, and how to write Phoenix code to do useful analysis and code transformations. What makes this all the more impressive is that Phoenix will be THE Microsoft compiler.  No more testing your algorithm on toy programs with toy languages.  Instead, you can now compile real applications with real workloads to understand the impact of your parallelization plug-in.
 
2) You're now working on taking your parallelization framework directly into Visual Studio.  You want to add a new feature in the editor that will place red-squigglies under code to represent code that causes a loop to not be parallelizable (or maybe put in arrows between dependencies in the code).  You can use Phoenix to do the analysis on the code - using your dependence analysis package - and then use this information to determine where to put the squigglies in Visual Studio. And there's even more that Phoenix does.  For example, Phoenix has support to do binary analysis and rewriting.
 
3) You are a consultant that is at a customer site and dealing with debugging an application. You have some libraries that you've written that can do call-stack analysis, but it needs to be invoked by the application at entry to each function. You'd probably need to rewrite the customer's application. With Phoenix you can write a simple application that loads the EXE and raises the machine code into the Phoenix IR.  From there you can add a new function call at entry to each function.  After this, you instruct Phoenix to lower the modified Intermediate Representation back into an executable file.  

 
What would YOU like to do with Phoenix?  I am interesting (my personal research) to use Phoenix for memory management (allocator and GC) analysis tool on native C/C++ code base software :). What about you??

Share this post: | | | |
Published Thursday, September 07, 2006 7:03 AM by Risman Adnan Mattotorang

Comments

No Comments

Leave a Comment

(required) 
(required) 
(optional)
(required) 

Enter the numbers above: