Information on implementing L4

[Andrew Warkentin]

On 9/14/18, John <john.r.moser at gmail.com> wrote:
>
> 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.
>

Is that on highly CPU-bound code, or just I/O-bound 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.
>>
>>
> 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.
>

Yes, I guess that would work, but you still have the problem of a
rather complex language runtime being part of the TCB, which you don't
get with an OS based on safer native code.

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

Developers probably aren't going to port to (or completely rewrite for
in the case of non-.NET languages) some obscure alternative OS.
They'll just say "oh, it runs Linux applications, so our Linux port is
good enough", and users will probably pass it over because there will
be few native applications, and Linux applications will be
second-class citizens (unless you actually manage to integrate Linux
applications and allow them to take advantage of your OS's advanced
features, but that sounds like it might be tricky in a non-Unix-like
language-based OS).

An advanced Unix-like OS would have a much easier time integrating
Linux applications (even in its native environment, UX/RT will
implement Linux-specific APIs where it makes sense to do so, and its
Linux binary compatibility layer will be more or less transparent,
allowing Linux programs to integrate reasonably well with the rest of
the OS and take advantage of many of its advanced features).

However, if you're writing your OS for some reason other than
practical real-world usage, then I guess compatibility doesn't matter
as much.