Information on implementing L4

Andrew Warkentin andreww591 at gmail.com
Fri Sep 14 07:00:42 CEST 2018


(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 at 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.

>
> 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.

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).




More information about the l4-hackers mailing list