5 ms·
This is a fine "long answer" to the question how do I write C++ on bare metal?. The short answer is don't, medium is if you don't know why every major operating
by microcolonel 9y ago
This is a fine "long answer" to the question how do I write C++ on bare metal?. The short answer is don't, medium is if you don't know why every major operating system at every size is written in C, then you have a lot of learning to do.
- dragontamer 9y agoWindows is well known to have portions of the kernel written in C++, and MacOSX has huge portions written in ObjectiveC. The greater part of Android is Java-based. Only Linux is really purely C-based, since Linus really hates C++ with a passion. But there's a reason why even the GCC project has moved over to C++. http://lordjeb.com/2013/09/19/modern-c-in-the-windows-kernel/ http://lordjeb.com/2013/09/19/modern-c-in-the-windows-kernel...
- microcolonel 9y ago"Only linux" And every BSD, Magenta (a brand new kernel), ThreadX, FreeRTOS, QNX, Integrity, HP-UX, SeL4, Illumos, TI-RTOS, RTEMS... XNU does not appear to have any Objective-C in the kernel, and it has no C++ in the scheduler, syscall handler, or any other critical section. I doubt Windows has C++ in any such place either. Inside the XNU tarball (the actual kernel inside OS X) there are 1,078 C source code files containing 652,124 source (not comment, not whitespace) lines. There are exactly 10 Objective-C files containing a total of 1787 code lines, and it's not certain they are even built as part of the kernel binary. To be fair, there is some amount of C++ in XNU these days. XNU contains 97 C++ files totalling 68,673 code lines, it seems mostly in iokit[50kSLOC] and libkern[17kSLOC] (infrastructure to support the iokit C++ code, maybe).
- monocasa 9y agoDarwin's whole driver model is in C++. Look up "IOKit"
- microcolonel 9y agoI'm aware that I/O Kit is written in C++, I added that to my comment (maybe you saw the old version). Drivers are not really kernel per se, there are plenty of systems which have no drivers in the kernel (usually except RTC, which is in kernel in XNU anyway). Also, it's not really C++, it's a pretty serious subset (lacking templates, multiple inheritance, exceptions, reflection, funky new casts [reinterpret_cast, static_cast, dynamic_cast, const_cast], and even namespaces(!)).
- monocasa 9y ago> I'm aware that I/O Kit is written in C++, I added that to my comment (maybe you saw the old version). The danger of quick edits. : ) > Drivers are not really kernel per se, there are plenty of systems which have no drivers in the kernel (usually except RTC, which is in kernel in XNU anyway). I mean, except more than half of the OSs you listed. And of those you listed that are microkernels, only QNX has gotten any serious traction. > Also, it's not really C++, it's a pretty serious subset (lacking templates, multiple inheritance, exceptions, reflection, funky new casts [reinterpret_cast, static_cast, dynamic_cast, const_cast], and even namespaces(!)). Yeah, compilers have come a really long way in the nearly 20 years since that was designed, but they want to keep ABI compatibility.
- dragontamer 9y ago> Also, it's not really C++, it's a pretty serious subset (lacking templates, multiple inheritance, exceptions, reflection, funky new casts [reinterpret_cast, static_cast, dynamic_cast, const_cast], and even namespaces(!)). Oh come on. Its not like you see C99 dynamic arrays used very much in Kernel mode. That's the joy of programming languages. Good programmers use the good parts and ignore the bad parts. C++ has a lot of bad parts (with regards to kernel programming. Such as how most of the STL automatically reallocates memory on its own whims). So, you ignore the parts that don't work for your task, and the work with the parts that are useful. Very few people have good uses of multiple inheritance anyway. ---------- > Also, it's not really C++, it's a pretty serious subset (lacking templates, multiple inheritance, exceptions, reflection, funky new casts [reinterpret_cast, static_cast, dynamic_cast, const_cast], and even namespaces(!)). BTW: The -kernel flag in Visual Studio only disables: * Dynamic Casts (Reflection/RTTI is disabled), Exceptions, and the DEFAULT New / Delete. Templates, Static_cast / Const_cast and all that good stuff are still available. This is a similar "subset" of C++ that has been chosen for GCC development: https://lwn.net/Articles/542457/ https://lwn.net/Articles/542457/
- dragontamer 9y ago> I doubt Windows has C++ in any such place either. https://msdn.microsoft.com/en-us/library/jj620896.aspx https://msdn.microsoft.com/en-us/library/jj620896.aspx Hint: This exists for a reason. Another note: Window's Kernel exposes an API for custom user-mode task-scheduling (Called UMS). Its API is accessible from C++: https://msdn.microsoft.com/en-us/library/windows/desktop/dd627164(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd6... . When you get to the ConcRT stuff (which is built on top of UMS), its C++ code for sure: https://msdn.microsoft.com/en-us/library/ee207192.aspx https://msdn.microsoft.com/en-us/library/ee207192.aspx Nearly direct-access to the GPU is also done through a little C++ API called DirectX. https://msdn.microsoft.com/en-us/library/windows/desktop/dn788656(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dn7... DirectX is very C++, using namespaces and stuff. Its a bit wonky because DirectX itself is older than C++98, but its clearly a C++-based API. Its very efficient and performant too.
- microcolonel 9y ago> Nearly direct-access to the GPU Not sure what you consider "near", but I certainly wouldn't consider even Direct3D 12 to be anywhere "near" direct access to the GPU. It doesn't expose the shader ISA, it doesn't expose the command stream format, it doesn't expose the register sets. The user mode scheduler is not the system scheduler, thus my statement holds.
- dragontamer 9y ago> Not sure what you consider "near", but I certainly wouldn't consider even Direct3D 12 to be anywhere "near" direct access to the GPU. It doesn't expose the shader ISA, it doesn't expose the command stream format, it doesn't expose the register sets. Of course, none of those are important. The important bit to expose are exposed. IE: The memory-model of the GPU. CPU memory space vs GPU memory space, such as Residency: https://msdn.microsoft.com/en-us/library/windows/desktop/mt186622(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/mt1.... Indeed, the ability for C++ to create abstractions that can track memory spaces in DirectX is proof positive that C++ has useful features applicable to the OS developer. https://msdn.microsoft.com/en-us/library/windows/desktop/mt613239(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/mt6... ------- Note that both CUDA and OpenCL support C++ features as well. The RAII feature of C++ alone is a huge benefit to anybody tracking what bits are where in OS settings. Have you tried to use C++ in the last 10 years?
- 95014_refugee 9y ago... this might have been true 20 years ago. It certainly isn't today. Perhaps you stopped learning at some point? It's important (as many posters in this thread have already noted) to understand that C++ is many languages, and that bare-metal C++ is not necessarily the same language you would use elsewhere. The fact remains, however, that in the right hands it can be an excellent tool for the task, and certainly more expressive and capable than its predecessor.
- jononor 9y agoAll the Unixes, Linux, Windows NT, QNX, even XNU started before the first standardized version of C++ (1998). Plenty of issues with C++, but it is not a problem to write bare metal applications or a kernel with it, at least for the last 10 years.