How do you think to merge the repository to CoreRT？

[forestbat]

dotnet/corert#7369
I think this repo is fit for corert,do you think to adapt it to .NET Core?
Thank your reply.

[kekyo]

@forestbat Thanks interesting my project!

Short words:

I'll combine from corefx or mono-based runtime corelib in the future. Is's saved in #52 (but the issue and plan truly empty for now ;)
But unfortunately IL2C can't merge in corert.

---

I'm thinking this project goal is long way:

• Support all opcode see list.
• Threading support (GC is done, concurrent GC is partially done, I'll next try the thread pool, TPL and Task implementation)
• Generic types (It's very difficult for what's higher advantage for using IL2C, but I'll surely do)
• Can handle for multiple platform truly (currently works is switcing to the cmake build system for the runtime project, but the sentence includes overall: building system, packaging system, how works C and target OSes (include non OSes) runtime combination/connectability and debuggability for major development system for VS, VSCode and others on the easier usable likely .NET manner.
• And, how to combine base runtime code from corefx.

In last topic, I'm not clearly thinking about: the corefx and coreclr base code separated by System.Private.CoreLib. It's included interoperability code fragment for runtime system CLR, CoreCLR and mono CLR. I think I'll be on this structure for better.

I feel the corert and mono (for AOT) are great projects, but I feel these runtime too big footprint for a lot of embedded systems (it has less than 1MB code, KB order data section).

I'm very interesting Matt Warren's article: "CoreRT - A .NET Runtime for AOT". His tested Test.CoreLib contains only bit fragments, and got result 500KB code section for only wrote System.Console.WriteLine(...).

My target is less than 10 times. It'll be able to fit a lot of embedded systems, and I feel more important makes better performance by CPU core concurrency, cache system, storage and memory footprints.

• I started IL2C in 2 years ago, then I'm continuing and most works are devoted to making it smaller footprint. The .NET runtime and specs for ECMA-335 are the monster of large body :) It'll quickly become huge if I'm offended.

Therefore, perhaps I can't combine both IL2C and corert, but will include corefx runtime libs because improves compatibitily for .NET ecosystems. That means will fit the .NET Core (netstandard?) in the future ;)

(Supplement: I'm NOT intension compared performances for corert, mono and IL2C. They're great, interesting and fun projects for me same as IL2C.)

If you have any questions, please ask me further!

[forestbat]

https://github.com/MichalStrehovsky/zerosharp
See efi-no-runtime and no-runtime，if you want，you even don't need runtime or OS，so I think corert want to go on MCU or embedded system，however this project is big so they don't care this too much——if you want to put your IL2C to there，I think everyone will be happy。
Now MS has gived CppCodeGen to community to finish it，they only provide guidance and reviser，since your repo is similar to CCG，I think your work can make coreRT more mature and strong。
Thank your reply。

[kekyo]

so I think corert want to go on MCU or embedded system

I feel it too and exactly agreed for will make everywhere the .NET world.

The project zerosharp is very interesting, but feel has big issue for the next step. For example, if we expand the hello world code to use System.String.Format(...). It's very useful for real world programming for average level developers.

• System.String.Format() refers IFormattable and IFormatProvider interfaces. They're pull in a lot of method metadata and method bodies. (Therefore pull in more CultureInfo related fragments)
• System.String.Format() refers System.Object.ToString() method. It's virtual and will pull in all ToString implementations includes primitive types: byte, int16, int32, int64, sbyte, uint16, uint32, uint64, float, double, bool ...
• System.String.Format() refers System.Object.ToString() method, it will pull in boxing/unboxing infrastructures implicitly, because all value types passing to System.Object argument.

There may be other problems. These are breaking small footprint very easier...

Implicitly example, GC can make concurrency, reusable heaps and higher efficiency scheduler. But it makes little impacts and exchanges very big footprint.

You may know corert team choices strategy for optimizing cloud usage, I shame many strategies maybe fitting the large resource systems. (But to respect for corert team)

I wrote the .NET specification and ECMA-335 are monster. That means we can write easier simply code fragment on the C#/.NET developer user-land world, but has to carefully runtime implementations for balance.

however this project is big so they don't care this too much

I know, understand and think how avoid IL2C go suspend.

Now MS has gived CppCodeGen to community to finish it

I hope if we have increase day time +10 hours for nature rules or this works turn to profit job to live (I'm looking for a job now ;)

[forestbat]

Have you thought to work in MS？
And .NET Core has different directions for different usages，such as a full coreclr for cloud and server（they don't need to care footprint），corert for place where need small applications，and now MS want a new route which is a "middle runtime",make the runtime not too big(a self-contained .net core app is about 70MB) but still has advanced grammar such as reflection——your work can also be a route of coreRT。
And if you enter MS，maybe you can work with coreRT team such as @jkotas to make it better。
Thank your reply。

[kekyo]

The corert and coreclr are receiving two request decisions. Single assembly and smaller footprint. I know .NET Core users need combined single assembly. I think the team will finish it in near future. But maybe it footprint can't reach IL2C's goal (maybe, I hope failing my thinking :)

Thank you, your opinion just encourage for me truly!!

I already applied .NET runtime jobs, but silently not selected in few month ago 😰 I'm very discouraged, I don't know what insufficient for my skills. But IL2C isn't lost and lives here, I bring up and continue enjoy how reach my IL2C's goal because the runtime works fun and interesting for my developer life ❤️

[forestbat]

Microsoft is strange，I heard that someone get offer after his interview 2 years……so I think you still have choice.
Don't care this too much，hope your work and .NET more and more better。

[kekyo]

I think I wanna go forward and see what useful for something!

[sgf]

The author's belief is deeply admirable.
It may be a good thing not to merge into corert and not to work in MS.
This will bring more possibilities and choices to the .net community and ecology.
The author's work is already great.

[kekyo]

@sgf Thank you sgf!

Last week, I got feel about very shame for WinGet and AppGet difficulity. I understand what into it about MS's goals, but the community developer, projects and worlds are most important for me.

CoreRT and other .NET core projects are extremely cool. I was thinked about how to integrate both IL2C and CoreRT, but I think by my self opinion going down priority integrate process.

[NCLnclNCL]

@sgfcảm ơn bạn sgf!

Tuần trước, tôi cảm thấy rất xấu hổ vì sự khó khăn của WinGet và AppGet. Tôi hiểu mục tiêu của MS là gì, nhưng đối với tôi, nhà phát triển cộng đồng, các dự án và thế giới là quan trọng nhất.

CoreRT và các dự án cốt lõi .NET khác cực kỳ thú vị. Tôi đã suy nghĩ về cách tích hợp cả IL2C và CoreRT, nhưng theo quan điểm riêng của tôi, tôi nghĩ rằng quy trình tích hợp ưu tiên sẽ giảm xuống.

Hey bro, now this and nativeaot which one is better

[kekyo]

@NCLnclNCL Hi, thanks for your interest!

(It's a closed issue, so no one will see it, so I'll write something wet :)

I think Native AOT is a realistic solution if the goal of the average developer is to use C# to write code for some purpose. For example, as most developers would think, writing ASP.NET Core-based code for the purpose of simplifying deployment or reducing load time. And that would be a common motivation today.

On the other hand, that is not the goal of IL2C, which is to target a wide range of platforms by minimizing the footprint (which would also accomplish the above) and making the C compiler the driver for executable code generation.

However, since starting with IL2C, every element around .NET has become more complex. I saw a very bright future up to C# language version 5, but since then I don't see much appeal. And I feel that the development of the CLR has basically been strongly driven by updates to the C# language (although I am sure there are other factors as well).

I am frustrated that implementing IL2C is almost like supporting the C# language, which was not the original idea of the CLR, which was supposed to be multi-language.

One of my personal projects is to create a new functional language, and of course at first I was thinking of an interpreter and compiler that would work with CLR, but I feel that CIL and CLR as intermediate code are too much influenced by C# when considering multi-platform support, I also feel that if I design a language, it doesn't have to be CIL for simplicity's sake. Hypothetically, I also feel that if IL2C had targeted Java bytecode, which could also be called JB2C, it would have been finished long ago.

That is one of the reasons why IL2C is stalled right now.

NOTE: Wikipedia Common Language Infrastructure: "describes executable code and a runtime environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures."