Generating classes and methods at run time using Reflection

[bencz]

Are there any plans to implement the reflection system in the project, if so, do you have any idea how it will work to generate methods and classes at runtime, and execute this code?

For exemple, if we have this code:

    static void Main(string[] args)
    {
        const string AssemblyName = "HelloWorld.dll";
        var assembly = AssemblyBuilder.DefineDynamicAssembly(new AssemblyName(AssemblyName), AssemblyBuilderAccess.RunAndCollect);
        var module = assembly.DefineDynamicModule(AssemblyName);
        var methodBuilder = module.DefineGlobalMethod("HelloWorld", MethodAttributes.Final | MethodAttributes.Public | MethodAttributes.Static, typeof(void), new Type[0]);
        var ilGenerator = methodBuilder.GetILGenerator();

        var writeline = typeof(Console).GetMethod("WriteLine", BindingFlags.Public | BindingFlags.Static, Type.DefaultBinder, new[] { typeof(string) }, null);
        ilGenerator.Emit(OpCodes.Ldstr, "Hello World");
        ilGenerator.EmitCall(OpCodes.Call, writeline, new[] { typeof(string) });
        ilGenerator.Emit(OpCodes.Ret);

        module.CreateGlobalFunctions();
        var helloWorld = module.GetMethod("HelloWorld");
        helloWorld.Invoke(null, null);
        Console.ReadLine();
    }

How would IL2C handle this?
Would it be necessary to implement an 'interpreter'?

[kekyo]

@bencz Unfortunately IL2C doesn't support any reflection API's include emits, but I'm interesting for dynamic emitter :)

In IL2C scope, we have to make native binary emitter or call native binary compiler in the runtime environment. For example, IL2C can use in non-OSes IoT environment and likes. The problems are how to invoke gcc and another compiler toolchains onto these platforms, or we can dynamic emitting the native binary onto these platform if IL2C's runtime library include it.

(It's too large and difficult embedding it...)

Are you thinking about where your apps build onto?

[sgf]

.net 5, .net 6 will integrate a code generator, and it will be simple to implement static reflection. Dynamic reflection can be considered from the long time(Not now).

[kekyo]

@sgf I feel the code generator manipulates at only a compile time, so we can use it different situation how use informations about.

I think bencz says about emitting, so it means about runtime interpreter if possible. I have a concept for IL bytecode interpreter implementation, but currently not implemented on IL2C runtime...

[bencz]

@kekyo maybe (just an idea), using the Mono MSIL interpreter, is something viable

[kekyo]

@bencz Sure, we can enable emitter with few ideas:

• Native IL interpreter: mono interpreter or like
• Native IL translator: Aggressive and challenging, but it can be implemented only rich environment (maybe can't bare-metals)
• (Bit compromise) LINQ expression reducer, but it can't handle generate new type metadata.

IL interpreter and translator have very difficult topics (related how to resolve and fixup another assembly metadata at runtime time on multi platform included bare-metals rather than code generator. I feel we also have to decline some features...)

I feel better choice for IL2C is LINQ expression reducer, because it makes practical and (maybe) easier implementations. Even so consider have to how to implement reflection ability on multi-platform at runtime time. I have no idea now, do you think about it?

[bencz]

@kekyo Take a look in this project that I'm developing https://github.com/bencz/IronNet/tree/master/source
I started this project because I want to be able to run .net programs on big iron servers, and on 'different' operating systems, such as IBM i, AS/400, s/390 and z/OS ...

Unlike DotNetAnywhere, IronNet came up with the idea of being bi-endian and with support for operating systems of 31, 32 and 64 bits .... in addition to being developed in the C99 standard (unfortunately, I will have to review this, because on IBM i, some errors occur because of the declaration of the variable ...)

Here, a simple .net exe decompilation running on ILE on IBM i

I am still implementing the interpreter .... IronNet has a translator, which generates an IR from MSIL, which translates to machine code using a JIT or performs the interpretation ... so, it may be possible to use parts of this mine project, to solve this problem ....

One detail, I'm testing IronNet on the following OS and architectures:
Windows x86 and x64
Linux Debian x86 and x64
Linux Debian powerpc and powerpc64 (big endian)
Linux Debian ppc64le
Linux Debian m68k
IBM s/390
IBM z/OS
IBM i
IBM AS/400

[bencz]

Alternatively, DotNetAnywhere can be used ... but, corrections must be made to support Big Endian and x64 architectures ... currently DotNetAnywhere, works only on Little Endian and 32bits systems

I fixed the DotNetAnywhere for B.E architectures...: https://github.com/bencz/IronNet/tree/master/DotNetAnywhere

[kekyo]

I surprised great your project IronNet! Is IR meaning iron servers opcodes declared this?

I think your solution focusing to be neutralizing different endians and instruction bits in translating process, it's very interesting.

Perhaps maybe we hope to need a abstract basis translator framework between CIL/MSIL and others when making translators...

How IronNet fixup another assembly method bodies? I found the System.String.[ch], these types/methods are declared hardcoded by you (and IL2C has similar solution), it crawl up recursively another arbitrary assemblies?

IL2C has to do it, but it will have to big problem, because translation process is made a long time. So I think have to split and turns to library (*.lib, *.a) each assemblies. (and the problem includes how to fixup building mechanism and packaging...)

When talking back, a runtime CIL/MSIL interpreter has to fixup these topics:

• Opcode interpreting (Light side, we know about it perfectly ;)
• Metadata interpreting (Dark side, it contains to fixup between targeting platforms)

[bencz]

Nop, the IR is the intermediate representation, the system converts the MSIL to the IR that I created, so it is possible to make optimizations in the IR, and then later, direct the result of the generated IRs to be interpreted or converted by the JIT

This file you found (System.String.[ch]) is for the DotNetAnywhere project ( oficial project page: https://github.com/chrisdunelm/DotNetAnywhere/ )...
Anyway, I will use the same ideia on IronNet!

About the metadata parsing, this is complex, but, not so much... it's just tedious to implement hahahahaha
You can have some ideia of how this is made, based on my project or on dotnetanywhere... and, it's possible to have some ideia of this, from this another project: https://github.com/LADSoft/DotNetPELib
This lib. was developed to be used in the new OrangeC compiler backend: https://github.com/LADSoft/OrangeC

[kekyo]

These project and your project is interesting.

My concern is where and how to split between ahead compilation and interpretation at both user-side and runtime (included from larger systems to bare metal systems) with balancing topics, between easier user developing platform, automated building (CI/CD, lacks many IoT devs now), can port and adapt minor platforms easier (It's truly multi platform, isn't it? :)

Thank you suggested, I'll make better way (huh, the topics too large for me, maybe advance with incremental...)

off topics:

I feel Orange C is similar to web-assembly targetted compilers. The web-assembly environment have strongly limitation for processing resource-access and memory-managements, but they are succeeded it.