(accidentally replied privately instead of to the list; I really don't
get why "reply to list" isn't usually a thing; it should be the
default when replying to a message from a list)
On 9/13/18, John <john.r.moser@gmail.com> wrote:
>
>
> Also, there's not necessarily a performance penalty in CLR because it's
> JIT
> to native code. The CLR isn't actually interpreting bytecode as it goes;
> rather it's compiling the program, storing that compiled program in
> memory,
> and entering the compiled native code. The outcome is the same as
> compiling a language to a native machine language.
>
It's certainly closer to native code than a pure interpreter in
performance and may be comparable in some situations, but I was pretty
sure that the overall performance was still somewhat weaker,
especially when you're dealing with real-time code.
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.
>
> 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.
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.