Products > Programming

GCC's __BIGGEST_ALIGNMENT__ macro on RISC-V architectures

(1/2) > >>

HwAoRrDk:
GCC documents the __BIGGEST_ALIGNMENT__ macro as:


--- Quote ---GCC also provides a target specific macro __BIGGEST_ALIGNMENT__, which is the largest alignment ever used for any data type on the target machine you are compiling for. For example, you could write:


--- Code: ---short array[3] __attribute__ ((aligned (__BIGGEST_ALIGNMENT__)));

--- End code ---

--- End quote ---

However, I have found that in code compiled for 32-bit RISC-V microcontrollers, this macro's value is 16. ??? I would have expected it to be 4. That is, I would expect it to reflect the architecture's (as specified by -march) native word/register size - 4 bytes for RV32, 8 bytes for RV64, etc.

Where does 16 come from? Are they just blanket defining it as 16 because RV128 is a thing, and so therefore it obviously must be that when the target machine is any RISC-V architecture? ::) Surely it should be more nuanced than that...

xvr:
Stack alignment is 16. But I not sure how it connected to __BIGGEST_ALIGNMENT__ :)
May be something penetrated from Vector Extension  :-//

I wanted a rude username:
Since you're targeting RV32, more likely this is because of the Q extension (128 b float).

This is also how the compiler will align if you don't specify a size:


--- Code: ---int16_t array[3] __attribute__ ((aligned)); // Aligns to at least 16 B on most architectures
--- End code ---

Usually we use compiler hints of this type to tell the compiler something that we know and it doesn't. So in practice you'll find people specifying the desired alignment explicitly (e.g. 8 B in this case).

HwAoRrDk:
The thing is I understand that there are architecture variations (e.g. RV128) or extensions that give a data type with 128-bit width, but if I'm specifying, for example, -march=rv32ec where no instruction can work with anything larger than 4 bytes, then surely that shouldn't apply?

I picked up on __BIGGEST_ALIGNMENT__ because I was using __attribute__((aligned(n))) to specify that something needed to be word-aligned, and I thought that rather than specifying a fixed value, the macro would give me whatever the native word size was for the architecture being compiled for. But it seems it doesn't work like that, and just gives you the same value that __attribute__((aligned)) uses when not specifying a size. So what's even the point of the existence of the macro? Maybe it's different for different platforms... :-//

I wanted a rude username:
If you want to align on native word size ... why don't you just use __UNITS_PER_WORD__?

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod