Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как выравнить код и данные на границу 16 байт?

Страницы: 1 2 >
Тыщ © (2008-04-08 21:54:00)
В распоряжении есть D7-D2007.
На {$ALIGN 16} ругается, для выравнивания кода вообще нет директив.
Есть ли какие-либо ухищрения, позволяющие это сделать,
или можно только подбирать каждый раз неиспользуемые код и данные для выравнивания?

Тыщ (2008-04-10 16:11:00) [1]
oxffff, Sapersky, спасибо!

tesseract (2008-04-09 20:57:00) [2]

> М.б. он научит прежде чем постить, изучить предмет.

Я имел в виду программирование в Delphi. Тема про SSE/MMX/вариации float не поднималась. В виду новых данных пост считьть как основанный на неверных вводных данных.

Sapersky (2008-04-09 19:31:00) [3]
Не так давно, в пределах месяца, наверно, эта тема обсуждалась

Ага, вот она:
http://www.delphimaster.ru/cgi-bin/forum.pl?id=1206039059&n=18

По поводу SSE - телепатор мне подсказывает, что автору вопроса следует для начала заглянуть сюда:
http://www.fastcode.dk/fastcodeproject/fastcodeproject/index.htm

Johnmen (2008-04-09 16:11:00) [4]

> tesseract © (08.04.08 22:15) [5]
> 128 битное выравнивание это к врачу. 64-битное это приемлимо,
> если понимаешь зачем процессору это нужно. Оно реально
> нужно только для 64 битных регистров.

Это тебе надо к врачу. М.б. он научит прежде чем постить, изучить предмет.

Anatoly Podgoretsky (2008-04-09 15:23:00) [5]
> Dimaxx (09.04.2008 13:16:31) [31]

Это так, но речь идет о переменных, а Интел еще и о переходах. Связано это с шириной кеша. И более того на повестке дня уже выравнивание и на 32 байта, современные процессоры имеют кеш 256 бит и есть материнские платы с 4 каналами памяти, в которых возможно загрузка кеша за одну операцию чтения вместо двух, в них выравнивание на 32 байта может дать реальный выигрыш.

Выравнивание на 16 байт нужно не столько для SSE, сколько для Extended (80 бит), это то есть во многих программах и есть во всех на Дельфи работающих с плающеей запятой, она вся основана на Extended

Dimaxx (2008-04-09 13:16:00) [6]

> Ты не знал, что SSE работает с 128-битными переменными и
> таким же выравниванием?

Не с переменными, а со 128-битными регистрами и данными. Переменные для SSE филькина грамота.

tesseract (2008-04-09 10:15:00) [7]

> Ты не знал, что SSE работает с 128-битными переменными и
> таким же выравниванием?

Я знаю, что в MMX и 170-битные значения может пользовать. Вот только какое это оношения имеет к {$ALING 16} и тому что DELPHI не поддерживает SSE, это не имеет. SSE пишуться чаще всего на ASM-е, так что смотри, как тебе нужно всё обравнять.

oxffff (2008-04-09 10:07:00) [8]

> Тыщ (09.04.08 02:41) [24]
> Германн © (09.04.08 2:29) [22]
>
> Объясняю. "начало функции кратно параграфу" означает, что
> адрес, с которого начинается функция, кратен 16 байтам.
> Но это относится к выравниванию кода, а [20] решило бы выравнивание
> данных.
>
> DrPass © (09.04.08 2:33) [23]
>
> Так все равно не будет гарантии, что record начнется на
> 16-байтной границе.
> Вот я и говорю,

Делай выравнивание на стеке сам

procedure TForm1.Button1Click(Sender: TObject);
var AlignedData:pointer;
begin
asm
mov ecx,esp;
and cl,$F0;
sub ecx,esp;
mov eax,DWORD PTR sizeof(Trect);
and al,$F0;
add eax,$10;
sub ecx,eax;
mov edx,esp;
lea esp,[esp+ecx];
mov AlignedData,esp;
mov esp,edx;
end;
end;

oxffff (2008-04-09 09:06:00) [9]
>Тыщ (08.04.08 22:03) [2]

Из документации Intel

Code Alignment
The P6 family and Pentium® processors have a cache line size of 32 bytes. Since the prefetch
buffers fetch on 16-byte boundaries, code alignment has a direct impact on prefetch buffer efficiency.
For optimal performance across the Intel Architecture family, it is recommended that:
• A loop entry label should be 16-byte aligned when it is less than 8 bytes away from that
boundary.
• A label that follows a conditional branch should not be aligned.
• A label that follows an unconditional branch or function call should be 16-byte aligned
when it is less than 8 bytes away from that boundary.

