MichalStrehovsky / zerosharp

Demo of the potential of C# for systems programming with the .NET native ahead-of-time compilation technology.
2k stars 103 forks source link

crossgen2 #33

Closed snikeguo closed 2 years ago

snikeguo commented 2 years ago

I was pleasantly surprised to see zerosharp by chance. I am an embedded microcontroller developer. Now there are many ARM MCU chips that contain large SDRAM, and some chips have MMU controller, which contain 64MB of SDRAM, which can run LINUX or VXWORKS (RTOS), The significance of C# running on MCU:

  1. Real-time. Running CLR on RTOS is much better in real-time than under linux. 1.1 In some IoT edge computing scenarios, hard real-time is not required, and a delay of 10-100ms is acceptable. such as smart gateways. 1.2 There are often not many other insignificant tasks in RTOS. Once the program is programmed into the chip, the chip will only run the program. Instead of running a C# program like a desktop operating system, users may be watching movies and playing games (using CPU time). 2.Crossgen2: Compile the MSIL code into PIC (position independent code) code as much as possible and burn it into the MCU. For the Load, Reflection, Dynamic Emit features, for most low-level applications, these features are rarely used. In this way, the program running efficiency is expected to reach 90% of the C language development.
  2. At present, the instruction set of most MCUs is ARMv7 Thumb2.CoreCLR supports this instruction set.
  3. I think CoreClr for MCU only needs to include: Thread and IPC (for example: semaphore queue mutex), Debug, GC, JIT, DLLImport, and others are all cut out. It is expected that the generated BIN file will be within 16MB ( User code+CoreCLR+System.Array, List..., INT8~INT64.. (only a little core library)). This is totally acceptable.

my question:

  1. The work of cutting CORECLR is not difficult, the code of CORECLR is not modular enough, and I don't know JIT, VM, GC, so I don't know how to cut. can you crop? How much time and how much does it take? Do you want to do this? If you want, I can fund you, that's great, and I'll help you with programming that isn't too hard (except writing the CORECLR virtual machine...). I really want to use C# to develop MCU (Corssgen2+JIT way, no interpreter).
  2. I know that there is a .Net Compact Framework. The code is well written and the modular program is very good. Can Microsoft open source this? Because CORECLR coupling is too serious.
  3. Is the machine code generated by Crossgen2 currently PIC (position independent code)? These are Google translated.

    偶然间看到zerosharp我感到非常惊喜. 我是一位嵌入式微控制器开发者,现在有很多ARM MCU芯片内部包含很大的SDRAM,也有一些芯片带MMU控制器,内部包含64MB的SDRAM,可以跑LINUX,也可以跑VXWORKS(RTOS), C#在MCU运行的意义: 1.实时性。在RTOS上跑CLR要比linux下实时性好很多。 1.1 在一些IOT边缘计算的场景下,不需要硬实时,10-100ms的延迟是可以接受的。比如智能网关。 1.2 在RTOS中往往没有太多其他无关紧要的任务,一旦程序烧录到芯片中,那么这个芯片只会跑这个程序。而不是像桌面操作系统那样,正在运行C#程序的同时,用户有可能在看电影,玩游戏(占用CPU时间)。 2.Crossgen2: 尽可能把MSIL代码编译成PIC(位置无关的代码)的代码,烧录到MCU中。对于Load、反射、动态Emit特性,对于大部分底层应用程序来说,这些特性很少用到。这样程序运行效率我预计可以达到C语言开发的90% 3.目前大部分MCU的指令集是ARMv7 Thumb2.CoreCLR支持这个指令集。 4.我觉得CoreClr for MCU只需要包括:Thread and IPC(比如:信号量 队列 互斥锁)、Debug、GC、JIT、DLLImport,其他的都裁减掉,预计生成的BIN文件会在16MB之内(用户代码+CoreCLR+System.Array、List...、INT8~INT64..(仅此一点点核心库))。 这是完全可以接受的。

我的问题: 1.裁剪CORECLR的工作难度大不大,CORECLR的代码不够模块化,并且我也不懂JIT、VM、GC,所以我不知道如何裁剪。你可以裁剪吗?需要多少时间和多少钱?你想不想做这件事?如果你想,我可以资助你,那非常好,我帮你做些不是很难的编程工作(除了写CORECLR虚拟机...)。我非常想使用C#开发MCU(Corssgen2+JIT的方式,不用解释器)。 2.我知道有个.Net Compact Framework,这个代码写的很规范,模块化程序很好,这个微软可以开源吗?因为CORECLR耦合太严重了。 3.目前Crossgen2生成的机器码是PIC(位置无关的代码)吗? 这些是Google翻译的。

MichalStrehovsky commented 2 years ago

@snikeguo ZeroSharp is based on CoreCLR and CoreCLR/NativeAOT. Extending platform support beyond what's supported in the dotnet/runtime repo is not going to happen here - the code for that doesn't even live here. ZeroSharp makes it somewhat easier to do platform bringup and the techniques can be used for that, but for that we would need to first NativeAOT ARM32 builds out (it's not currently officially supported, although it can build that way, but it wasn't extensively tested).

I'm going to close this in favor of https://github.com/dotnet/runtime/issues/47256.