none
Some queries about the CLI, CLR, and Compiler. RRS feed

  • Question

  • Hi,

    I am doing some self-teaching into the stuff behind the scenes, but I have got rather confused regarding changes to the CLI, CLR, and Compiler (due to new .NET Framework releases), hopefully somebody on here can help!

    The following are my understandings of the CLI, CLR, and Compiler, if I have misundertood and points, I would be very grateful if you could point them out.

    1. The CLI specification has not changed since it's original release
    2. The CLR is changed when improvements are made to existing CLR conversations from CLI to machine code.
    3. As the CLI specification is static, there are no 'new' functionality is added to CLR releases.
    4. The C# (or any other language) compiler is updated when new language features are added, e.g LINQ or bugs/performance improvements are found. Are there any other reasons for a compiler being changed?
    5. New BCL features alone don't require a new compiler release.

    I think that is it for the moment. Thanks in advance for any help, it gratefully received.
    Thursday, February 18, 2010 9:51 AM

Answers

  • CLR is a bit more than converting IL to CLI, it has JIT compiling, interoperability, library loading, garbage collection, native threading, etc... So I guess it's natural to expect it to change more often than just IL->machine code improvements. About the CLI, I believe it has been pretty much static ever since its conception.

    About the compiler: features, bugs, performance improvements are basically what drives software changes all around the software industry, so what other reasons had you had in mind that could require a compiler to be changed?

    It's  true that BCL features alone don't require compiler changes, unless the BCL features trigger the development of a new language feature, such as syntatic suggar to access that new BCL feature. A perfectly good example would be the creation of a Nullable<T> type and the syntatic suggar "int?" to create a "Nullable<Int32>". Oh wait, they've already created it :)
    • Marked as answer by SS323 Thursday, February 18, 2010 3:45 PM
    Thursday, February 18, 2010 3:17 PM

All replies

  • CLR is a bit more than converting IL to CLI, it has JIT compiling, interoperability, library loading, garbage collection, native threading, etc... So I guess it's natural to expect it to change more often than just IL->machine code improvements. About the CLI, I believe it has been pretty much static ever since its conception.

    About the compiler: features, bugs, performance improvements are basically what drives software changes all around the software industry, so what other reasons had you had in mind that could require a compiler to be changed?

    It's  true that BCL features alone don't require compiler changes, unless the BCL features trigger the development of a new language feature, such as syntatic suggar to access that new BCL feature. A perfectly good example would be the creation of a Nullable<T> type and the syntatic suggar "int?" to create a "Nullable<Int32>". Oh wait, they've already created it :)
    • Marked as answer by SS323 Thursday, February 18, 2010 3:45 PM
    Thursday, February 18, 2010 3:17 PM
  • Bruno, thank you very much. I think that answers pretty much everything I wanted to know, especially around the CLR.
    Thursday, February 18, 2010 3:46 PM
  • Re 1: Is CLI spec static?
    Well not that much. For example .NET Fx 2.0 introduced generics. That had to be spec'd in the CLI ECMA spec (and it was a huge change to the CLI). I believe that CLR implementation (which was in progress at that moment) was inspiration/motivation for the CLI spec changes.
    It is the same way as the original CLI (v1) spec was motivated by (at that moment not yet released) CLR 1.0 implementation. CLI spec wasn't created from scratch before CLR implementation started.

    There are ongoing updates to the CLI spec. Some little things there are wrong, some are ambiguous, some useful things implemented in CLR are missing. All CLI changes go through ECMA commitee, so it is not like that we (MS/CLR team) can change there whatever we want.
    To give you some examples:
      - Type forwarders are not spec'd in the current CLI version (or in the recent CLI version). Because it is useful concept widely used, we decided to add it to the spec. It was not there so far probably just by mistake rather than on purpose.
      - We discovered recently some bugs in CLR around ambiguities e.g. interface variance casting. That topic is not covered in the spec at all. Therefore it is time to look at it, think how it should work and spec it. It also is useful to look at CLR - how it works there (while ignoring bugs). The CLR implementation is a good reference and check that the CLI spec updates are implementable.
      - Behavior of MethodImpls was described in the CLI spec such way that it didn't make sense in certain corner cases. Again, we worked on updating the CLI spec to make sense and be consistent with itself. Again CLR implementation was a motivation for the spec.

    In the future one can imagine CLI updates or breaking changes if they are needed for further platform improvement. If we find that some things are needed (and asked by our customers, like for example generics in 2.0) and that they require changes to IL instructions, adding new IL instructions, or something like that, we might go that way. Of course if it is possible to implement the new feature without CLI changes, then it is the preferred solution, but that is not always truth.

    Another 2 main CLR features categories came into my mind:
    1. Features which are not covered in CLI at all - e.g. all of COM interop. Therefore all improvements in that area are OK - e.g. Type Equivalency in .NET Fx 4.0.
    2. Features which do not need CLI updates, because CLI doesn't restrict the implementation in that area - for example Collecitble Assemblies. Nothing in CLI spec forbids such new behavior of assemblies, although it is very different behavior against the past. One can imagine that Collectible Assemblies won't be restricted only to Reflection.Emit in the future and any assembly can eventually be collected/unloaded when it is not needed anymore. That is a feature many customers ask for.

    -Karel

    Please note that this is my personal view, not any official Microsoft/CLR team response.
    Thursday, February 18, 2010 8:13 PM
    Moderator