|
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 saw this one (Thor)[^] the other day. C++ , with "some" assembly.
As for why C, I leave that to others.
TTFN - Kent
|
|
|
|
|
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.
|
|
|
|
|
I think you are right. During that time C++ was still just a pre-processor too.
|
|
|
|
|
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...catch block 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 sh*t 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.
|
|
|
|
|
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.
|
|
|
|
|
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
modified 2-Sep-16 19:25pm.
|
|
|
|
|
Very interesting! I guess that's why Microsoft developed COM, because they needed a way for binary compatibility between modules produced by different compilers. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Exactly 
|
|
|
|
|
|
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: some architectures define ABI on C++ level
Yes, and there is a proposal to define portable ABI for C++: N4028[^]
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
The rules for this forum state:
"For lazing about and discussing anything in a software developer's life that takes your fancy except programming questions."This topic definitely affects a software developer's life.
In 2014, the U.S. approved more than 370,000 H-1B applications. The flood of cheap foreign workers is killing compensation for software developers. In the DC region, I am seeing rates from the early 90's. In the 90's, rates were easily $40-80/hr. I think it is worse in the Seattle area. If we have a tech worker shortage, why are we at $40-80/hr 25 years later ? I want to know which candidate will shut this down ?
...thanks primarily to the ability to pay their imported workers on H-1B visas between 30 percent and 50 percent less than the prevailing American wage rate for that job.
...it's no surprise to discover that politics and business are familiar bedfellows, ...the list of the top 10 companies who apply for H-1B visas. In 2014, while six were Indian ... the rest were all American. Deloitte, IBM, Accenture, and Microsoft made up the remainder of the top 10, while Ernst & Young and Google sneaked into 11th and 12th places
Southern California Edison IT workers 'beyond furious' over H-1B replacements
Pink Slips at Disney. But First, Training Foreign Replacements
(very informative video)Protecting United States Workers[^]
...
For you South Park fans: "They took our jobs! They took der jerbs!! Durka durr!!"
modified 5-Sep-16 14:44pm.
|
|
|
|
|
This isn't gonna end well... 
In this present crisis, government is not the solution to our problem; government is the problem. ~ Ronald Reagan
|
|
|
|
|
It's obviously a sore point with him...but you're right, it can't end well - this has been moved to SB once already. 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
There is no qualification of what kind of candidate in the original question. Senate and House Representatives can introduce legislation to shut the program down, and even labor representatives might have an influence enough to do so. I see a lot of complaining here about this post, but I see WAY more about programming, and not a peep is emitted from any of you. Stop being such hypocrites.
|
|
|
|
|
It's a Soapbox issue - it's political, which is probably why it got moved: it obeys one rule but breaks others.
I'd suggest that you don't push the rules too much to drive your agenda here, you will annoy people and they will almost certainly vote to close your account as a result.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
It is not a programming question and it is not "political" -- it does not advocate any candidate or party. This affects the wages of all US IT workers - which would seem to impact a "software developer's life". The Soapbox is where this goes to die. hmmm... maybe Code Project employs a bunch of H-1B's....
The forum heading says:
For lazing about and discussing anything in a software developer's life that takes your fancy except programming questions.
|
|
|
|
|
And the rules[^] say NO POLITICS.
Asking "which (US Presidential) candidate will shut this down" is politics. Saying "this isn't political" doesn't change that. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Quote: hmmm... maybe Code Project employs a bunch of H-1B's
Seeing as how H1-B is a US job classification, and CP is located in Toronto, that's unlikely.
I know people are sensitive, and view discussions around H1-B (and other visas) as political, so perhaps spend less time rules-lawyering and listen to what the community suggests. Is it that hard to move over one discussion area, where you can spend less time discussing the appropriateness of the topic, and more on the topic itself?
Anyway, when I worked in the States, I was on an H1-B (for four of the five years), and knew of more than a few folk also on it. None of them were hired because they were cheap. I'd think that if a company wanted cheap, they'd outsource, and that definitely is Soapbox material.
TTFN - Kent
|
|
|
|
|
Kent Sharkey wrote: view discussions around H1-B (and other visas) as political
It's not even that. The original title of the thread ask about the position of the US presidential candidates. Even the modified message says "I want to know which candidate will shut this down".
It's not that visas are a political topic. It's that politics is a political topic!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
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 -