[Mono-dev] Inline assembly in C#

[Jon Purdy]

Would this be AOT-only? And should a method be allowed to contain a mix of
inline assembly and managed code? These greatly affect whatever design we
might come up with.

If assembly can appear anywhere in a managed method, you need something
like the GCC extended asm notation so you can specify inputs, outputs, and
clobbers to determine things like addressing modes and register allocation
for the surrounding code. It¹s also useful to have ³volatile² (don¹t move
this) and ³goto² (may jump to managed label), but these are maybe less
critical.

I would be in favor of the simpler alternative of restricting inline
assembly to a whole method:

    public unsafe __asm__(x86_64) int ReturnOne ()  {
        "movl $1, %rax"
    }

    public unsafe __asm__(ppc) int ReturnOne () {
        "li r3, 1"
    }

    public __asm__ int ReturnOne () {
        return 1;
    }


The idea is that when you compile (AOT) or load+compile (JIT) this
assembly on x86-64, the __asm__(x86_64) method is selected and the
__asm__(ppc) method is ignored entirely; if you¹re compiling on neither
x86-64 nor PowerPC, the managed fallback is chosen. I suppose the fallback
could also be written in IL:

    public unsafe __asm__(cil) int ReturnOne () {
        "ldc.i4 1"
        "ret"
    }


However, this comes at the cost of some expressiveness and inhibits
optimisations.


On 6/1/17, 6:59 AM, "Mono-devel-list on behalf of Miguel de Icaza via
Mono-devel-list" <mono-devel-list-bounces at lists.dot.net on behalf of
mono-devel-list at lists.dot.net> wrote:

>Hello,
>
>These are good observations.    If we ever do this (I am not saying we
>are, I just wanted to get this off my head), we would indeed require
>assemblies for 32/64 on the same system.
>
>Any work that we did to support inline assembly would need some extra
>work on the runtime, so adding support for mixed-mode execution would
>fall into the sort of work we would need to do.
>
>Anyways, this is a very good catch, and it means that the original design
>was probably best.   And it is still an independent issue from having an
>inline assembler in place.
>
>Miguel.
>
>On 5/30/17, 1:58 PM, "Vincent Povirk" <madewokherd at gmail.com> wrote:
>
>    > Now that Mono is switching to platform-specific assemblies for the
>core
>    > assemblies as opposed to cross-platform assemblies that work across
>Windows,
>    > Mac and Linux (a price we pay to converge with CoreFX) it made me
>wonder if
>    > we could not reuse instead the existing support for mixed-mode
>assemblies in
>    > the CLR.
>    
>    What you're suggesting are architecture-specific assemblies, not
>    platform-specific. So you would be multiplying the platform variations
>    by the set of architecture variations.
>    
>    This would be a problem for Wine Mono's use case. Currently we can use
>    one set of class libraries with 32-bit and 64-bit Mono dll's. We would
>    need a mechanism to load some different class libraries based on
>    architecture.
>    
>    > Essentially, instead of having inline assembly in the body of a
>method, we
>    > could define entire method as inline assembly, and set the method
>    > implementation flags in the ECMA metadata to be native and point to
>the
>    > code.   It is not as flexible, but would eliminate the need for a
>    > post-processor, and would merely require the C# compiler to perform
>the
>    > assembly code generation and injection.
>    
>    You would also have to extend the Mono runtime to support mixed-mode
>    assemblies on non-Windows platforms.
>    
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.dot.net
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.dot.
>net%2Fmailman%2Flistinfo%2Fmono-devel-list&data=02%7C01%7Cjopur%40microsof
>t.com%7C8ded07862a7b48c9590608d4a8f667e9%7C72f988bf86f141af91ab2d7cd011db4
>7%7C1%7C0%7C636319223645828454&sdata=4JueGESfWp8sLKAYXKibnUTZQNu1NBcsPwmpB
>lWtaTg%3D&reserved=0