On Tue, Nov 26, 2013 at 7:12 AM, Paulo Matos <pma...@broadcom.com> wrote:
>
> I am slightly confused about the BIGGEST_ALIGNMENT docs which state:
> "Biggest alignment that any data type can require on this machine, in bits.
> Note that this is not the biggest alignment that is supported, just the
> biggest alignment that, when violated, may cause a fault."
>
> What kind of fault would this be?
An instruction that fails to execute correctly because the memory
address is misaligned. For example, on many RISC chips, a memory load
of a 16-bit or larger value from an odd address will fail. For
example, on x86, an aligned load of an SSE register from an address
not aligned to an 16-byte boundary will fail (the x86 does have
different unaligned load instructions for SSE registers).
> We currently have it set to 64, word_size. However, we really have no
> alignment restrictions being able to align data types to byte boundaries if
> necessary. Therefore, from this piece of code:
> unsigned int
> get_mode_alignment (enum machine_mode mode)
> {
> return MIN (BIGGEST_ALIGNMENT, MAX (1,
> mode_base_align[mode]*BITS_PER_UNIT));
> }
>
> I am tempted to set BIGGEST_ALIGNMENT to 8 so I can force GCC to just align
> the data at any byte boundary. Would this be a fair use of BIGGEST_ALIGNMENT?
> If not, then should BIGGEST_ALIGNMENT be equal to the largest supported mode
> on our machine? I am quite confused about what fault it could happen in
> BIGGEST_ALIGNMENT is violated, therefore for our machine I guess
> BIGGEST_ALIGNMENT can be as high as possible.
If your processor can execute a memory load instruction from any
address, and if memory is addressed in 8-bit bytes, then
BIGGEST_ALIGNMENT should be set to 8.
Ian
