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-boun...@lists.dot.net on behalf of
mono-devel-list@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" <madewokh...@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@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@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list