14.4.3. Data Alignment
...................
CODE OPTIMIZATION
• Align 80-bit data on a 128-bit boundary (that is, any boundary that is a multiple of 16
bytes).
• Align 128-bit SIMD floating-point data on a 128-bit boundary (that is, any boundary that is
a multiple of 16 bytes).

В итоге, тебе нужно выравнивание DATA на 128-bit boundary.
И выравнивание кода циклов и переходов согласно.

• A loop entry label should be 16-byte aligned when it is less than 8 bytes away from that
boundary.

• A label that follows an unconditional branch or function call should be 16-byte aligned
when it is less than 8 bytes away from that boundary.

P.S. Напиши перемещаемый ASM код. Далее VirtualAlloc и Copymemory + Reloc FIXING на метках.

MBo (2008-04-09 05:19:00) [10]
Не так давно, в пределах месяца, наверно, эта тема обсуждалась, приводились функции для получения указателя на блок данных с нужным выравниванием.

Германн (2008-04-09 02:51:00) [11]

> Тыщ (09.04.08 02:41) [24]
>
> Германн © (09.04.08 2:29) [22]
>
> Объясняю. "начало функции кратно параграфу" означает, что
> адрес, с которого начинается функция, кратен 16 байтам.
>

Ну и ?
А дальше то что?
Или ты надыбал функцию, а она не не работает?

Германн (2008-04-09 02:46:00) [12]

> DrPass © (09.04.08 02:33) [23]

Это уже подразумевалось в tesseract © (08.04.08 21:59) [1]

Тыщ (2008-04-09 02:41:00) [13]
Германн © (09.04.08 2:29) [22]

Объясняю. "начало функции кратно параграфу" означает, что адрес, с которого начинается функция, кратен 16 байтам.
Но это относится к выравниванию кода, а [20] решило бы выравнивание данных.

DrPass © (09.04.08 2:33) [23]

Так все равно не будет гарантии, что record начнется на 16-байтной границе.
Вот я и говорю,
[0] > "или можно только подбирать каждый раз неиспользуемые код и данные для выравнивания?"

DrPass (2008-04-09 02:33:00) [14]

> Согласись, если бы record'ы могли выравниваться на 16 байт,
> это бы решило часть моей проблемы.

Сделай 8-байтное выравнивание, и засунь между элементами "заглушки" int64. Будет тебе 128 бит.

Германн (2008-04-09 02:29:00) [15]

> Тыщ (09.04.08 02:17) [21]
>
> Германн © (09.04.08 2:11) [20]
>
> Согласись, если бы record'ы могли выравниваться на 16 байт,
> это бы решило часть моей проблемы.
>

Не соглашусь. Пока ты не объяснишь смысл фразы "если начало функции кратно параграфу".

Тыщ (2008-04-09 02:17:00) [16]
Германн © (09.04.08 2:11) [20]

Согласись, если бы record'ы могли выравниваться на 16 байт, это бы решило часть моей проблемы.

Германн (2008-04-09 02:11:00) [17]

> Тыщ (09.04.08 02:03) [19]
>
> Германн © (09.04.08 1:56) [18]
>
> Странный ты. Заладил "плохо читал", "плохо читал". Твое
> утверждение голословно.
>

Я не "странный". Я - Германн.
Из справки Д6: "The $A directive controls alignment of fields in record types."

Тыщ (2008-04-09 02:03:00) [18]
Германн © (09.04.08 1:56) [18]

Странный ты. Заладил "плохо читал", "плохо читал". Твое утверждение голословно.

Германн (2008-04-09 01:56:00) [19]

> Тыщ (09.04.08 01:43) [17]
>
> Германн © (09.04.08 1:37) [16]
>
> > Плохо читал.
>
> Ну да, конечно, любой незарегистрированный пользователь
> по умолчанию ни черта не знает и плохо читал.

И всё равно - плохо читал. Примите и прочь.

Тыщ (2008-04-09 01:43:00) [20]
Германн © (09.04.08 1:37) [16]

> Плохо читал.

Ну да, конечно, любой незарегистрированный пользователь по умолчанию ни черта не знает и плохо читал.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »