[Mono-dev] Inline assembly in C#

[James Bellinger]

Please make it so all platforms can be embedded in the same assembly. 
Separate compilation is a mess. And it's not as simple as 'x86-64' vs 
'ppc'. Different CPUs have different instructions.

I can figure out which to call on my own. If I know it's x86-64, beyond 
that, one can do tests and build a library to test for additional CPU 
features.

A method that just takes pointers, even, would be completely usable for 
any game.  Incidentally, if they could all be embedded in this manner, 
it'd make SIMD much more powerful and frankly, even be useful outside of 
Mono, on Windows.

James


On 6/2/2017 5:49 PM, Jon Purdy via Mono-devel-list wrote:
> 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
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.dot.net
> http://lists.dot.net/mailman/listinfo/mono-devel-list