Coffeehouse Thread

7 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

.NET Assembly for beginners?

Back to Forum: Coffeehouse
  • User profile image
    chuawenching

    Hi,

    I had a few questions to ask for a beginner in IL Assembly.

    1) How to code IL then use some tools to convert to c#? Is it possible? I had seens many articles that required you to code c#, convert to *.exe, then use ildasm to convert into IL. I want the opposite way.

    2) Is there any way to debug IL codes like debugging c#? Placing breakpoints, can see how data is transfered?

    3) I do notice that C++.NET do boxing when i write this code.

    int _tmain(void)
    {
        System::Int32 i;
        for (i=0; i<10; i++)
        {
            Console::WriteLine(__box(i));
        }
        return 0;
    }
    

    and c# doesn't do boxing.

    static void Main(string[] args)
    {
        System.Int32 i;
        for (i=0;i<10;i++)
        {
           Console.WriteLine(i);
        }
    }
    

    Does it mean c# doesn't do boxing behind the scene? Why?

    4) Is there any guidelines that IL must be coded like this for C# and like that for VB.NET? It seems the generated codes (using ildasm) for c# and vb.net are a bit different. Hope can write 1 IL and use for everything.

    5) Is there any benefits to code IL and be hardcore on it? Does the industry needs people who is good in .NET and good in IL too?

    Thanks. IL looks great Smiley

  • User profile image
    gusperez

    1.  Check out .NET Reflector.  It should be able to show you some C# code for a given assembly regardless of whether it was originally compiled with ilasm or any other compiler.  Here's a link: http://www.aisto.com/Roeder/DotNet/.

    2.  The Visual Studio debugger doesn't support "disassembling" to IL.  Not sure about other tools out there. 

    3.  Console.WriteLine has several overloads including one that takes an Int32.  In the C++ code snippet you provided, you're explicitly boxing the value before passing it to Console.WriteLine.  If you don't do that, it should probably just work without boxing.  The C# compiler will automatically box the int if it needs to.  In the case of Console.WriteLine, it doesn't need to.  If you use something that just takes an object, such as ArrayList, then you'll see that C# will box it for you.

    4.  The VB and C# compilers don't always emit exactly the same IL.  But it'll probably be pretty similar for the most part.  I think the simple answer to your question is yes, it's one IL for everything.  There are features supported by the CLR that are not supported by all .NET languages.  But in general, interop between languages is great.

    5.  Someone who can read IL will be able to better understand what the code they wrote in a higher-level language (C#, VB, etc.).  We, on the compiler team, read IL very often.  It's one of the first steps we take when trying to figure out if a bug is in the compiler or the JITter or elsewhere.  That said, I'm not sure it's a huge advantage to know IL fluently in general.  It'll sure help, but I don't know of many people that find themselves writing code in IL very often. 

    Hope that helps,
    -gus
    http://blogs.msdn.com/gusperez


  • User profile image
    SMac

    Hi! I'm not an IL expert, but I can answer a few of your questions, as well as my opinion of using IL in this way..

    I hope the experts of IL respond to this so that we can both learn more about IL..

    #1: Going from IL to C# or other higher level language is called disassembly or decompiling. A number of tools are available on various sites, a quick google turned up this site:
    http://www.program-transformation.org/Transform/DotNetDecompilers

    Note though that you are essentially reverse-engineering generated code, what you get won't be the same, although similar to, as if you coded it in a high-level language yourself. Also, since anyone with one of these tools can reverse engineer any .Net IL assembly -- even copyrighted, commercial software, there is a push to obfusicate, or attempt to make it harder, to reverse-generate code in this manner.

    #2: I don't know the answer to this question -- I played around a little bit in VS and under the debug menu was able to attach to an already running .Net process and was able to set breakpoints, however, the source displayed was actual assembly language, not IL.

    #3:

    #4: I'm not completely sure on this question -- but I'll try Wink it is my understanding that any .Net language gets compiled to pure IL code and thus IL is more or less exactly the same -- hence the full name of IL being "Common Intermediate Language". It thus just depends on the ability of the disassembler to reverse engineer IL into whatever higher-level language which the user would want. The differences in IL I believe are due to minor semantics of each language. Also be aware that other various differences may be due to differing timestamps, filesize, assembly version, and module version GUID... but there also might be additional metadata, I don't know..

    #5: My opinion on this one -- the advantage of coding in a high level language -- such as VB.Net, C#, but even C++, C or any other high level language is that the code is easier to view, debug, and maintain. The benefits writing code in IL probably are the same arguments for writing native assembly code in that you can control every variable, every pointer, every method call, every stack push, every stack pop, . The disadvantages are that you're controlling every variable, every pointer.. you get the idea..

    As far as needing IL coders, perhaps this would be a valuable skill in creating compilers for other OS's/Platforms.. (such as the mono (http://www.go-mono.org) project is doing) Crafting custom languages, and aid in debugging.. there's probably alot more too..



    Note that included in the framework are these namespaces:

    System.Reflection.Emit
    System.Reflection.Emit.ILGenerator
    System.CodeDom

    the first allows for generating runtime assemblies and modules, the second emitting IL code at runtime through an extensive object module, and the third contains classes which can be used to generate programmatically source code.


    Looks like this got answered much more concisely by someone who knows what they're talking about so I'll quit Wink

  • User profile image
    chuawenching

    Thanks a lot. Yeah, i roughly know what to do next. Thanks again. Yummy IL taste sweet.

  • User profile image
    ms44cn

    On sourceforge.net .The DILE tools could debug IL code.

  • User profile image
    littleguru

    If you want to get a deep view into the .NET runtime you should read the ECMA-355 standard (aka. Common Language Infrastructure standard).

  • User profile image
    Ion Todirel

    Also if you want to know more about IL you can also try: MS Press - Inside .NET IL Assembler

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.