A benchmark, mostly GC

[Paulo Pinto]

No need to reference Wikipedia articles, I am well aware of the implementation specifics.

Still Singularity was just an example. I can pinpoint several other operating systems done in GC enabled systems languages, where besides the given language, only assembly was used, Native Oberon is such an OS for example.

Many times C and C++ get used in such operating systems because of available tools that speed up development, instead of spending time rewriting them.

I think we will eventually get there as the trend nowadays is that everything is slowly done in GC enabled languages anyway. Even Microsoft and Apple are extending their systems languages (Objective-C and C+) to offer some form of automatic memory management.

--
Paulo


Robert Jacques Wrote:

> On Tue, 13 Dec 2011 02:22:00 -0500, Paulo Pinto <pjmlp at progtools.org> wrote:
> 
> > Robert Jacques Wrote:
> >> >>>> Second, being a systems language means that D can not implement a lot of
> >> >>> GC algorithms including copying, generational and the good concurrent
> >> >>> collectors.
> >
> > I disagree, as there are other system languages with better GC algorithms as D,  because they offer more safe features than D, lack of inline assembler being one of them.
> >
> > And regardless of what you may think about these languages suitability for doing systems programming, there are research operating systems written in them with lots of papers to read from. Something that I am yet to see from D.
> >
> > Yet when reading how Singularity was implemented, there are lots of parallels between what Sing# offers and what D does. So I really see that there is quite some possibilities to improve D's GC still.
> >
> 
>  From the Singularity Wikipedia article:
> The lowest-level x86 interrupt dispatch code is written in assembly language and C. Once this code has done its job, it invokes the kernel, whose runtime and garbage collector are written in Sing# (an extended version of Spec#, itself an extension of C#) and runs in unprotected mode. The hardware abstraction layer is written in C++ and runs in protected mode. There is also some C code to handle debugging. The computer's BIOS is invoked during the 16-bit real mode bootstrap stage; once in 32-bit mode, Singularity never invokes the BIOS again, but invokes device drivers written in Sing#. During installation, Common Intermediate Language (CIL) opcodes are compiled into x86 opcodes using the Bartok compiler.
> 
>  From BitC website
> A less obvious issue is the absence of first-class union value types in the managed subset of the Common Language Runtime (CLR) or the corresponding parts of the Java Virtual Machine (JVM). These are absolutely necessary for low-level systems programming, so one must either abandon Java/C#/Spec# to implement these low-level objects (thereby abandoning the foundation for checking), or one must find a more appropriate language.
> 
> In addition to the problems of expressiveness, neither Java nor C# was designed with formal property checking in mind. Spec# [3], a language developed by Microsoft Research to retrofit formal property checking to C#, has been forced to introduce some fairly severe language warts to support precondition and postcondition checking, but the language does not attempt to address the underlying performance issues of C#.
> 
> So, no, Singularity isn't written purely in Sing#; all its low-level systems access is written in ASM/C/C++, like pretty much every single other operating system. (It's still an impressive microkernel)
> 
> Now BitC and Coyotos are another interesting language/OS pair, though they currently use a C/C++ conservative garbage collector.
> 
> At the end of the day, I'm really excited about the growth in the systems programming arena and I'd love to see the combination of the ideals in C4, L4, Singularity and Coyotos into some new OS and/or language. But that doesn't really change the limitations of running on top of Windows or iOS.