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