реклама на сайте
подробности

 
 
> Выравнивание данных в памяти(стеке), Зачем всё это?
sigmaN
сообщение May 29 2008, 14:53
Сообщение #1


I WANT TO BELIEVE
******

Группа: Свой
Сообщений: 2 617
Регистрация: 9-03-08
Пользователь №: 35 751



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


--------------------
The truth is out there...
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
sigmaN
сообщение May 29 2008, 18:42
Сообщение #2


I WANT TO BELIEVE
******

Группа: Свой
Сообщений: 2 617
Регистрация: 9-03-08
Пользователь №: 35 751



А что можно сказать о 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ворда, это явно многовато....


--------------------
The truth is out there...
Go to the top of the page
 
+Quote Post



Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 25th July 2025 - 12:41
Рейтинг@Mail.ru


Страница сгенерированна за 0.01356 секунд с 7
ELECTRONIX ©2004-2016