OSDev.org

Casm wrote:

Where did you get the idea that garbage collectors must invoke an OS?

The compiler for any high or medium level programming language is going to presuppose the existence of an operating system. It couldn't very well do anything else if there is supposed to be a garbage collector freeing memory. The only way around that would be to wreite your own compiler, and even then you would need to be able to disable garbage collection until you had got your OS's memory manager in place.

Correct---most higher-level language implementations were designed for applications, not systems programming. However, there are exceptions (e.g., Cosmos for C#).

Casm wrote:

Interpreter?! It's very simple: A language can mandate a specific behavior when you go out of bounds. As an example, it might throw an exception.

And what would any exception handler put in place by a compiler do?

Expect the code to catch it.

As for Smalltalk, it was designed specifically with developing this type of environment in mind.

I believe that you are wrong about the reasons that Smalltalk was designed, but that's another question. Have you used it for this purpose?

More generally, it would be interesting if you could tell us which language(s) you use for OS development.

However, there are exceptions (e.g., Cosmos for C#).

How are they exceptions? C# needs not just an operating system, but the whole .NET framework (or its equivalent - again written in C).

Expect the code to catch it.

It is hardly likely to rely upon that. It would put a default handler in place.

You can't expect to have all sorts of nice services when you are supposed to be writing the thing to provide those services.

Casm wrote:

However, there are exceptions (e.g., Cosmos for C#).

How are they exceptions? C# needs not just an operating system, but the whole .NET framework (or its equivalent - again written in C).

I'm beginning to think that you're a troll. How about you do a little research of your own rather that contradict everything? Infero is one of the older (but not oldest) managed operating systems; it started at Bell Labs and is now maintained by a different group. JavaOS was Sun's Java-based OS. Microsoft's Singularity was an open source research project written in C#. Cosmos and MOSA are two frameworks for building operating systems in C#. JamesM's Horizon was another general-purpose framework for creating managed operating systems.

The exact same rule that applies to C also applies to higher-level languages: You either need a VM (an interpreter or compiler that comprises the lowest layer of the OS) or an AOT compiler (that generates machine code for you the same way a regular C compiler would). The only difference is that the tools for C are easier to find so you are less likely to need to implement them yourself.

Casm wrote:

Expect the code to catch it.

It is hardly likely to rely upon that. It would put a default handler in place.

You can't expect to have all sorts of nice services when you are supposed to be writing the thing to provide those services.

That's like saying saying C kernels are unlikely to handle errors. What do you mean it's hardly likely? Are you suggesting that the code that goes into an OS is a matter of chance? No, you don't just write code willy-nilly. You write handlers to catch your exceptions.

[I'm beginning to think that you're a troll. How about you do a little research of your own rather that contradict everything?

The point is that so called "managed" operating systems can only run on top of something which is effectively an unmanaged operating system, and, guess what, that underlying operating system will have toi be written in something like C, which doesn't need any underpinning.

As I asked once before on here, how is an operating system, which runs an operating system, which runs applications, an improvement upon an operating system which runs applications? It is just another layer of unnecessary complexity to slow everything down, and it doesn't even solve the problem of bugs in the bottom layer of software.

Hi,

Casm wrote:The point is that so called "managed" operating systems can only run on top of something which is effectively an unmanaged operating system, and, guess what, that underlying operating system will have toi be written in something like C which doesn't need any underpinning.

As I asked once before on here, how is an operating system, which runs an operating system, which runs applications, an improvement upon an operating system which runs applications? It is just another layer of unnecessary complexity to slow everything down, and it doesn't even solve the problem of bugs in the bottom layer of software.

Perhaps you missed the part,

Love4Boobies wrote:AOT compiler (that generates machine code for you the same way a regular C compiler would.

Regards,
Shikhin

Casm wrote:

[I'm beginning to think that you're a troll. How about you do a little research of your own rather that contradict everything?

The point is that so called "managed" operating systems can only run on top of something which is effectively an unmanaged operating system, and, guess what, that underlying operating system will have toi be written in something like C, which doesn't need any underpinning.

As Shinkin just pointed out, this is not necessary: There is no reason why a language like C# could not be compiled to native code the same way C is. Both languages define abstract machines. And guess what? If you have a C# compiler that compiles to native code, it can even become the "something like C" you are describing. There is nothing special about C at all here; all that is required is that the lowest layer of the OS be native machine code.

Casm wrote:As I asked once before on here, how is an operating system, which runs an operating system, which runs applications, an improvement upon an operating system which runs applications? It is just another layer of unnecessary complexity to slow everything down, and it doesn't even solve the problem of bugs in the bottom layer of software.

It is not an OS running an OS. There just happens to exist a translation phase at the lowest layer. Whether or not you decide to use a VM (again, this is not a requirement), here are some of the advantages:

• Not requiring memory protection domains (like virtual memory or segmentation). In fact, the CPU doesn't even require a MMU.
• Blazing fast IPC in the same NUMA domain (to pass a block, all you need to do is pass a reference).
• Not requiring the hardware to make repeated checks on memory accesses for things that can be verified statically.

For VM's, there are some additional pro's:

• Implicit binary portability for applications, just like in the case of Java.
• The ability to perform JIT optimizations based on runtime profiling or microarchitecture-specific details.
• The ability to easily migrate processes from one place to another (even if we are talking about x86->ARM).
• Managed bytecode is designed such that it can be verified for correct behavior.

Love4Boobies wrote:The only difference is that the tools for C are easier to find so you are less likely to need to implement them yourself.

This THE reason that so many use C or C++ because the tools are available for various target architectures. Java and C# exists but works on a virtual machine. Few people have the knowledge to create an entire new language, which takes man years to create.

Ideally what I think is missing here.

1. A "managed language" tool chain that can compile directly to native code.
2. A CPU that is designed for the language, which means HW assisted object protection. I keep wondering of those virtual machines for Java and C# are just a workaround that CPUs aren't really designed for that type of protection.

Suddenly this virtual machine layer was invented which is an extra overhead for people who want to do bare metal coding and OS development but at the same time want to adopt the features of more modern languages.

The MMU choice decades ago is like when the car industry decided to use gas (an later on even lead in it) instead of electricity. It's been like that for almost 100 years but that doesn't mean that the electric car is unfeasible today and we are starting to see really nice electric cars.

OSwhatever wrote:Few people have the knowledge to create an entire new language, which takes man years to create.

I would dare postulate that designing a good programming language is more challenging than an OS.

OSwhatever wrote:Ideally what I think is missing here.

1. A "managed language" tool chain that can compile directly to native code.
2. A CPU that is designed for the language, which means HW assisted object protection. I keep wondering of those virtual machines for Java and C# are just a workaround that CPUs aren't really designed for that type of protection.

Right. Both exist but neither are commonplace.

OSwhatever wrote:Suddenly this virtual machine layer was invented which is an extra overhead for people who want to do bare metal coding and OS development but at the same time want to adopt the features of more modern languages.

I wouldn't be so quick to dismiss virtual machines. My previous post in this thread listed some of their advantages but even if you find JIT unsuitable for the system you target, that doesn't mean bytecode is. You can take advantage of most of that stuff by performing AOT compilation at installation time.

Even with all it's traps and pitfalls, C is still a suitable language for many things. I don't think Love4Boobies is suggesting that it is always inappropriate to use it.

He probably even gets that reference.

..and if he doesn't, well, screw that bastard. C > *

Brynet-Inc wrote:Even with all it's traps and pitfalls, C is still a suitable language for many things. I don't think Love4Boobies is suggesting that it is always inappropriate to use it.

I think it is mainly useful for embedded programming on resource-scarce platforms, as no better alternatives exist there. And for working on existing C code, obviously.

Brynet-Inc wrote:He probably even gets that reference.

I C what you did there.

Love4Boobies wrote:I think it is mainly useful for embedded programming on resource-scarce platforms, as no better alternatives exist there. And for working on existing C code, obviously.

Embedded systems are often non-x86 and you might use architectures you never heard of before. What they usually do is porting GCC for that particular architecture so you are pretty much forced to use C/C++. Now when LLVM is getting more popular that might chance so that they port LLVM instead and that way you will have a greater palette of languages in the future. Once you added LLVM support for you architecture you get all the languages in LLVM for "free".

I'm not certain what that incoherent paragraph about compiler porting has to do with C.

Casm wrote:

[I'm beginning to think that you're a troll. How about you do a little research of your own rather that contradict everything?

The point is that so called "managed" operating systems can only run on top of something which is effectively an unmanaged operating system, and, guess what, that underlying operating system will have toi be written in something like C, which doesn't need any underpinning.

As I asked once before on here, how is an operating system, which runs an operating system, which runs applications, an improvement upon an operating system which runs applications? It is just another layer of unnecessary complexity to slow everything down, and it doesn't even solve the problem of bugs in the bottom layer of software.

I beg to differ. At Mosa we are writing a managed operating system in C#, with a complete toolchain (written in C#). To make it short: it's 100% C#. No C/C++ involved.

my 0.02$,

I use C because it's simple, i know it well and it gets the job done. I've also used various other languages such as C#, C++ etc at work but never felt that the functionality they provide over C are worth the size, performance and portability issues they bring with them for use inside an OS. Although by including portability I do not mean that C code is portable (or if OS code needs to be portable at all, usually it's well defined for a few architectures/VM only), just more easier to port than equivalent C#, C++ stuff. Having worked with embedded stuff gave me another reason to use C, C compilers support far more architectures/CPUs than C# (which is mostly run on a MS VM) or C++.

(I also compare size of code as I've have had relatively less cache miss on equivalent C code compared to C++ code, although one could argue my C++ code sucks as I am no expert with it).

Love4Boobies wrote: I think it is mainly useful for embedded programming on resource-scarce platforms, as no better alternatives exist there.

Yes, it certainly is. But i don't get your argument of strictly confining it to resource-scarce platforms. Just because you have a few hundred thousand extra cycles you'll use something that isn't efficient and hence waste energy + time ?

Although the argument hasn't been raised here, The advantage of standard libraries in such managed languages and C++ doesn't matter at all, If done perfectly, You can have a well written library in C too. (ie. dlmalloc)


Feel free to enlighten me wherever I might have gone wrong.