[RESOLVED] Why Phoenix? What is the benefit of a new architecture?

I've heard that Microsoft will abandon development of its standard C/C++ compiler and put all its efforts into a new compiler named Phoenix. Can you

1) give a brief history of what started this push (what caused you to throw your hands up and say "this can't be done" in the current code base)
2) how will you allocate human resources to who is going to be involved in the two compilers
3) What is the transition strategy for projects within Microsoft (i.e. will OS or Office team use Phoenix any time soon or do you need suitable resources on the existing compiler for a very long time)
4) What effort will be put into legacy code. Is this going to be a "new projects only" type compiler or will compiling legacy code be a very high priority.
5) Can you give a bit of description of the mechanics of supporting two different compilers internally in Microsoft i.e. do you ever envision a point where you will have to make fixes to two compilers in parallel (being caught in the situation where a single team of developers must be intimately familiar with two separate code trees?) or are the team members that you are grooming for the future going to be specialists on only one set of code (i.e. either legacy or Phoenix)

Hi Ted. My name is Kang Su Gatlin and I'm a program manager on the Codenaname: Phoenix team. I was on the Visual C++ team up until a few weeks ago when the Visual C++ team split into two: one part keeping the Visual C++ name and the other part taking on the name of Phoenix.

You ask some interesting questions and I'll attempt to answer these.

First, Phoenix is not a compiler per se, but rather a framework for developing tools for program analysis and transformation. Compilers are one, but only one, of the kinds of tools that will be built on TOP of Phoenix. I should note that the backend of the compiler (c2.dll) will be built on Phoenix, but not the front-end (c1xx.dll) (at least not in the first release of Phoenix).

1) I wrote a short history of Phoenix here: http://blogs.msdn.com/kangsu/archive...16/493744.aspx.

2) First, remember that Phoenix is a full framework while the compiler backend is simply one client of Phoenix (for example other clients like PreFast will also at some point be built on Phoenix). So with that it makes hard to compare as it's not really apples to apples. With that said I would expect resources to continue to slowly move from UTC to Phoenix, but UTC is responsible for delivering Orcas so it needs to be staffed accordingly (although Orcas won't have near the c2.dll changes that you saw going from VC2003 to VC2005).

3) Divisions and teams at Microsoft are free to use the compiler of their choice. One of the main reasons we're doing the Phoenix project is for Windows, and we're working with them to make sure that Phoenix-based compilers and tools work well for Windows. As you might imagine there are a LOT of teams at Microsoft, but one of our goals is to make sure that Phoenix-based tools and compilers are so compelling that no one prefers to stay with an older version of the toolset.

4) If by legacy code, you mean legacy source code, that will be very high-priority. If by legacy code, you mean legacy binaries (as Phoenix can raise binaries up to an intermediate representation and re-optimize them) then we will support raising binaries that have certain kind of debug format. For example, today it requires the linker to use the /PROFILE option. So for really old binaries, you will not be able to raise them to do binary analysis or re-optimization.

5) We actually have the situation with multiple compiler trees today. There is the UTC compiler tree for x86/x64/Itanium. There's the x86 JIT tree. The x64/Itanium JIT tree, and then the mobile devices tree. All having different teams (as you can see this is one of the reasons we wanted Phoenix as well). At some point down the line UTC will be servicing mode only, but we have not yet figured out how the teams will be structured around it.

I hope these help Ted. And I'd suggest going to http://research.microsoft.com/phoenix and/or my blog to get more information on Phoenix. We do have a downloadable pre-alpha RDK that will give you more insight into what Phoenix actually is, and what types of capabilities it will have.

Thanks,

Kang Su Gatlin
Codename: Phoenix Program Manager