[Mono-dev] Inline assembly in C#

Fri Jun 2 23:38:01 UTC 2017

If we ever build this, I do not think it should be AOT only.

Inline assembly in a method has the problems that you outlined, namely that we do need to sort out input/output/clobbers.   By isolating this to a method, we can just say "These are the Mono calling conventions, follow these".

The inline method as well as my original proposal have one advantage: both of them can be implemented without requiring changes to the metadata format, the former by having the JIT recognize a special method call sequence, and the latter by leveraging the existing mixed-mode execution that is supported in the file format.

Your new proposal would allow us to provide multiple implementations, but would require either a file format change.

Perhaps what we could do is flag the method with "RTSPECIALNAME" or "SPECIALNAME" when we do inline assembly, and only when this flag is set, we could trigger a slower method lookup system that lookups the real method based on the architecture.

So you would write:

public unsafe asm(x86) ReturnOne () { movl $1, %rax }

public unsafe asm(ppc) ReturnOne () { li r3, 1 }

public unsafe asm(default) ReturnOne () { return 1; }

The compiler would generate x86_ReturnOne, ppc_ReturnOne and ReturnOne, the last one with "SPECIALNAME" set and an attribute [AsmImplementations(x86,ppc)] which would trigger the runtime to resolve the call to the right method.

That sounds like it would address all the requirements.

Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: Jon Purdy
Sent: Friday, June 2, 2017 4:49:04 PM
To: Miguel de Icaza
Cc: mono-devel-list at lists.dot.net
Subject: Re: [Mono-dev] Inline assembly in C#

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170602/5a6f0092/attachment.html>