Unlike Rotor v1, Rotor v2 is much closer to the shipping implementation of .NET Framework. I would like to highlight several changes between Rotor v1 and v2 that reduced the differences between Rotor and .NET Framework:

- The name of the .dll that contains the core CLR used to be sscoree.dll in Rotor v1. It is mscorwks.dll in Rotor v2 - the same name as in .NET Framework v2. sscoree.dll is just a thin shim in Rotor v2, very much like mscoree.dll in .NET Framework.

- Rotor v1 used a unique flavor of cdecl calling convention on x86 (documented in docs\techinfo\stackframe.html). The calling convention used by Rotor v2 is exactly same as the calling convention used by .NET Framework. It is documented in ECMA Partition II (http://msdn.microsoft.com/netframework/ecma/) section 15.5.6 (implementation-specific).

- The internal JIT/VM interface is same in both .NET Framework v2 and Rotor v2. It allows mixing and matching of JITs between .NET Framework and Rotor v2. Here are the steps to verify that it indeed works - these steps assume that Rotor has been successfully built already.

1. Disable the FJIT support in Rotor:
D:\sscli20\clr\src>set C_DEFINES=%C_DEFINES:-DFJITONLY=%

2. Copy over the JIT from the retail .NET Framework:
D:\sscli20\clr\src>copy c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll %_NTTREE%\mscorjit.dll

3. Rebuild the core CLR:
D:\sscli20\clr\src>build -c

4. Clix your favorite micro-benchmark to verify that Rotor is running optimized JITed code now.

Enjoy...

-Jan

This posting is provided "AS IS" with no warranties and confers no rights.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com