C# for ARM

[jnc100]

The ARM port of my CIL to native code compiler (tysila) has now reached the stage where it can compile simple C# to ARM code. The code at rpi_test/Program.cs can now be successfully run on the Raspberry Pi and prints 'Hello from C#!' on the serial port.

Obviously its a very early work-in-progress and many things will not work, but I'll be looking to expand the range of code it can work on over the coming weeks.

Regards,
John.

[dozniak]

Nicely done!

[Air]

Good job
What features your CIL have and how much opcodes it support?

[jnc100]

The frontend supports all CIL opcodes (with some very limited exceptions of opcodes like arglist and endfilter which are not used in mainstream .NET languages anyway) and converts this into an intermediate language. There exist various different backends for different architectures (x86_64, i386 and ARM) which support the various intermediate language opcodes to a greater or lesser extent. The ARM backend is currently the least completely implemented, particularly with regard to floating-point opcodes and some bitwise operators (purely because these have not been required to assemble the functions I have tested it on). For many opcodes, however, if there is not a concrete implementation in the assembler itself, a function call to a library function is used instead (similar to how gcc outputs calls to libgcc functions on certain architectures).

Regards,
John.

[Air]

Cool
I asked exactly about CIL because i saw some extra opcodes in your sources. How did you use them?
And the final question(if, of course, this endless questions are not annoying you) is why did names for assembly functions look like this:

Code: Select all

_ZN8libsupcs17libsupcs#2Ex86_643CpuM_0_7get_Cr2_Ry_P0:

[jnc100]

The frontend converts CIL opcodes to intermediate representation opcodes which are listed here via the function EncodeOpcode (and the helper functions in that file). The code then undergoes a series of optimization passes before being converted to machine code by the code snippets referenced in the various backends. These are listed in the arch_init_opcodes() function (e.g. for x86_64/i586 and for ARM).

why did names for assembly functions look like this:

Code: Select all

_ZN8libsupcs17libsupcs#2Ex86_643CpuM_0_7get_Cr2_Ry_P0:

This is a mangled version of the C# function:

Code: Select all

namespace libsupcs.x86_64 {
    class Cpu {
        public extern static ulong Cr2 { get; }
    }
}

in module libsupcs. The getter function of the Cr2 property is tagged as [MethodImpl(MethodImplOptions.InternalCall)] to identify to the compiler that it doesn't have an implementation and that the compiler will provide it instead. When a function like this is called, first enc_intcall() is called to see if the compiler actually does provide it. If it does, then the function is inlined, else a call to an external function with that mangled name is emitted. Eventually I plan on incorporating a lot of these cpu-specific functions as inlineable internal calls, I just haven't got around to it yet.

The reason the names are mangled is that, exactly like C++, multiple functions in both the same and different classes can have the same name, and therefore each needs a unique identifier to use in the linking phase. The mangling rules are here.

Regards,
John.

[Air]

Thanks man. Now i understand how it works - So you choose implement architecture-depended functions out of compiler-generated-code and c# code instead of including them in That look easy to implement but ...when compiler will grow ,code will grow too since it need support for each extra function you have. Does it make any bad impact on performance?

[jnc100]

when compiler will grow ,code will grow too since it need support for each extra function you have.

The number of architecture-specific functions (i.e. those which cannot be encoded through equivalent high level language instructions) is small and doesn't carry much footprint, so this isn't really an issue.

Does it make any bad impact on performance?

These functions are called relatively infrequently and therefore any performance loss caused by adding one extra function call into the mix is small. As I said, inling them is something I plan to do, but given how relatively infrequently an OS will update the control registers for example, I simply cannot make it a priority at the moment.

Regards,
John.