Support embedded il instructions

[muhamad]

This is a proposal to add new keyword to allow writing inline IL code directly inside C# code for example

using System;

public void WriteMessage()
{
    var message = "a message to console";

    il
    {
        ldlocal.0
        call void Console::WriteLine(string)
    };
}

[HaloFour]

If I recall it was considered quite an effort to try to add IL to the C# specification, including all of the glue syntax that would be required for IL to support C# constructs and vice versa. The team instead is looking to expose "compiler intrinsics", or special methods that would be converted by the compiler into IL operations, in order to represent special IL operations that cannot be generated easily by normal C# code. dotnet/roslyn#11475

[HaloFour]

I couldn't find a previous request for embedded IL on the Roslyn repo or CodePlex. Could be that my Search-Fu is failing me. Anyway, the issue on compiler intrinsics addresses the concept but it's good to have this issue as a place to discuss the concept.

[jnm2]

@HaloFour dotnet/roslyn#13735

Edit: Oh hey #226

[HaloFour]

Figures, I was only looking on Roslyn.

Anyway, #428 is more like this issue whereas #226 is much more open ended.

[jnm2]

Fwiw I searched dotnet/roslyn is:issue asm il and skimmed the 11 titles that showed up.

[muhamad]

In MSDN, they have example of using Dynamic binding before DLR and after

/*before*/ Scriptobj.SetProperty("Count", ((int)GetProperty("Count")) + 1);
/*after*/  scriptobj.Count += 1;

so if it's going to be so much effort to add inline assembler why just not treat it as a dynamic language - which it is from JIT point-of-view - and embed it in the output and let JIT do the checking.

and let me say that it is allowed for us to add dynamic IL using ILGenerator and if we add invalid instruction it get caught at runtime and and exception thrown which we are responsible for emitting invalid instruction.

[HaloFour]

@muh00mad

so if it's going to be so much effort to add inline assembler why just not treat it as a dynamic language - which it is from JIT point-of-view - and embed it in the output and let JIT do the checking.

The compiler would still be required to take the text of the IL instructions and compile them into the corresponding IL byte code. That has to happen at compile time. The CLR/JIT has no concept what ldlocal.0 is, it only knows 0x06 which is the single byte instruction that it compiles to. The only way to do that within the compiler is to extend the compiler to understand IL syntax.

And then there is the issue of integration. What does ldlocal.0 mean embedded within a C# method? The locals emitted by the C# compiler don't have to be in any particular order and the compiler is free to both optimize out declared locals as well as introduce additional unnamed locals. This is why in IL you assign slot numbers to each variable. But as an embedded language you'd need the C# compiler and the IL compiler to work together using a dialect so that you can reference the local by name.

[svick]

