Thread: General (noob) question about C++ and embedding programming

Hello, I had a very general question, not a specific programming question. I've programmed in C++ before, and in assembly for the Motorola 68k in academic settings, if that helps answer.

How much control does one have (within C++ language and the C++ compiler being used) over memory alignment and management at the really low-level?

I've read that compilers often make their own optimizations or re-arrange what they perceive to be inefficient source code. I'm interested in particular in cases when a given project hasn't been written entirely in assembly. If a part of a program has been written in C++ and another critical part has been written in assembly code, and they must be integrated, how is that done? Are there cases where the capabilities of the C++ language cannot deal with the low level nature of what is needed and assembly code MUST be written? What are common tools/software that an embedded C++ programmer might use when a project requires higher level C++ concepts/objects as well as low-level memory concerns?

Read the Compiler documentation; because that is what a embedded C++ programmer must do to know the answer.
It likely changes for each Compiler Vendor; it might even change for each embedded target or compiler version.

I would suggest looking at the #pragma pre-processer command/keyword; this is often where C compilers have this documented.

Edit: Searching on byte padding or packing will also likely get the answer for a given compiler.

Tim S.

Originally Posted by Ocifer

How much control does one have (within C++ language and the C++ compiler being used) over memory alignment and management at the really low-level?

That depends on both the compiler and the host system (embedded development does not exclude there being an operating system which mediates access to the hardware by programs).

Originally Posted by Ocifer

I've read that compilers often make their own optimizations or re-arrange what they perceive to be inefficient source code.

Compilers aren't all that perceptive but, yes, compiler optimisation can re-arrange code to enhance particular criteria (such as performance, or memory usage). There are limits on the ability of any compiler to do that. Firstly, code with well defined behaviour according to the standard cannot be reordered so it produces different observable effects (for example, output). Second, more significant optimisations require considerable, in depth, analysis of the program - and that is difficult for compiler developers (mere mortals) to implement.

Conversely, C++ code with undefined behaviour can be reordered by a compiler to a ridiculous degree, since there is no guarantee of what the result is.

Originally Posted by Ocifer

I'm interested in particular in cases when a given project hasn't been written entirely in assembly.

I've yet to hear of any C++ projects that are written entirely in assembly. More seriously, however, C++ compilers don't generally optimise assembler source code, and I've yet to come across one that will reorder inline assembly.

Some other programs in the build chain might analyse the structure of object files and the resultant executable, and do their own optimisations, but those programs are distinct from a C++ compiler.

Originally Posted by Ocifer

If a part of a program has been written in C++ and another critical part has been written in assembly code, and they must be integrated, how is that done?

That is specific both to the compiler and the assembler. Generally speaking - as is the case when integrating code from ANY two programming languages into one program - there will be a specification of how the two interface to each other.

With C++ and assembler, there will be information on how C++ code constructs map to assembly. Some of those (alignment of variables, struct types, etc) are compiler specific. Bear in mind that assembly tends to be specific to a particular family of host platforms and the means C++ compilers (or compilers of any other language) map to assembly are specific both to the compiler and host platform.

As Tim mentioned, those things can be controlled by the developer using things like pragmas (compiler specific extensions).

Originally Posted by Ocifer

Are there cases where the capabilities of the C++ language cannot deal with the low level nature of what is needed and assembly code MUST be written?

There are sometimes requirements that can't be demonstrably met by C++ code, when compiled with a particular C++ compiler, and when targeting a particular host (where host means the entire platform - all its hardware, the operating system if any, etc).

In practice, such requirements are pretty rare, unless you're working in a space of very low level code. Examples might include writing a device driver for an operating system for some new hardware, or an interface module so a C++ program running "on the metal" (i.e. sans operating system) can directly access some bespoke hardware. Sometimes such things need to be written in assembler. Even then, more often than not, they can be written in C++ (or sometimes C rather than C++) without resorting to assembler - because a compiler is often written by knowledgeable people, and can therefore often optimise the code it emits better than the average programmer can hand-craft assembler for a similar purpose.

Originally Posted by Ocifer

What are common tools/software that an embedded C++ programmer might use when a project requires higher level C++ concepts/objects as well as low-level memory concerns?

The primary tool is their brain. In practice "higher level C++ concepts/objects" rarely interact directly with code with "low-level memory concerns" - if they do, it's usually a sign of premature optimisation (i.e. a programmer lovingly optimising low level details without any identified need to do so).

An experienced C++ developer will usually start by designing and implementing as much as possible at a higher level of abstraction, in order to meet functional requirements (bear in mind that performance and memory usage are rarely functional requirements - they are usually quality aka "non-functional" concerns). They will focus on picking representative (as opposed to best) algorithms, and ensuring code produces the required output from inputs. Then they will analyse (with the help of tools like profilers, but also based on design information) attributes like performance, or memory usage, or whatever. If a performance requirement is not being met, a profiler can often be used to find the parts of code that are contributing to that deficiency. If a memory requirement is being exceeded, various memory mapping tools might be used to identify the problem. Once they've worked out the cause of a deficiency, the first choice is often selecting better algorithms (for example, using a different sort algorithm from the standard library that is better optimised for the use case at hand, or maybe implementing a different one if none of the sorting algorithms in the standard library are sufficient). That is sufficient, more often than not - and, at this point, everything will probably still be written in C++. Sometimes requirements might be revisited (to determine if a stated requirement is truly a requirement, rather than a nice-to-have) and updated. Sometimes the problem might be solved by only offering a guarantee of correct execution if the program is run with a given CPU (or better) or with some minimum amount of RAM. Doing things in assembler - and having to address all the compiler-specific interfacing issues - is truly a last resort ... and only if a case can be made that, by doing so, requirements will be met.

