It's been a pleasure talking with developers here, on MSDN forums, at conferences, and via email.  But my departure doesn't mean that you won't hear from me -- some of you also must watch TV, so I hope to continue having conversations with some of you over there.  It may not be in this particular blog, but I don't think it will be hard to find me...

Lastly, I hope you're enjoying Visual Studio 2008.  It's a great release.  And this division will continue to delight you in future releases -- even if I'm not actively working on them  :-)

So please, leave a comment (or email) letting me know what code samples and/or documentation you'd like to see.  We'll do our best to make it happen either for this upcoming SDK or some future version of the SDK -- or maybe even this blog.

Phase	Phase Action
CxxIL Reader	Converts CxxIL to Phoenix IR.
Warnings Analysis Detection Phase	Detects and emits back-end warnings (C4700, C4701, and so on).
Add CallGraph Call Site Information	Modifies call graph (if present) to refer to specific call sites within the function.
Inliner	Inlines functions.
Type Checker	Verifies that IR is correctly typed.
Flow Optimization	Streamlines control flow (for example, eliminates jumps to jumps).
MIR Lower	Lowers object model instructions.
Loop recognition and loop transformations	Performs basic loop restructuring.
Global optimization	Performs optimizations such as constant propagation, global value numbering, constant subexpression elimination, and dead code elimination.
Loop optimizations	Recognizes induction variables for strength reduction and loop-invariant code motion.
GS Shadow Copying	Implements the /GS option (stack security).
GS Security Cookie Allocation	Implements the /GS option (stack security).
X86 scalar Sse	Prepares the compiler to use SSE floating point instead of x87 floating point.
Canonicalize	Transforms IR to canonical form in preparation for lowering.
ShiftExpansion Strength Reduction	Transform multiplications and divisions by constants into shifts and additions.
Address Mode Builder	Transforms HIR/MIR to take advantage of target architecture's built-in addressing modes.
Lower	Lowers most instructions to machine level.
SSA-based idioms optimization phase	Performs classic "peephole" optimizations.
Priority Order Register Allocation	Assigns registers to operands.
X87 Stack Allocation	Allocates the x87 stack.
GS Security Cookie Initialization and Check	Implements the /GS option (stack security).
Native EH Lower	Expresses exception handling the way that the run-time convention expects.
Stack Packer	Assigns stack locations to operands.
Frame Generation	Determines shape of stack frame for the function.
Switch Lower	Lowers switch instructions.
Dead Stores	Removes dead stores (that is, stores that are guaranteed not to be read).
Block Layout	Places IR in final order.
Flow Optimization	Removes jump-to-jump and jump-to-next instructions.
Finish EH Lower	Finishes the process begun by Native EH Lower.
Encoding	Produces machine encoding for IR, and debug information.
Emission	Puts encoded IR into the object file.
Emit Referenced Symbols	Verifies the references made from the encoded IR to ensure that the compiler emits a fully closed set of functions and data.
Assembly Listing	Produces the .asm listing file.

 The issue is when there is some code like the following:

    class BaseClass

    {

    }

    class InheritedClass : BaseClass

    {

        void SomeFunction() { }

    }

And you have a pointer to the SomeFunction function unit, how do you find out the associated base class of that function (in this case it is BaseClass).

The answer is: 

functionSymbol.EnclosingAggregateType.PrimaryBaseAggregateType

o    A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary.

o    A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary.

So, what does this mean for code that you might write?  Let's look at the Read Acquire semantics in an example.  In this example the volatile variable has the name 'V'.

Read Acquire Semantics:

Store A

Load B

Load V

Store C

Load D

The Read Acquire semantics say that Store C and Load D must remain below Load V.  Store A and Load B are not constrained by Load V (at least, they have no constraint as a result of the load acquire semantics, but other hardware constraints may constrain their movement).

Now let’s look at Store Release semantics.  Again, the volatile variable is 'V':

Store Release Semantics:

Store A

Load B

Store V

Store C

Load D

The store release semantics state that Store A and Load B must remain about Store V.  In this case Store C and Load D are not constrained by Store V (again, at least not with respect to the store release semantics). 

OK, this behavior is exactly what many people want.  So what they often do at this point is they use volatile in code and then they look at the generated assembly code to see what type of synchronization the compiler introduces to ensure that the acquire/release semantics are preserved.  (Note, that the compiler has internal constraints which ensure that the compiler does not violate these semantics when it generates code).   For many people they're surprised to see that there are no synchronization primitives used.  Wait, this can't be right?!  How do we keep the CPU from violating these semantics without some type of lfence or sfence or something?  Well lets talk about what the hardware might do to our instruction sequence. 

With respect to a single core all loads and stores are perceived by the programmer to occur in program order (note, that when I say program order, at this point I mean the assembly program).  There is no reordering that occurs.  OK, that makes things easy, but again that's just a single core looking at its own instruction sequence.

