Proposal on XSharp interface

[zarlo]

I am proposing that we use a fluent API for XSharp like this https://gitlab.com/liquip/liquip/-/blob/7921298f4f73b412a52bab313172df7c41761e5d/Liquip/RDseed.cs#L56 this will map well to a string builder and will allow better showing of control flow

The POC will target yasm and x86 and just emitting the asm string

[ascpixi]

I voiced my concerns about implementing X# in v3 in #35. Quoting:

Are we sure we need the X# builder API surface? While it would be nice, I think it'd be a lot more code to maintain, especially given the fact that x86-64 has a lot of ISA extensions itself. If we're limiting inline assembly to the minimum, wouldn't X# be extremely underutilized in this scenario?

I believe that we could get by if we only did what is currently known as LiteralAssemblerCode in IL2CPU. That is, when defining an inline assembly method, we would do the following:

[InlineAssembly]
public static void ReadCr3() {
  InlineAssembly.Literal("""
    mov rax, cr3
    ret
  """);
}

...or, alternatively:

[InlineAssembly(
  """
    mov rax, cr3
    ret
  """
)]
public static extern void ReadCr3();

The latter would be easier to manipulate from compile-time IL weavers. That is, we would only need to read custom attribute data, rather than interpret known IL patterns.

[zarlo]

I voiced my concerns about implementing X# in v3 in #35. Quoting:

Are we sure we need the X# builder API surface? While it would be nice, I think it'd be a lot more code to maintain, especially given the fact that x86-64 has a lot of ISA extensions itself. If we're limiting inline assembly to the minimum, wouldn't X# be extremely underutilized in this scenario?
I believe that we could get by if we only did what is currently known as LiteralAssemblerCode in IL2CPU. That is, when defining an inline assembly method, we would do the following:
[InlineAssembly]
public static void ReadCr3() {
InlineAssembly.Literal("""
mov rax, cr3
ret
""");
}

...or, alternatively:
[InlineAssembly(
"""
mov rax, cr3
ret
"""
)]
public static extern void ReadCr3();

The latter would be easier to manipulate from compile-time IL weavers. That is, we would only need to read custom attribute data, rather than interpret known IL patterns.

so what you are getting at is to have ilc emit it?

[ascpixi]

so what you are getting at is to have ilc emit it?

Well, we'd have something similar to what X# did - that is, extract assembly code from CLR assemblies to files - but it would realistically only support string literals. We'd probably introduce some common header to the generated file.

Do note that this will introduce a whole another build step. I'm not sure if inline assembly is worth it if most functions would be defined in their own standalone assembly files; e.g.

(C#)

[RuntimeImport("x86_getcr3")]
public static extern nuint GetCr3();

(NASM x86-64 Assembly)

align 16
global x86_getcr3
x86_getcr3:
  mov rax, cr3
  ret

This is the approach most kernels take, e.g. Linux, WinNT, *BSD, etc...

[zarlo]

mmm I think that could work like we have a path search to include .s files have YASM build it and we pass the build consts from .net to it

so like in the cosmos nuget package there would be a folder asm/[cpu type]/**.s

[valentinbreiz]

there would be a folder asm/[cpu type]/**.s

I think this will be way simpler for long term support + community contributions