1

I am aware of the Shared Source Common Language Infrastructure and also the MethodImplOptions Enumeration. I am interested to learn more about how the .NET runtime is implemented.

For example, in his answer to the following question; Hans Passant talks about how Math.Pow() is implemented in C++ in: clr/src/vm/ecall.cpp: How is Math.Pow() implemented in .NET Framework?. My question is: how do you know to look in that file in the first place? Is it because you know the code so well or is there a reference somewhere? i.e. a reference that says that Math.Pow() is implemented in: ecall.cpp

Community
  • 1
  • 1
w0051977
  • 15,099
  • 32
  • 152
  • 329
  • 1
    Yes, I studied SSCLI20 to know to look there. – Hans Passant Jan 31 '13 at 18:59
  • @Hans Passant, thanks for the comment. I will mark the question as answered if you are willing to post an answer. – w0051977 Jan 31 '13 at 19:06
  • The SSCLI source is out of date now as I understand that it is based on .net 2.0. I also understand that the purpose of SSCLI was to give developers the opportunity to make .net portable with other platforms. Is there an updated version of SSCLI? – w0051977 Jan 31 '13 at 20:54

1 Answers1

4

Well, you could poke around in the sources of the SSCLI. But I guess that is not what you were after :-)

You can however narrow down the false positives of a plain findstr /s /i "pow" *.*.

You'd start by decompiling (or disassembling, if you feel like it) the System.Math class. You would find it in mscorlib.dll, which MSDN would tell you in case you didn't know.

If you do, you'll see that the method doesn't actually have a body defined there, but merely the signature. It has the MethodImplAttribute assigned, though. Which bears the value of MethodImplOptions.InternalCall. Again, looking at MSDN tells you, that this method is

"The call is internal, that is, it calls a method that is implemented within the common language runtime." (emphasis added).

This should give you one important hint: it is probably implemented in C or more like C++, since that is the language that is used to implement the CLR itself.

Knowing that, you do a search over all the C++ source files of the SSCLI.

findstr /s /i "pow" *.cpp

That narrows down the hits considerably, but still is a lot of stuff. Know it is really time to experiment, like make the search case sensitive, and look for whole words only (to exclude stuff like "power").

findstr /s /r "\<Pow\>" *.cpp

Doing this will, for this example, return only two hits:

clr\src\classlibnative\float\comfloat.cpp:FCIMPL2_VV(double, COMDouble::Pow, double x, double y)
clr\src\vm\ecall.cpp:    FCFuncElement("Pow", COMDouble::Pow)

The output pretty much gives it away then: Pow seems to be somehow related to COMDouble::Pow, which is show also.

Frankly, I don't remember how I really came up with the knowledge that InterallCall / instrinct functions (or there lookup tables, if you will) can be found in clr\src\vm\ecall.cpp, but the above is what I would have done, if I need to again.

To add to Hans' comment to your question about having studied the SSCLI, I would say that in general it is always educational, heck even "entertaining" if you're geek enough, to read and explore other codebases. Especially, when they are related to the technology domain you are currently working in. I guess many people have been spelunking in the BCL and other .NET libraries, either using decompiling or the public available sources, which even have comment. But the CLR itself is also quite interesting, even with the SSCLI being somewhat outdated by know. Another interesting thing, IMHO, are the CRT (C/C++ runtime library) sources that are installed with Visual Studio (e.g. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt).

Christian.K
  • 47,778
  • 10
  • 99
  • 143