ESP32 Forum

I've heard about structure padding to reduce R/W operations to access a struct member, and that there is "packed" option to disable this padding optimization.

I would like to write struct in certain order, to keep mutual parameters together.
But to apply reorder optimization at compilation to reduce used memory space while minimalizing R/W operations for most struct members.
Note: __reorder__ is made up, but I am looking for some attribute with this effect

I know that, according to C standard, compiler is not allowed to automatically reorder structure, but can I somehow explicitly ask it to do so for particular structure?

Not that I know of.
I know your pain, and have thought that this would be an excellent addition to 'C', especially in the embedded world, but sadly that's unlikely to happen.

can I somehow explicitly ask it to do so for particular structure?

It appears that this is not possible a.t.m.

Hello,
You are looking for #pragma pack and #pragma align. Do an internet search on both of these.

Regards,
Ron

Problem with packing is that gcc will (on ESPs mostly unnecessarily) generate slow, byte-wise accesses, see e.g.
https://godbolt.org/z/nKc9Tcx4f
Notice that the access to what gcc determines to be an unaligned/packed uint32_t generates ten assembler instructions, compared to one instruction for a properly aligned struct member, or one or two for the possible "proper" access to the unaligned one.
Same thing for both Xtensa and RISC-V.

Wow I expected like only one or two more instructions for unaligned struct access, not 10

However, in terms of speed, does one Assembler instruction take always at least one CPU clock tick? Can't it process some instructions at once? So the Assembler code may look slow, but actually it could be done in 2-3 clock ticks? But this is probably too complicated to be covered in this topic

So, reordering struct members could optimize memory usage and still be as fast as aligned struct access, right?
Too bad there is no option for such optimization in 2023

ghost07 wrote: ↑

Fri Oct 13, 2023 11:32 am

However, in terms of speed, does one Assembler instruction take always at least one CPU clock tick? Can't it process some instructions at once? So the Assembler code may look slow, but actually it could be done in 2-3 clock ticks?

Nope. It's as bad as it looks. AFAICT none of the ESPs can retire more than 1 instruction per clock cycle (per core). - Even worse: All that code needs to be loaded from slow flash memory, at least leaving less space in the cache for 'useful' code.

So, reordering struct members could optimize memory usage and still be as fast as aligned struct access, right?

Correct. Ordering members by size, biggest data types first, keeps alignment and can reduce or eliminate padding.