But things get more interesting when you have more than one processor/core (doesn't it always?).  Across processors, one "might" see different ordering, i.e., processor 1 might observe loads/stores retired in a different order than processor 0 has in its program order (note, this is probably the weakest memory model you will see on x86/x64, but if we work here, we'll work for something stronger).  Hmmm… that may cause problems for our volatile (or will it?).  Lets dig into what this reordering Processor 1 might observe is.

The possible reordering that Processor 1 might observe is that Loads can pass Stores (as long as the Store is non-conflicting).  But Loads with respect to other Loads will remain ordered.  And Stores with respect to other Stores will remain ordered.  Lets see an example:

Original Program Order on Processor 0:

Load A

Store B

Load C

Load D

Store E

Load F

Possible Reordering Processor 1 Might See:

Load A

Load C

Load D

Store B

Load F

Store E

or

Load A

Load C

Load D

Load F

Store B

Store E

If you look at this, you see that Loads can "float" upwards past Stores (again, as long as the Store is non-conflicting), and "can" continue to float upwards  until it hits another Load. 

So how does this affect our volatile semantics?  Let’s start with the Read Acquire semantics example (example copied from above):

Read Acquire Semantics:

Store A

Load B

Load V

Store C

Load D

Another processor observing this instruction sequence may see Load B float above Store A, which is fine (no violation).  But since Store's don't float upward, Store C must remain below Load V.  Load D can float upward, but it can't go past another Load, so it can't pass Load V.  Thus any instruction originally below Load V, will be observed by another processor to execute after Load V.  Good.

Now let’s look at the Store Release Semantics (again, copied from above):

Store Release Semantics:

Store A

Load B

Store V

Store C

Load D

In this case Load D can float past Store C and Store V, but Store Release semantics don't care about instructions that occur below the Store V, so no violation here.  Loads can float upward, but not downward, so Load B can not be observed to execute after Store V.  And Store's are always observed in program order.  Again we're good.  So our volatile model is preserved, even with this reordering semantics.

Last thing… these rules don't apply to SSE streaming instructions or fast string operations; so if you are using weakly ordered instructions, then you'll need to use lfence, sfence, mfence, etc...

PS - On Itanium, with its weaker memory model, we generate ld.acquire and st.release instructions explicitly. 

If you didn't sign-up, hopefully we'll have some more events in the future.

Note that we can raise managed code to Phx.FunctionUnit.SymbolicFunctionUnitState.

The next thing is that the PLDI 2007 Tutorial info is now posted and you can get info on the Phoenix tutorial.  It is located at: https://ties.ucsd.edu/PLDI/tutorials.shtml#phoenix.  Conference registration is not expected until May 12th, so mark your calendars.  Also, the webpage lists the tutorial for 2-hours, but it is a 4-hour tutorial. 

 That's it for now.  More shortly...

https://connect.microsoft.com/site/sitehome.aspx?SiteID=214

From the description on the webpage:

"Phoenix RDK March 2007 features improved API naming, more optimizations, volatile supports for acquire/release semantics, improvements to c2 generated debug information, more robust and accurate raising of MSIL to LIR, improved conditional branch semantics, and improved documentation."

Some other cool news is that there is a Phoenix MSDN Forum now!  In the past the forum was restricted to only academics, and it was on more difficult to use message board system.  Now we've joined all of the other Visual Studio technologies in the MSDN Forum, and it is open to everyone.  So if you have any questions, or comments, that's a great place to post them!

And just as a reminder the Phoenix CGO tutorial is coming up in just a about a week.  I got to sit in a dry run session at Microsoft that Andy Ayers gave and it's some cool stuff.  We didn't do the whole tutorial, but we used extension objects, the dataflow/simulation package, and had fun with flow graphs and the bit-vector package.  Online registration I believe is closed, but there are still spaces open if you register onsite.

And lastly, myself, Jim Hogg, and Andy Ayers had our proposal for a Phoenix tutorial at PLDI 2007 accepted.  While it will also be hands-on, the focus will be on building tools.  More info on this as I get it.  Also, if people have feedback on what they'd like to see in a hands-on tutorial, please let me know.  We have plenty of time to custom craft it.

For the optimizations, the Phoenix C++ code generator will generate much better code with this new RDK, although the code quality still won't be quite as good as the shipping Visual C++ 2005 compiler.

What will probably be the most visible difference to users of the RDK is that we have done some name auditing, and now the names for classes, methods, properties, etc are a lot clearer, and we removed needless (and often confusing) abbreviations.  Additionally, we needed to be more inline with our own company's guidelines on building .NET class libraries.  We will also ship a tool in the RDK that will help you convert your existing Phoenix code to use these new names, so we're making this transition as easy as possible

All in all, we think that this will go a decent ways towards making the API usable.  And I know this is something that many people have inquired about.