Aug 12, 2015 at 6:35 AM
Edited Aug 12, 2015 at 6:36 AM
1) It reading IL Byte code from DLLs and generating C code with exceptions from C++ to execute it and get the same result
Then why implement both CS -> CPP and MSIL -> CPP? Or do does it internally compile to MSIL before generating CPP?
2) Yes for now it does not support many things and C# is not just C#, it is bug VM which has name .NET Framework
for now it does not support:
- Struct Layout
- __arglist, __makeref, __reftype, __refvalue (partially it supports them)
- DllImport as C# does
- Creating Runtime types etc
The only thing I need here is the struct layout, but I guess that's not too tricky to implement.
3) il2c converts all MSIL codes into C code so it does not depend on any version. (for example it does not matter how many new syntax sugar you are going to use as it will be converted to the same MSIL code which was written for .NET Framework 2.0)
Okay, so its preferable to run il2c on MSIL assemblies instead of the C# source code?
Hmm, I thought asm.js modules ran in a virtual heap (basically a big typed array in JS), meaning that the JS VM doesn´t know about objects allocated on the virtual heap.
If you look at for example
Lua VM in asm.js
you will see that explicitly state that they also compile the garbage collector:
"Are you really porting the entire Lua VM?
Is there anything preventing just compiling libgc with emscripten and redirect memory allocations to that gc engine (which I guess is aleady done when not specifying the /emscripten option?).