On 9/14/18, John john.r.moser@gmail.com wrote:
It's a compiler, the same as gcc. In some situations, equivalent C# and C++ code have compared with the C# program being faster in business logic sections.
Is that on highly CPU-bound code, or just I/O-bound code?
I designed a way for the CLR to self-host: it'd be written in C#, and running on itself. This is still theoretical, of course.
I'd think you'd have to statically compile it to native code first.
You'd have to perform the translation ahead of time and then store the CIL, native, and instrumentation data in an image. When you load the image, it's the same as if a CLR had loaded the original CIL and gotten it JIT'd; except the CLR is the JIT result, and the CIL is the CLR. Runs on itself.
Yes, I guess that would work, but you still have the problem of a rather complex language runtime being part of the TCB, which you don't get with an OS based on safer native code.
To me, language-based OSes have always seemed interesting but a bit impractical and limiting. A language-based OS would face more of a challenge when it comes to success in the real world than a conventional OS would (that's one reason why I'm writing an advanced Unix-like OS, since that is what is most likely to be used in the real world).
The plan is to run a Linux userspace by providing the Linux-specific ABI.
Developers probably aren't going to port to (or completely rewrite for in the case of non-.NET languages) some obscure alternative OS. They'll just say "oh, it runs Linux applications, so our Linux port is good enough", and users will probably pass it over because there will be few native applications, and Linux applications will be second-class citizens (unless you actually manage to integrate Linux applications and allow them to take advantage of your OS's advanced features, but that sounds like it might be tricky in a non-Unix-like language-based OS).
An advanced Unix-like OS would have a much easier time integrating Linux applications (even in its native environment, UX/RT will implement Linux-specific APIs where it makes sense to do so, and its Linux binary compatibility layer will be more or less transparent, allowing Linux programs to integrate reasonably well with the rest of the OS and take advantage of many of its advanced features).
However, if you're writing your OS for some reason other than practical real-world usage, then I guess compatibility doesn't matter as much.