Information on implementing L4

[John]

On Fri, Sep 14, 2018 at 1:00 AM Andrew Warkentin <andreww591 at gmail.com>
wrote:

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20180914/24160607/attachment.htm>