Выравнивание данных в памяти(стеке), Зачем всё это? Опции

[sigmaN]

Добрый день.
Вот разбираюсь с TMS320F28335...
Пробую линковать по разному....и вижу, что даже когда размер стека достаточный, но он размещен не там где надо - у меня глючит код. Я начал вчитываться в документацию и увидел там alignment...т.е. зачем-то всё любят выравнивать.
Я хотел-бы узнать зачем?
Я так подозреваю, кроме стека, выравнивать нужно и всё остальное. ..У линкера есть директива align, например.
А как выравнивать? По 16, 32, 64?
Разъясните мне ламеру саму суть операции)) Ведь тогда получаются дырки и память может использоваться не так эффективно.....её и так нехватает))

[aaarrr]

Суть операции в том, что далеко не на всех архитектурах можно обращаться к памяти без выравнивания. Да и на тех, где можно, это приводит к снижению производительности.

Т.е. 16-и битные данные должны укладываться по четным адресам, 32-х бтные - по адресам, кратным 4 и т.д.
Для стека иногда бывают дополнительные ограничения.

[Nitrotoluol]

Выравнивание данных — способ размещения данных в памяти особым образом для ускорения доступа.

Центральные процессоры в качестве основной единицы при работе с памятью используют машинное слово, размер которого может быть различным. Однако, размер слова всегда равен нескольким байтам (размер байта является единицей, в которой отсчитываются адреса). Как правило, машинное слово равно 2k байтам, т.е. состоит из одного, двух, четырёх, восьми и т.д. байтов.

При сохранении какого-то объекта в памяти может случиться, что некое поле, состоящее из нескольких байтов, пересечёт «естественную границу» слов в памяти. Некоторые модели процессоров не могут обращаться к данным в памяти, нарушающим границы машинных слов. Некоторые могут обращаться, но к невыровненным данным обращение дольше, нежели к данным, находящимся внутри целого «машинного слова» в памяти.

[sigmaN]

А что можно сказать о TMS320F28335?
читаю, что стек должен быть выровнян:
The stack pointer (SP) must be even-aligned by the parent function prior to making a call to the child
function. This is done by incrementig the stack pointer by 1, if necessary. If needed, the coder shoud
increment the SP before making the call.
На сколько я понимаю, в этом случае всё это забота компилятора?
А как насчёт данных в памяти?
Курил C28 CPU and instruction set.
Вижу вот это:
All 32-bit reads and writes to memory are aligned at the memory interface to
an even address boundary with the least significant word of the 32-bit data
aligned to the even address. The output of the address generation unit does
not force alignment, hence pointer values retain their values. For example:
MOVB AR0,#5 ; AR0 = 5
MOVL *AR0,ACC ; AL −> address 0x000004
; AH −> address 0x000005
; AR0 = 5
The programmer must take the above into account when generating addresses
that are not aligned to an even boundary.
32-bit operands are stored in the following order; low order bits, 0 to 15, followed
by the high order bits, 16 to 31, on the next highest 16-bit address increment (little-endian format).
Т.е. нужно выравнивать, да?
А как это правильно делается?
Не тыкать же везде #pragma )

И вообще, какой align и для каких секций лучше всего использовать для этого DSP. Столько всего про них написано, а конкретики никакой.
Вот например
5.7 Restrictions on Using the Post-Link Optimizer
SECTIONS
{
.text > MEM,
.mydata > MEM,}
A change in the size of the .text section after optimizing causes the .bss section to shift. Ensuring that
all output data sections are aligned on a 64-word boundary removes this shifting issue. For example,
consider the following link command file:
SECTIONS
{
.text > MEM,
.mydata align = 64 > MEM,}
т.е. если использовать постлинк оптимизер - нужно по 64 выравнивать.
А если не использовать - то можно без этого??
Пока толком не понятно мне как с ним быть.....
Сам смысл выравнивания уже понятен, спасибо.


Кстати поставил везде align 64 - и SP стал частенько показывать космическое A00A:-)
Это же больше чем вся оперативка DSP :-D
Я думаю, раз это в вордах(2байта) то нужно поставить 2(будет 4байта=32бита)
А 64ворда, это явно многовато....