True, the cross-over point where assembler is necessary often comes sooner with less capable and/or less modern hardware. But the general approach is the same - don't be afraid of using assembler, but don't reach for it prematurely. Learning assembler (on a host platform that is practically useful to you, whether that platform is embedded or not) is useful both at a high level (understanding how to write high level code that is more likely to cause a compiler to emit decent code) and low level (interesting to do in its own right). However, one of of many hallmarks of inexperienced developers is reaching for assembler before they need to, and using it a lot more than necessary in production code.

Originally Posted by Ocifer

How much control does one have (within C++ language and the C++ compiler being used) over memory alignment and management at the really low-level?

C++11 added some standard tools for specifying the alignment of variables. But you may have to use compiler specific intrinsics for some cases, or when there is no C++11 support.

I've read that compilers often make their own optimizations or re-arrange what they perceive to be inefficient source code. I'm interested in particular in cases when a given project hasn't been written entirely in assembly. If a part of a program has been written in C++ and another critical part has been written in assembly code, and they must be integrated, how is that done?

There are two ways to include assembly in C++ code. One, you can write functions in assembly. Those functions must obey a particular calling convention, and then they can be linked with a c++ program. The simplest calling convention is the C convention, and if you use that, you can treat your assembly functions as C functions. Two, you can use assembly in asm blocks in c++. That's usually easier, because you don't have to worry about linking, and it allows you to hand optimize only the part that needs it without wrapping it in a function call.

In both cases, assembly is treated as a very strong barrier for code movement, which significantly hinders the compiler's ability to optimize around it.

Are there cases where the capabilities of the C++ language cannot deal with the low level nature of what is needed and assembly code MUST be written?

Generally not, because your compiler will provide builtin functions for architecture specific operations.

What are common tools/software that an embedded C++ programmer might use when a project requires higher level C++ concepts/objects as well as low-level memory concerns?

A good profiler! But C++ gives you very low level control over memory so you don't really need assembler for that.

And remember, most of the time the compiler is better at optimizing code than you are.

Originally Posted by Aslaville

That is not true.

You have to label your code volatile to make sure that the compiler does not interfere with it However most of the code the programmers write in inline assembly is now optimizable.You could try writing a loop in inline assembly and the compiler will optimize it.

If you do NOT state the name and version of the compiler that does this; then, I think you will be ignored!!

Tim S.

If you do NOT state the name and version of the compiler that does this; then, I think you will be ignored!!

O_o

In practice, several compilers do reorder, attempt to optimize, or otherwise trample over "inline assembler"--such as inserting instructions between `asm' lines.

Seriously, you have to go out of your way to prevent "ICC", "GCC", and "Clang" from mucking about with your "inline assembler".

Of course, you could argue that the C++ compiler isn't responsible; you could argue, as grumpy, that the "back end" or whatever is responsible.

*shrug*

In practice, it doesn't matter which tool in the chain is responsible if the code doesn't make it into the final binary unchanged.

Soma

phantomotap: I suggest you read those two posts looking with the eye for logic.

I hate people who say the compiler always does X; but, they are either saying all compilers does X or they are idiots who do NOT say which compilers does X.

I considered anything said by a idiot to be bad info till given proof that it is true.

Tim S.

I suggest you read those two posts looking with the eye for logic.

O_o

I suggest you, at the very least, actually read comments before you post a response.

I did not say anything about your issue with the implication that "all compilers always".

I gave context for the comment with which you have a problem removing the "all compilers always" interpretation in the process.

Is that your problem? Are you upset that someone offered a clarification to a comment making your interpretation invalid?

Or are you upset is was me instead of Aslaville who added context?

And just so as we are clear, I don't care if you think I'm an idiot. I'm not going to waste my time listing every version of every compiler that fits which I'm aware of to satisfy a fool condition when "looking with the eye for logic" tells us that Aslaville was simply providing anecdotal evidence related to a comment made by grumpy which was itself anecdotal evidence.

The post by Aslaville could have been better written, and the post could have been written without the implication the grumpy was wrong (The post grumpy made notes a general view not an absolute.), but your post in response was no better. You could, for example, have said what you take issue with instead of just barking out that you have an issue.

Soma

So you can read this line the way I did!!!!!

You could try writing a loop in inline assembly and the compiler will optimize it.

Tim S.

Originally Posted by stahta01

So you can read this line the way I did!!!!!


Tim S.

Am talking of GCC but am certain even clang will do the same thing and many other compilers.

Originally Posted by Aslaville

Am talking of GCC but am certain even clang will do the same thing and many other compilers.

So from you reply should I assume every version of GCC optimizes embedded asm no matter what options are given to the compiler/linker?

Tim S.

I apologize in returning to this question so late. Thank you very much for your answers, they were helpful.