Your world of microcontrollers is dominated by Eclipse.

It is inescapable. I changed microcontroller supplier, and all I got was another version of Eclipse. Almost familiar, but different enough to be annoying.

It'sjust a warning that GNU (and every other compiler designed for embedded applications) compilers have padding and packing #pragma and attributes to handle “implementation dependent” behaviours (for speed in access and addressing) even in the same family of processors.

Padding becomes critical with things like memory mapped interfaces where you can have various variable types (and byte sizes) and needed alignments in the same set of structures.

http://www.catb.org/esr/structure-packing/

I can use #pragma to force it to use misaligned uint16_t and uint32_t but I’m not entirely sure that it works the same way every time.

 

I don’t mean that it was required to do that. I just observed that it did.

Oh, okay.

Just be careful not to rely on that observation. Even if you just upgrade to a new version of the same compiler, it is free to change how it handles structure member alignment. It probably won't, but if it does, all of your code will break as soon as it's recompiled and you will likely play merry hell figuring out what happened because, from your view of things, absolutely nothing changed.

Also, if you give/sell your code to anyone else and they compile it, they may get different results and their code won't work.

 

Oh, okay.

Just be careful not to rely on that observation. Even if you just upgrade to a new version of the same compiler, it is free to change how it handles structure member alignment. It probably won't, but if it does, all of your code will break as soon as it's recompiled and you will likely play merry hell figuring out what happened because, from your view of things, absolutely nothing changed.

Also, if you give/sell your code to anyone else and they compile it, they may get different results and their code won't work.

Portability is a myth when dealing with microcontrollers. My only worry would be a new version of GNU C compiler.
The ARM has a load halfword instruction, which works on two-byte boundaries, so one would assume a compiler would use that and align 16 bit variables on two-byte boundaries.

However, a quote from a former colleague:
”‘I assume’ precedes a cock-up”

 

It is inescapable. I changed microcontroller supplier, and all I got was another version of Eclipse. Almost familiar, but different enough to be annoying.


I can use #pragma to force it to use misaligned uint16_t and uint32_t but I’m not entirely sure that it works the same way every time.

It probably does, but....

#pragma is, pretty much by definition, invoking and configuring implementation-defined behaviors, so the same pragma could do completely different things in different implementations. On a course level, it is probably unlikely as compiler developers have motivation to be consistent with the meaning of common #pragma directives that are already out there. But in the fine print, they may either not know enough of the subtle details to behave exactly the same, or behaving exactly the same may simply not be an option on that particular platform (or may not make sense).

 

Portability is a myth when dealing with microcontrollers. My only worry would be a new version of GNU C compiler.
The ARM has a load halfword instruction, which works on two-byte boundaries, so one would assume a compiler would use that and align 16 bit variables on two-byte boundaries.

However, a quote from a former colleague:
”‘I assume’ precedes a cock-up”

Agreed -- and I've never written a C program for a microcontroller (have always used assembly for the brain-dead micros I work with). But I know folks that do use it a lot and have run into issues because they were providing source code for a particular MCU and other folks, targeting that exact same MCU, but using a different compiler, ran into implementation-specific differences. One of these guys, because it was important for the project (and for him to get paid!) spent quite a bit of time eliminating as much of the implementation-defined behaviors as he could without sacrificing performance too much. It was a lot of effort, but in the end he actually had a program that compiled and ran correctly on all of the compilers involved (without invoking compiler-specific #pragmas) and only took about a 10% performance hit, which was acceptable. I wasn't privy to the details and, to a large degree, neither was he. But he came to the conclusion that this requirement was driven by contract language that was out of touch with reality and they ended up paying him a lot more to meet the letter of the requirements (and take a performance hit that wasn't needed) when it would have made a lot more sense to just accommodate other compilers down the road when and if the need arose.