Why? When would you want to use this (assuming the dotnet/roslyn#11475 IL intrinsics existed)?

[mattwar]

This feature suggestion makes me IL. 😆

[muhamad]

The compiler would still be required to take the text of the IL instructions and compile them into the corresponding IL byte code. That has to happen at compile time. The CLR/JIT has no concept what ldlocal.0 is, it only knows 0x06 which is the single byte instruction that it compiles to. The only way to do that within the compiler is to extend the compiler to understand IL syntax.

AFAIK the work already been done here and all it needs is a some - minor - effort to add into the compiler source.

Why? When would you want to use this (assuming the dotnet/roslyn#11475 IL intrinsics existed)?

Some project I'm working on require fast alternative to PropertInfo.SetValue with simple interface for ValueTypes and ReferenceType so the function was SetValue(object instance, string name, object Value)
which works fine for reference types but for value type it didn't work at all for obvious reasons so here is the example I implemented to solve the problem using DynamicMethod, this example works fine even if SampleType was reference type

struct SampleType
{
    public int Number { get; set; }
}

class Program
{
    public static void Main()
    {
        var type = default(SampleType);
        object o = type;
        SetValue(o, nameof(SampleType.Number), 10)
    }

    public static void SetValue(object instance, string name, object value)
    {
        if (name == "Number")
        {
            // invalid in c#
            //((SampleType)instance).Number = (int)value;

            // valid in c#, the modified object is not the target object but the local one
            //SampleType sampleType = (SampleType)instance;
            //sampleType.Number = (int)value;

            il
            {
                ldarg.1
                unbox SampleType
                ldarg.3
                unbox.any [mscorlib]System.Int32
                call instance void SampleType::set_Number(int32)
            }
            return;
        }
        throw new Exception("name not found");
    }
}

The compiler intrinsics is not confirmed yet and if it is going to be added it will be some functions so the IL code above will be something like

using Microsoft.CSharp.Intrinsics;

    CompilerIntrinsics.LdArg(1); // CompilerIntrinsics.LdArg(int index)
    CompilerIntrinsics.Unbox(typeof(SampleType)); // CompilerIntrinsics.Unbox(type)
    CompilerIntrinsics.LdArg(3); // CompilerIntrinsics.LdArg(int index)
    CompilerIntrinsics.UnboxAny(typeof(SampleType)); // CompilerIntrinsics.UnboxAny(type)
    CompilerIntrinsics.Call(typeof(SampleType).GetProperty(nameof(Range.Number).GetSetMethod); // CompilerIntrinsics.Call(MethodInfo metthod)

which is more effective from end-user point-of-view?

[mattwar]

I think you both want ldarg.0 and ldarg.2

[bondsbw]

I'd still like to see either multi-language projects or language extensibility.

Compiler intrinsics will also be welcome, but it solves a different set of problems.

[HaloFour]

@muh00mad

AFAIK the work already been done here and all it needs is a some - minor - effort to add into the compiler source.

That project was already referenced, and no, it would not take minor work. It would take massive complicated work in order to integrate with the compiler, IDE, debugger, E&C, refactoring, etc. It's not sufficient to hack it in there.

which is more effective from end-user point-of-view?

For something that should be exceptionally rarely used? Probably the one which has any likelihood of getting implemented and would actually get the job done.

[svick]

@muh00mad

The compiler intrinsics is not confirmed yet and if it is going to be added it will be some functions so the IL code above will be something like

No, it won't. There is nothing in the proposal about supporting "common" IL instructions like ldarg or call. So it wouldn't work for this use case.

[svick]

@muh00mad

I think that use case is an argument to add an Unbox method, which uses ref return to avoid the copy, either as an intrinsic or similar to methods on the Unsafe type (which are just simple methods implemented in IL).

With that, your code could look like this:

public static void SetValue(object instance, string name, object value)
{
    if (name == "Number")
    {
        ref SampleType sampleType = ref Unbox<SampleType>(instance);

        sampleType.Number = (int)value;

        return;
    }
    throw new Exception("name not found");
}

The implementation of Unbox:

.method public hidebysig static !!T& Unbox<valuetype T>(object o) cil managed aggressiveinlining
{
    .maxstack 1
    ldarg.0
    unbox !!T
    ret
}

[333fred]

Is there still any interest in this feature?

This feature is not championed, so there is no place for it in the schedule currently. See https://github.com/dotnet/csharplang/blob/master/README.md#design-process.

[AdamSpeight2008]

@06needhamt Even though the feature isn't championed, if you would like to have a go at implementing the feature. Go ahead and prototype it.

[333fred]

Go ahead and prototype it.

I want to be clear though: a PR to roslyn with an implementation for a unchampioned, undiscussed feature will be closed. Unless and until the feature is championed by a member of the LDT, the feature is not open for inclusion in the language.

[CyrusNajmabadi]

You are, of course, always welcome to do wahtever you want in your own forks. But Fred is correct, the explicit team stance on this sort of thing is that a PR for that would be rejected for not following proper procedure.

[msedi]

@06needhamt : As long as there is missing support in C# and some things can only be accomplished by using IL I agree that there needs to be some mechanism. The question is, if you need it integrated in C# or if it's better to have some official and well supported ilproj?

[tannergooding]

to have some official and well supported ilproj?

There is an ilproj SDK that is used by dotnet/runtime. It allows you to easily compile IL into assemblies, but doesn't provide intellisense or VS project system support.

some things can only be accomplished by using IL I agree that there needs to be some mechanism

The few things that are missing (like function pointers) have championed proposals (generally speaking) and are being worked on.

Other cases can be handled by things like dynamic methods. Dynamic methods or methods explicitly written in pure IL tends to work better as well since the compiler doesn't have to optimize around you inserting arbitrary IL. The same goes for inline asm in C/C++ and is one of the reasons intrinsics are preferred.

[msedi]

@tannergooding: I agree with the things that are solved with the championed proposals. I also agree to use intrinsics. The embedded asm {} in C++ was in my opinion only for microoptimizations. But what about math on generics? I can currently only do it in IL. I'm not aware that something has been championed by this.

I needed to write my own assembly that holds basic math on generics, but only for these 6 methods I had to write my own assembly that I could have embedded into my own core assembly if there was a possibility to do so. There are of course arguments around here that an assembly does not matter, but we have around 200 assemblies and in the end it does matter.

If there would be a possibility to add an *.il file to my project that is compiled and added that would be just fine for me. I don't need to embed code directly, only if there's performance drawback in a method call vs. embedded code.

[tannergooding]

But what about math on generics?

Provided it is over a value type, the JIT supports generic specialization which ensures the codegen is optimal.

For example: https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBDAzgWwB8ABAJgEYBYAKGIAYACY8gOgCUBXAOwwEt8YLAMIR8AB14AbGFADKMgG68wMXAG4aNYgGYmpBkIYBvGgzMNT5gPRWGAFQAWvXA2wYMUXsA4YYDZwwQXJIAngwAZtAMGA5+uA7YUGKS2MAMACbOeLgw+MDSUJZmNgwAkhj+uFwA5BVcMDDpjf5c0bGuYBgc2JIMkE1FDADasglJADKp7Nx8AiwAUrwYAOIw9Z5gABQYIWIwEOGbHJJBAOYAlOdogwyjiWKTwNM8/IKLK2syytu7+4e8PEu12o5jMdwmU04Lzm71W62+Oz2B024RObiBN3BD0hM1eCyWcK+W0Rf02yw4vHSlwAuoMhgBZGAxCDpUriSSbRnM1nsgDyYj4QVwLAAgqdTrBcLheAoYPzZrwAF5uXhBc60kHmHRMchIewMEXpdIAHjsAD5NnYGJIHLg0PqoLbzsYbuZeOEGD8kYc7M6ALx+6K/ZEAjCXV1mEya0ExpgAdk9vs2EGAACsYJ1zptNqGsyn05mbS4ANSe3PJtMZsOO3DnDTRmMAXwjDBgkhy/g9XtJvoYAaD3pRaLD5xbUdjsYUiQYkuOFUDAFUuLhsOFBCLcKb7aiIG4LbAPUXnaWlyu16LN3Zt8P9zAPTW6y3QcQE6fV+vNzu3PbzZsDzPVDnR8G1BZsQPMNsO3dT0SWRXt+1gw5jjOcNwMjJ8tQTS080rTNs2QrgLgrAswyLBhSyOE5CJwkjzgfesJwYMDGMgmAxwwswYigCAAHcGHqPjSi4KdJEpfkZBVIIAFEEBUAVVS4TZgMY5jzDAxsgA

You can see in each case where a typeof(T) == typeof(...) check exists and T is a value type, it optimizes away the dead code (any path where the typeof check would be false). The downsides of this approach are:

• It doesn't work for reference types
• You have to explicitly codify the supported T
• The IL gets bigger, so you may need [MethodImpl(MethodImplOptions.AggressiveInlining)] on the method
• The code may be less readable due to casts ((T)(object)result and (...)(object)value) or using Unsafe.As

But it works and generates highly optimized code.

[msedi]

@tannergooding: Yes, I know this approach and it is far from being optimal. To be honest - and I don't want to sound rude - the fact that it can be done does not mean that it's good. Our code is highly cluttered with the methods described and is also far from being maintainable, since every code path needs to be implemented explicitly. This means that every change means changing all pathes. When you are doing a lot of number crunching this can be annoying like hell ;-)

One can see the result of having no math on generics: Math -> MathF. Even though there might be differences in the internal behaviors, but I think Math.Abs and MathF.Abs is a good example where it would help to have support on generics.

One can see that you only do this once and never touch it again, but it is the time to develop these pieces of code and to maintain them. And as said before in math and physical environments where you need to develop algorithms this could help a lot.

[IS4Code]

Powerful JIT can help optimize away certain "pathological" casts, but it doesn't mean the casts are no longer pathological themselves.

I wholeheartedly support this idea, even though specifying it would essentially require to add another language into the specification. In the past, others have also objected that adding arbitrary CIL could make the code horribly wrong or simply invalid, but now with tools like Unsafe, programmers have plenty of ways to destroy their lives, if they wish to accept the possibility by having used these tools in the first place. The same could simply happen with embedded CIL, and thanks to the difficulty of the language, not many people would dare to use it anyway. Besides, you can do virtually the same thing with ILGenerator already, but that is not supported everywhere and has worse performance.

The remaining question is how much of the syntax should be accepted. I think the most powerful option is the best one - cil/il should work in a method, class, or global scope, and allow anything that would normally be allowed in the same context in a pure CIL program.

[HaloFour]

I wholeheartedly support this idea, even though specifying it would essentially require to add another language into the specification.

Sounds like a massive amount of effort to slightly better support the vast minority of library writers.

They already have solutions, slightly less than ideal solutions, but given how often this code needs to be written it doesn't sound like it justifies adding IL (and a hybrid form of IL which would allow interop between IL and C# source). For every one of those use cases there sounds like there are numerous alternative approaches each of which involve many, many magnitudes less effort.

[tannergooding]

One can see the result of having no math on generics: Math -> MathF

This had nothing to do with math/generics but was an overload resolution problem. System.Math was created in v1 of the framework and for a large number of functions only supported double. Because int is implicitly convertible to both float and double, but prefers float, it was a breaking change to add single-precision overloads because it is a silent source breaking change (double d = Math.Sqrt(5); would call Math.Sqrt(float) rather than Math.Sqrt(double)). So we added MathF in order to avoid this issue.

You'd likewise have potential problems even if they were generic from day 1, as not all types may be supported and so you wouldn't get a compile time error for things like Math.Sqrt<Guid> (you would need to rely on analyzers for that).

One can see that you only do this once and never touch it again, but it is the time to develop these pieces of code and to maintain them

Yes, it is effectively a write once situation. There are only a limited number of types (the runtime primitives) where you can use IL instructions to perform arithmetic or other logical operations. These can be trivially supported via a small generic helper class and then never need to be touched again.

Any other type ends up being a call to a user-defined operator (including types like System.Decimal which is only a C# primitive, not a .NET primitive) and would likely fit into one of the shapes proposals that are already being tracked.

[msedi]

@tannergooding: I'm curious about the syntax. Let's assume I want to generalize Add and I have primitive times and types with an overloaded + operator. Do I need two different kinds of Add methods:

T Add<T>(T a, T b) where T : struct

and another (I don't know the final syntax)

T Add<T> (T a, T b) where T : shape

and the CLR emits different pathes or is it then subsumed under one Add method?

[tannergooding]

That would depend entirely on how the shapes proposal was implemented, among other factors.

[cschuchardt88]

I think this should be more like C\C++ __asm { opcodes } as for Dotnet is should look like __ilasm { opcodes }

    class Program
    {
        static unsafe void Main(string[] args)
        {
            __ilasm
            {
                ldstr "Hello World"
                call System.Console::WriteLine(string)
            }
        }
    }

    class Program
    {
        static unsafe void Main(string[] args)
        {
           string HelloString = "Hello World";

            __ilasm
            {
                ldstr &HelloString
                call System.Console::WriteLine(string)
            }
        }
    }

[colejohnson66]

This is already possible with external packages, specifically InlineIL.Fody. You can even combine C# and "IL" in the same method.

I would like to see support for this feature, but for now, a solution does exist.

[cschuchardt88]

I just want to copy il from ildasm.exe and have it work. But thank you. Just hate having to call methods.

[CyrusNajmabadi]

There is no plan or appetite to do anything here in the language space. If you want to work with IL, there are options available to you.

[tannergooding]

Even in languages like C/C++, inline assembly is not a truly standard feature. While the spec does define asm( string_literal ), how it actually works is implementation defined and is not universally supported. Using such a feature is also typically considered bad practice and can often lead to worse overall performance due to it causing a general inability for the compiler to actually do its job.

Compilers do not do well when they cannot perform inference over a block of code, when they cannot recognize patterns, do transformations, or when they are otherwise artificially restricted from being able to freely pick the optimal use of CPU/system resources

Manually writing IL is no different and more often that not you're likely de-optimizing your code by writing it, especially if you deviate from the patterns that something like Roslyn would emit (which is largely what the JIT/AOT and other tools are built around recognizing).

There are very few IL features that C# cannot express today and even fewer that are not polyfilled via runtime provided functionality like System.Runtime.CompilerServices.Unsafe or similar. The things that can't be expressed are often under-tested and under-optimized by the runtime itself. Because of that, you will almost always get overall better code, performance, stability, readability, maintainability, etc by simply writing standard C# instead of trying to be "clever" and work against the tooling.