Re: Information on implementing L4
Andrew Warkentin <[email protected]>
| Newsgroups | gmane.comp.micro-kernel.l4.devel |
|---|---|
| Message-ID | <CAD-qYGrg0UOnhCC7kG9peAJWS+JJfPp0AYodwn-UpbxMMKAQyQ@mail.gmail.com> |
(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 <[email protected]> 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).