CoreCLR Interpreter

[BrzVlad]

This issue tracks required work and progress for the porting of the mono interpreter to CoreCLR. The end goal of this issue is to be able to run entire test suites in full interpreter mode (without any JIT/AOT) on desktop platforms (ex. arm64 linux). This issue will be updated on the fly as the implementation progresses.

M1 - basic compilation and interpreting support of a simple method

• interp wire-in Initial interpreter wire-in #112202
• interp executor in libcoreclr
• interpreter runtime test

M2 - stress tests involving object manipulation

• constant loads and unchecked binops
• ldlocal/ldarg
• static void calls
• full var offset allocator
• basic block formation and implementation of branch opcodes
• newobj creation
• field access opcodes
• array support
• indirect load/store opcodes
• precise GC scanning and GC safepoints
• conversion opcodes
• valuetypes (locals, fields, ctor)
• basic generics working ?
• isinst/castclass
• static fields

M3 - EH and interpreter calls

• basic non exceptional path for try/finally/leave
• exception throw support and resume to correct handler clause
• implement invocation of finally/filter clauses from EH
• null checks and ovf opcodes
• interp virtual call support
• interp interface call support
• direct calls to non-interp code

M4 - mixing with compiled code

• figure out separation between interp/jit/R2R code for testing purposes
• calli and ldftn with interpreter target method
• calli and ldftn with jitted target method
• delegate creation and invocation with interpreter target method
• other delegate scenarios, passing it between interp/jit with either interpreted or jitted target method
• box/unbox

M5 - pinvoke support, full interpreter support for Hello World

• implement pinvoke support
• implement reverse pinvoke support
• bugfixes and feature support for Console.WriteLine("Hello World") in full interpreter mode

M6 - library tests and runtime tests

• bugfixes and feature support for test suites

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

[snikeguo]

Please support ARM32. The interpreter mode has great prospects on MCU.（eg:stm32）
we need generics, multithreading Interpreter, and serial port debugging. The nanoframework does not support these.
https://github.com/bytecodealliance/wasm-micro-runtime
WAMR:
Key features
Full compliant to the W3C Wasm MVP
Small runtime binary size (core vmlib on cortex-m4f with tail-call/bulk memroy/shared memroy support, text size from bloaty)
~58.9K for fast interpreter
~56.3K for classic interpreter
~29.4K for aot runtime
~21.4K for libc-wasi library
~3.7K for libc-builtin library
Near to native speed by AOT and JIT
Self-implemented AOT module loader to enable AOT working on Linux, Windows, MacOS, Android, SGX and MCU systems
Choices of Wasm application libc support: the built-in libc subset for the embedded environment or WASI for the standard libc