OS Kernels
-
Richard Andrew x64 wrote:
Does anyone know of any modern OS kernels that are written in C++?
There is eCos[^], for instance. And then, of course, BeOS[^] if you consider it "modern".
Richard Andrew x64 wrote:
Is there a reason they are usually written in C?
Some C++ features like RTTI and exceptions are pretty hard to implement in kernel mode but most importantly pretty much all popular operating system kernels were developed before C++ was stable and widely used.
-
Does anyone know of any modern OS kernels that are written in C++? Is there a reason they are usually written in C? :)
The difficult we do right away... ...the impossible takes slightly longer.
Moving onward from where Kent left you. Basically, I do a lot of Object-oriented programming and prefer it over other procedural languages. But when things have to go deep, like really deep, you should avoid distractions. ;-) C and C++ have a basic difference, C++ has a flavor of object-oriented programming, a bit of functional programming (lambdas) and other community-suggested features. C language is free from such stuff and is very much close to Assembly language. Assembly language, as you know, is used to program the devices at the lowest level and, as per this thread[^]:
Quote:
Per Brinch-Hansen once called C an "assembly language with better syntax".
So, that is one of the factors why C is preferred over C++. If C++ was that much great language and better than C (which it is not in the terms of performance), even Bjarne would have started a project to port some kernel to C++. Which he did not, or that we know of. He did use C++ in many applications, started supporting the community for many projects but kernels or low-level programming was not a part of that — and all of that made sense at a higher-level of programming, in kernel development that was just garbage. That said, now I really want to see a kernel re-written in C++ because of the amazing facts of C++, there is a
try...catchblock on C++, so maybe instead of halting the systems we can redirect it somewhere — redirect to termination? The processor power today doesn't care about these things, processors are powerful and intelligent enough to take care of most of issues. So, these won't be a problem in today's world. But still C++ is much more complex than C, just because of the easy features that it contains. Finally, if you are asking why Linux kernel isn't using C++, then you would be really very much disappointed because that is never going to happen as long as Linus is managing what piece of code goes to Linux kernel. Linus Torvalds on C++[^]The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
-
Moving onward from where Kent left you. Basically, I do a lot of Object-oriented programming and prefer it over other procedural languages. But when things have to go deep, like really deep, you should avoid distractions. ;-) C and C++ have a basic difference, C++ has a flavor of object-oriented programming, a bit of functional programming (lambdas) and other community-suggested features. C language is free from such stuff and is very much close to Assembly language. Assembly language, as you know, is used to program the devices at the lowest level and, as per this thread[^]:
Quote:
Per Brinch-Hansen once called C an "assembly language with better syntax".
So, that is one of the factors why C is preferred over C++. If C++ was that much great language and better than C (which it is not in the terms of performance), even Bjarne would have started a project to port some kernel to C++. Which he did not, or that we know of. He did use C++ in many applications, started supporting the community for many projects but kernels or low-level programming was not a part of that — and all of that made sense at a higher-level of programming, in kernel development that was just garbage. That said, now I really want to see a kernel re-written in C++ because of the amazing facts of C++, there is a
try...catchblock on C++, so maybe instead of halting the systems we can redirect it somewhere — redirect to termination? The processor power today doesn't care about these things, processors are powerful and intelligent enough to take care of most of issues. So, these won't be a problem in today's world. But still C++ is much more complex than C, just because of the easy features that it contains. Finally, if you are asking why Linux kernel isn't using C++, then you would be really very much disappointed because that is never going to happen as long as Linus is managing what piece of code goes to Linux kernel. Linus Torvalds on C++[^]The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
Thanks for the terrific post! :)
The difficult we do right away... ...the impossible takes slightly longer.
-
Does anyone know of any modern OS kernels that are written in C++? Is there a reason they are usually written in C? :)
The difficult we do right away... ...the impossible takes slightly longer.
C has de facto standard and stable ABI, so you can make drivers and modules work with kernel even if you used different compiler than it used to compile kernel. C++ ABI has no de facto standard and it is widely different between different compilers so interoperability is impossible. It means you either relay on a single version of a compiler1 to do everything in kernel mode or you have to make C API to interact between different modules in which case you lose a lot of benefits of C++.
1 - sometimes you can break compatibility between binaries produced by the same compiler if you use different set of switches to compile the code
GeoGame for Windows Phone | The Lounge Explained In 5 Minutes
-
C has de facto standard and stable ABI, so you can make drivers and modules work with kernel even if you used different compiler than it used to compile kernel. C++ ABI has no de facto standard and it is widely different between different compilers so interoperability is impossible. It means you either relay on a single version of a compiler1 to do everything in kernel mode or you have to make C API to interact between different modules in which case you lose a lot of benefits of C++.
1 - sometimes you can break compatibility between binaries produced by the same compiler if you use different set of switches to compile the code
GeoGame for Windows Phone | The Lounge Explained In 5 Minutes
Very interesting! I guess that's why Microsoft developed COM, because they needed a way for binary compatibility between modules produced by different compilers. :-D
The difficult we do right away... ...the impossible takes slightly longer.
-
Moving onward from where Kent left you. Basically, I do a lot of Object-oriented programming and prefer it over other procedural languages. But when things have to go deep, like really deep, you should avoid distractions. ;-) C and C++ have a basic difference, C++ has a flavor of object-oriented programming, a bit of functional programming (lambdas) and other community-suggested features. C language is free from such stuff and is very much close to Assembly language. Assembly language, as you know, is used to program the devices at the lowest level and, as per this thread[^]:
Quote:
Per Brinch-Hansen once called C an "assembly language with better syntax".
So, that is one of the factors why C is preferred over C++. If C++ was that much great language and better than C (which it is not in the terms of performance), even Bjarne would have started a project to port some kernel to C++. Which he did not, or that we know of. He did use C++ in many applications, started supporting the community for many projects but kernels or low-level programming was not a part of that — and all of that made sense at a higher-level of programming, in kernel development that was just garbage. That said, now I really want to see a kernel re-written in C++ because of the amazing facts of C++, there is a
try...catchblock on C++, so maybe instead of halting the systems we can redirect it somewhere — redirect to termination? The processor power today doesn't care about these things, processors are powerful and intelligent enough to take care of most of issues. So, these won't be a problem in today's world. But still C++ is much more complex than C, just because of the easy features that it contains. Finally, if you are asking why Linux kernel isn't using C++, then you would be really very much disappointed because that is never going to happen as long as Linus is managing what piece of code goes to Linux kernel. Linus Torvalds on C++[^]The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
Afzaal Ahmad Zeeshan wrote:
kernel development that was just garbage.
While C++ is not used to write kernel of any major OS, it is used for other things running in kernel mode such as Windows shell and drivers.
GeoGame for Windows Phone | The Lounge Explained In 5 Minutes
-
Very interesting! I guess that's why Microsoft developed COM, because they needed a way for binary compatibility between modules produced by different compilers. :-D
The difficult we do right away... ...the impossible takes slightly longer.
-
Does anyone know of any modern OS kernels that are written in C++? Is there a reason they are usually written in C? :)
The difficult we do right away... ...the impossible takes slightly longer.
I prefer C because the code is really clean an you know what it will compile into. But tt could be done in C++. The question is - do you also want to expose system services in object oriented manner or simply write a kernel using it? Your everyday micro-kernel does following: 1) Startup code is usually written in assembler. It manages interrupts, initializes stack, vectors and BSS/DATA segments for C/C++ code, and typically ends by calling your _main function), minor changes are required here (I guess there are some C++ code startup tasks here). 2) Memory management. Operator new would have to be overloaded. 3) Task (thread) management. Maintaining thread queues (running, sleeping, waiting, suspended, etc.), basic context switching logic, algorithm to select next thread to run, and algorithms to support sync. events (this is commonly just moving threads from one queue to another). 4) IPC mechanisms. You could expose the inner kernel logic as some sort of interfaces, similar to COM vtables. And proxy each function so that it "simulates" OS mode call before executing (depending on hardware). If you'd like to give it a go I am maintaining a tiny OS kernel for ZX Spectrum here [^]. I'd have a desire to port it to Raspberry PI for a while... Regards, Tomaz
-
C has de facto standard and stable ABI, so you can make drivers and modules work with kernel even if you used different compiler than it used to compile kernel. C++ ABI has no de facto standard and it is widely different between different compilers so interoperability is impossible. It means you either relay on a single version of a compiler1 to do everything in kernel mode or you have to make C API to interact between different modules in which case you lose a lot of benefits of C++.
1 - sometimes you can break compatibility between binaries produced by the same compiler if you use different set of switches to compile the code
GeoGame for Windows Phone | The Lounge Explained In 5 Minutes
Good point and practically correct. But not entirely. :cool: For example, I had situations where two C compilers put function arguments to the stack in the opposite order: first to last and last to first. In addition - some architectures define ABI on C++ level. For example ARM.[^]
-
Good point and practically correct. But not entirely. :cool: For example, I had situations where two C compilers put function arguments to the stack in the opposite order: first to last and last to first. In addition - some architectures define ABI on C++ level. For example ARM.[^]
That's why I said de facto standard, since ANSI C standard does not deal with implementation details. In your case we're talking about calling convection and for each platform there are several well known and understood convections (almost as if they are standardized). Any decent compiler support different calling conventions and allows you to specify it for your functions, so interoperability is not a problem. This is not the case with C++ where we have things like vtables, pointer to member, name mangling...
Tomaž Štih wrote:
Yes, and there is a proposal to define portable ABI for C++: N4028[^]
GeoGame for Windows Phone | The Lounge Explained In 5 Minutes
-
Does anyone know of any modern OS kernels that are written in C++? Is there a reason they are usually written in C? :)
The difficult we do right away... ...the impossible takes slightly longer.
Coming from the embedded world where C is the 800 lb gorilla, the reason for this is memory management, or lack of it. Building an OS has much in common with embedded, since it's a "bare iron" implementation. That means there no service to allocate and free memory or manage stacks and heaps. That's what the OS does. More critical is the tradeoff between deterministic and probablistic behavior. Real time response requries deterministic response times. When an interrupt occurs it absolutely, positively has to be handled right now (want your brakes and steering to wait for the heap to be consolidated?). Inject garbage collection and heap allocation overhead, respone time become probabilistic...it may be ready on time, but no guarantee. We think of an OS kernel in terms of threads, scheduling, maybe a filesystem, but that's what's exposed to the user. It's the internals, finding the minimal path to schedule the next task (or tasks plural for multi-core), efficiently passing inter-process messages, and optimizing I/O operations for parallel, asynchronous operation. Often the code is closely tied to the hardware, and that's where C outperforms anyting but assembler.
-
Coming from the embedded world where C is the 800 lb gorilla, the reason for this is memory management, or lack of it. Building an OS has much in common with embedded, since it's a "bare iron" implementation. That means there no service to allocate and free memory or manage stacks and heaps. That's what the OS does. More critical is the tradeoff between deterministic and probablistic behavior. Real time response requries deterministic response times. When an interrupt occurs it absolutely, positively has to be handled right now (want your brakes and steering to wait for the heap to be consolidated?). Inject garbage collection and heap allocation overhead, respone time become probabilistic...it may be ready on time, but no guarantee. We think of an OS kernel in terms of threads, scheduling, maybe a filesystem, but that's what's exposed to the user. It's the internals, finding the minimal path to schedule the next task (or tasks plural for multi-core), efficiently passing inter-process messages, and optimizing I/O operations for parallel, asynchronous operation. Often the code is closely tied to the hardware, and that's where C outperforms anyting but assembler.
Thanks for your reply. It sounds like you know a lot about OS's, so let me ask this question: Is the internal runtime environment of the kernel anything like what we, as application programmers, know as a "process?" Or is it some kind of amorphous, limitless environment?
The difficult we do right away... ...the impossible takes slightly longer.
-
Thanks for your reply. It sounds like you know a lot about OS's, so let me ask this question: Is the internal runtime environment of the kernel anything like what we, as application programmers, know as a "process?" Or is it some kind of amorphous, limitless environment?
The difficult we do right away... ...the impossible takes slightly longer.
There's a micro-kernel for essential services, things like task scheduling and memory management. Essentially that's a standalone program since it's the lowest layer. Built on top of that are tasks that can be scheduled to implement the rest of the services. Task is a way to encapsulate a service. That has some security benefits by localizing references, it only runs as needed, can be swapped in a virtual system if not needed, and run multiple execution paths through the same code, important if there are several execution units (multi-core CPUs). So the upper layers, close to the end user, are usually process based, though there are some exceptions when you get to embedded RTOS design. Response time is everything in an RTOS, which is why they exist alongside a traditional OS like LInux or Windows. In an RTOS there may not be enough resources to work through multiple layers. Remember, we're talking about a microwave oven or a sprinkler controller, not an i7 and 16GB RAM. A low level RTOS does look more like a library of method calls to a small set of services.
