Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I see on quite a few job descriptions for embedded developer positions, that a requirement would be for example to have knowledge of embedded C programming on ARM microcontrollers.
What's not very clear to me is , what is the difference between having knowledge of developing C for a particular ARM processor, or developing C for a PowerPC or other type of processor. Developing with C we are abstracted from the actual instructions which will get compiled and the architecture so why does it really matter?
I would guess that it is important mainly to have knowledge of embedded development, knowing memory constraints etc. and that the actual target processor wouldn't matter too much. For example, won't a developer who was writing code for PowerPC MCUs for many years be just as good as developing code for an ARM-based or other type of MCU?
Perhaps i'm missing something obvious here. Please could someone give an example of what could be some major differences between writing C/C++ code for one type of processor and another type. Thanks
All you write about Linux and kernels, but 99% of the embedded work is purely bare metal. therefore, the knowledge of the core and peripherals is essencial.
In the most cases, before Linux programmers learn how to program the bare metal, they are way useless.
And this time needed costs your employer money.
As usual, it depends.
If you are going to develop at a deep C level, it is a good idea to know about the architecture, in order to optimize your code according to speed or/and memory (data bus size, instructions per clock, etc).
It is a must if you are going to develop at a deeper level (and if we are talking about ARM and its thumb, thumb2 and ARM... It is madness).
Furthermore, each architecture because of legacy reasons or to make our life better, adds some tricks. For instance, ARM PC points to the instruction after the next one to be executed, which is quite different in PowerPC or RH850 or whatever.
Above that (I mean, above or close to an OS), the compiler uses to be better than us, but anyway, it is a nice to know how it is working (and definitely it will make the debugging easier)
The answer is yes and no.
If a job is more of application related then MCU specific knowledge will be of little help
If the software development is at kernel/BSP/drivers or hardware related then the knowledge of MCU/CPU hardware is critical.
Please check the Job Description in details to know the kind of work expected.
Well, I haven't written any ARM code myself, but I would think the ARM-specific experience would be (in no particular order):
Experience with ARM-specific toolchains (particularly non-standard parts of that toolchain, pieces of proprietary software etc)
Knowledge of which relevant libraries are available on ARM rather than on Intel machines, and whether their ARM version is performant enough, stable enough etc.
Knowledge of how certain coding patterns look like when compiled to ARM machine code, and consequently, good discretion regarding certain choices regarding low-level implementation.
Ability to write inline ARM assembly when and if necessary
Knowledge of ARM systems' cache layout
Ability to estimate/forecast the power economy of code rather than its mere performance (as ARM processors are sometimes more concerned with that).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Given that Java is highly portable and it is not having serious overheads, can't C++ be made platform independent?
Yes, it is perfectly possible. For example, you can compile C++ to JavaScript ( see https://softwareengineering.stackexchange.com/questions/197940/how-to-run-c-code-in-browser-using-asm-js ) or to CLI byte code ( https://en.wikipedia.org/wiki/C%2B%2B/CLI ) to run on Windows or Linux, or various other targets.
None of these currently performs as well as native C++, and most lack direct access to operating system resources. So the portability comes at some cost, and usually if you wanted to pay the cost of targeting web browsers or CLI, you have languages better suited to those platforms.
In reality, the method of code execution (whether the code is compiled, interpreted, run by VM, etc) is more a property of the implementation, and not the language.
when people say C++ is a compiled language and that JavaScript is an interpreted language, that does not necessarily mean that you can't write a compiler that translates JavaScript code to machine code on your hardware of choice, but rather what is a common way to provide implementation for said language.
In practice, C++ is used because of its efficiency and close to the metal features that is a good choice for performance critical tasks like embedded systems programming, systems programming, graphics, etc, so getting C++ to run in a VM would defeat its purpose.
kinda like buying a fillet Mignon and cooking it in the microwave.
Java compiles to an intermediate platform-independent byte code that is then interpreted at runtime by platform-specific JVMs. That is what allows Java to be portable. Each type of JVM is tailored to run the byte code on the platform's particular hardware architecture.
C/C++ compiles to native machine code that runs directly on the CPU (or as directly as the OS will allow). So no, you cannot compile C/C++ in a platform-independent manner. You have to use platform-specific compilers to compile C/C++ code for each hardware architecture that you want to run your code on.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
From what I know, even though the common OS have parts written in other languages, the kernel is entirely written in C.
I want to know if it's feasible to write a Kernel in C++ and if not, what would be the drawbacks.
There are plenty of examples of well-used operating systems (or parts of them) implemented in C++ - IOKit - the device driver subsystem of MacOSX and IOS is implemented in EC++. Then there's the eCOS RTOS - where the kernel is implemented in C++, even making use of templates.
Operating systems are traditionally awash with examples of OO concepts implemented the hard way in C. In the linux device model kobject is effectively the base-class for driver and device objects, complete with DIY v-tables and some funky arrangements implemented in macros for up and down-casting.
The Windows NT kernel has an even more deeply rooted inheritance hierarchy of kernel objects. And for all of the neigh-sayers complaining about the suitability of exception handling in kernel code, exactly such a mechanism is provided.
Traditionally, the arguments against using C++ in kernel code have been:
Portability: availability of C++ compilers for all intended target platforms. This is not really an issue any more
Cost of C++ language mechanisms such as RTTI and exceptions. Clearly if they were to be used, the standard implementation isn't suitable and a kernel-specific variant needs using. This is generally the driver behind the use of EC++
Robustness of C++ APIs, and particularly the Fragile base-class problem
Undoubtedly, the use of exceptions and RAII paradigm would vastly improve kernel code quality - you only have to look at source code for BSD or linux to see the alternative - enormous amounts of error handling code implemented with gotos.
This is covered explicitly in the OSDev Wiki.
Basically, you either have to implement runtime support for certain things (like RTTI, exceptions), or refrain from using them (leaving only a subset of C++ to be used).
Other than that, C++ is the more complex language, so you need to have a bit more competent developers that won't screw it up. Linus Torvalds hating C++ being purely coincidental, of course.
To address Torvalds' concerns and others mentioned elsewhere here:
In hard-RT systems written in C++, STL/RTTI/exceptions are not used and that same principal can be applied to the much more lenient Linux kernel. Other concerns about "OOP memory model" or "polymorphism overhead" basically show programmers that never really checked what happens at the assembly level or the memory structure. C++ is as efficient, and due to optimized compilers many times more efficient than a C programmer writing lookup tables badly since he doesn't have virtual functions at hand.
In the hands of an average programmer C++ doesn't add any additional assembly code vs a C written piece of code. Having read the asm translation of most C++ constructs and mechanisms, I'd say that the compiler even has more room to optimize vs C and can create even leaner code at times. So as far as performance it's pretty easy to use C++ as efficiently as C, while still utilizing the power of OOP in C++.
So the answer is that it's not related to facts, and basically revolves around prejudice and not really knowing what code CPP creates. I personally enjoy C almost as much as C++ and I don't mind it, but there is no rational against layering an object oriented design above Linux, or in the Kernel itself, it would've done Linux a lot of good.
You can write an OS kernel in more or less any language you like.
There are a few reasons to prefer C, however.
It is a simple language! There's very little magic. You can reason about the machinecode the compiler will generate from your source code without too much difficulty.
It tends to be quite fast.
There's not much of a required runtime; there's minimal effort needed to port that to a new system.
There are lots of decent compilers available that target many many different CPU and system architectures.
By contrast, C++ is potentially a very complex language which involves an awful lot of magic being done to translate your increasingly high-level OOP code into machine code. It is harder to reason about the generated machine code, and when you need to start debugging your panicky kernel or flaky device driver the complexities of your OOP abstractions will start becoming extremely irritating... especially if you have to do it via user-unfriendly debug ports into the target system.
Incidentally, Linus is not the only OS developer to have strong opinions on systems programming languages; Theo de Raadt of OpenBSD has made a few choice quotes on the matter too.
The feasibility of writing a kernel in C++ can be easily established: it has already been done. EKA2 is the kernel of Symbian OS, which has been written in C++.
However, some restrictions to the usage of certain C++ features apply in the Symbian environment.
While there is something "honest" about (ANSI) C, there is also something "honest", in a different way, about C++.
C++'s syntactic support for abstracting objects is very worthwhile, no matter what the application space. The more tools available for misnomer mitigation, the better ... and classes are such a tool.
If some part of an existing C++ compiler does not play well with kernel-level realities, then whittle up a modified version of the compiler that does it the "right" way, and use that.
As far as programmer caliber and code quality, one can write either hideous or sublime code in either C or C++. I don't think it is right to discriminate against people who can actually code OOP well by disallowing it at the kernel level.
That said, and even as a seasoned programmer, I miss the old days of writing in assembler. I like 'em both ... C++ and ASM ... as long as I can use Emacs and source level debuggers (:-).
Revision after many years:
Looking back, I'd say the biggest problem is actually with the tons of high level features in C++, that are either hidden or outside the control of the programmer. The standard doesn't enforce any particular way of implementing things, even if most implementations follow common sanity, there are many good reasons to be 100% explicit and have full control over how things are implemented in a OS kernel.
This allows (as long as you know what you are doing) to reduce memory footprint, optimize data layout based on access patterns rather than OOP paradigms, thus improve cache-friendliness and performance, and avoid potential bugs that might come hidden in the tons of high level features of C++.
Note that even tho far more simple, even C is too unpredictable in some cases, which is one of the reasons there is also a lot of platform specific assembly in the kernel code.
Google's new-coming operating system Fuchsia is based on the kernel called Zircon, which is written mostly in C++, with some parts in assembly language[1] [2]. Plus, the rest of the OS is also written mostly in C++[3]. I think modern C++ gives programmers many reasons to use it as a general programming environment for huge codebases. It has lots of great features, and new features are added regularly. I think this is the main motive behind Google's decision. I think C++ could easily be the future of system programming.
One of the big benefits of C is it's readability. If you have a lot of code, which is more readable:
foo.do_something();
or:
my_class_do_something(&foo);
The C version is explicit about which type foo is every time foo is used. In C++ you have lots and lots of ambiguous "magic" going on behind the scenes. So readability is much worse if you are just looking at some small piece of code.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I will give internal training about C++ on ARM, focusing on programming tips and hints, and I searched some webpages like:
Embedded C interview Questions for Embedded Systems Engineers
Efficient C for ARM
all of above are mainly for C on ARM, in that I am wondering they apply to C++ as well, say struct padding and etc
can you help me on that, T.H.X
I didnt look at the first link, the second link Efficient C for ARM is very good, thanks for finding and sharing that, I am going to refer people to that link.
In the same way that the Zen of Assembly language is still as relevant today as when it came out is not because the modern x86 is related to the 8088/86 and the "cycle eaters", but because the thought process and analysis taught doesnt change over time. The cycle eaters might from language to language or target to target, but how you find them doesnt. That book was outdated and irrelevant when it came out as far as the tuning for an 8088/86 or so I read somewhere, but I read it then and use what I learned every day since.
Same here the Efficient C for ARM applies well to similar items in C++, but more importantly look at the early slides, before any specific structures or code is shown. You have to analyze by inspection, and by using a profiler (no different than what Zen of Assembly language says, look at it and time it). Then the Efficient C for ARM page goes on to inspect some examples, take your C++ code and compile it, then disassemble, and see what is really happening. The problem with doing that is that you have to realize that there are many tuning knobs on a compiler and compilers are constantly evolving, and different compilers say, gcc, llvm (clang) and visual C/C++ are completely different. The same C++ source code presented to the different compilers and different versions of the compilers and the same compilers with different optimzation settings is going to produce different results.
When you want to micro-optimize you have to learn a lot of how the compilers work by getting a considerable amount of experience at disassembling and analyzing what the compiler does with your code (FOR EACH TARGET YOU CARE ABOUT). Only then can you begin to do some real optimization without having to resort to writing assembler. Despite what folks may tell you you can do this, you can for some situations significantly improve execution performance by simply rearranging structures, functions, lines of code, etc. Also make code that is more portable to other processors and make code that is generally faster on a number of platforms, not just one. The nay-sayers are right in that you need to have a good reason for it, sometimes it doesnt change the readability, but often taking it to far makes your code unreadable or unmaintainable or fragile, etc. Always arrange your structures in a sensible way, larger, aligned variables first, then progressively smaller. Other things though you may not want to do as a habit but only for special occasions.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
So lately I've been intrested in reading assembly which is displayed by a disassembler like ollydbg. The reason why I want to read this assembly is to learn how other developers build their applications or things like file formats of binary files the program has.
It's not like I'm a complete newbie at programming since I've been using C++ and C# for a while now. And I have a solid understanding of C++ so the whole pointer concept is clear to me.
Well I know that there are tons of assembly guides out there on the internet but I have no idea how reliable they are this tutorial: http://jakash3.wordpress.com/2010/04/24/x86-assembly-a-crash-course-tutorial-i/ was very usefull too me and this is the kind of tutorial with just a short explanation of the instruction. This one was very clear to me but it doesn't cover all of the assembly codes.
I hope someone could give a good guide/tutorial.
I think the standard guide to assembly is The Art of Assembly. It's online and free.
If you are interesed in x86 assembly and the opcodes for all instructions, try the Intel manuals (free download). If you want to know how to program in assembler, use the recommendation by Seth Carnegie. Another download would be the 32 bit edition.
I learned much of what I know about assembly language from Matt Pietrek's Just Enough Assembly Language to Get By and its sequel. This is especially made for C or C++ programmers wanting to read what the compiler emits in their debugger.
Pietrek's material is above any doubt and he writes clear and entertaining. It's tailored to the Windows platform, though.
This is a different approach. I recently released a first draft of learning assembly by example. It is not x86 assembly though, on purpose. Learning a better and easier to understand instruction set first, will get you through the basic concepts, from there other instruction sets, x86 included are often a matter of downloading an instruction set reference for the desired processor. https://github.com/dwelch67/lsasim
Normally googling xyz instruction set will get you a number of hits (instead of xyz choose the one you are interested in, arm, avr, 6502, etc). Ideally you want the vendors documentation which is usually free. There have been so many variations on the x86 by different companies that it adds to the mess. There are a lot of good online references though. For other families, msp430, avr, arm, mips, pic, etc, you can often go to the (core processor) vendors site to find a good reference. msp430, arm and thumb are also good first time instruction sets if you are not interested in the lsa thing. mips or dlx as well so I am told unfortunately I have not learned those yet. avr and x86 after you have learned something else first. Pic has a few flavors, the non-mips traditional pic instruction set is certainly educational in its simplicity and approach, might be a stepping stone to x86 (I dont necessarily recommend pic as a first instruction set either). I recommend learning a couple of non-x86 instruction sets first. And I recommend learning the 8088/86 instructions first, I can give you an ISBN number for the original intel manuals, can probably be found for a few bucks at a used book store (online). Lots of websites have the x86 instruction set defined as well, I highly recommend a visible simulator first before trying on hardware, will make life easier...qemu for example is not very visible nor easy to make visible. gdb's simulators might be as you can at least step and dump things out.
I really liked Programming From the Ground Up, a free book which aims to teach you the basics of ASM programming in a pretty easy to understand way. You can check it out here:
Programming from the Ground up
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've been asked many times by my juniors about the areas in which C++ is widely used. I usually answer Operating Systems. Are there any other areas where its extensively used?
A quite large and probably quite definitive list of software written in C++ can be found at Bjarne Stroustrup's homepage.
Numerical computations: physics, graphical games, finance, statistics;
Bit fiddling: drivers, operating systems, networking, embedded devices;
Anywhere you need exact control of allocation of memory.
I wouldn't say Operating Systems actually. The Linux & Windows kernels are mostly C, with only userland stuff being C++ (granted, drivers could be written in anything). I'm not sure about Mach (OS X), but I wouldn't be surprised if it were mostly C as well.
C++ filled this wonderful nitch of "Object Oriented, but fast enough for dinky computers in the late-80s & early-90s". Accordingly, anything written in the 90s had a good chance of being written in C++; applications, drivers, games, whatever.
Today, new development seems to be done mostly in managed (JVM/.NET) languages. Not that there isn't any new C++ development; games, in particular, are still performance limited enough to use C++ in many cases.
In short:
Drivers
Games
LEGACY CODE
C++ is also used heavily in real-time financial market data software. Latency here is very important. C++ is great choice since it's almost the closest to metal.
C++ and C are used heavily in embedded systems since one can have deterministic control of memory and other scarce resources. I think most games (well at least the games I play) are still written in C++, probably because there exists large frameworks written in C++ which have been fully tested and are very capable.
it's used where you find it solve your problems efficiency. Compilers, writing Drivers ...
Currently it is in game development and performance critical applications. However, there is lots of older stuff written in C++ which was mostly written before Java and .NET were introduced, and this code still needs to be maintained.
Consider this: From the introduction of MFC until the introduction of the .NET framework, C++ was the preferred language for Windows development. So that should tell you something. Preferred by Microsoft that is, many developers still prefer it to .Net languages.
C++ is a language capable of systems level programming, but also due to the provision of extensive libraries it is used for applications programming also. I would guess that almost every application running on your Desktop PC was written in C++.
If you can get a library for anything, you can almost certainly get it for C++.
It is widely used in the games industry, and to some extent in the embedded systems domain.
So I would say - 'everywhere'. It is after all a 'general purpose' programming language.
I have seen C++ used quite heavily in GUIs, due to the object orientated nature being sort of natural for "widgets".
I once saw it used in safety-critical code for an aircraft. This still gives me nightmares.
Any application based on Qt will use it as Qt is written in C++.
Also, since KDE is based on Qt pretty much the whole desktop environment including the applications designed to work within it are therefore written in C++.
C++ in Operating Systems: No kernels (the core bit that really does all the nasty work like memory management and drivers ) that I know of are written in C++, just C. Linux is written in C and so is Windows.
See here:
What Languages are Windows, Mac OS X and Linux written in?
Applications ( non-kernel bits that make up an OS ) these days are written in whatever language seems best for the job.
You would choose C++ if the following were important to you:
You want to make heavy use of classes and inheritence
You only plan on working on one OS
You want reasonable performance
Your developers already know C++
You want to divide work on similar components to different people or teams ( you can give each time a class or interface to implement )
You can do all of the above with C, portability between platforms is still an issue ( C++ is equally platform specific as most C ) In C you have to be more strict make good use of static and dynamic analysis tools. It's easier to leak memory in C than in C++ too.
Most antivirus software are written in C++
Several major operating systems have been written in c++
Uncompromising low-level efficiency essential for C++. This allows us to use C++ to write device drivers
Much numerical, scientific, and engineering computation is done in C++.
Graphics and user interfaces are areas in which C++ is heavily used.
C++ is widely used for teaching and research
Games
In legacy code...
Even Stroustrup admits C++ has many mistakes, most inherited from C.
That is why C++0x is being developed.