Какова логика выравнивания полей в записи ?

← →
Skier © (2003-05-12 16:14) [0]

Господа, помогите в таком вот вопросе (читал хелп, но там мало, в
общем я не разобрался...) :

Как происходит, т.е. какова логика выравнивания полей в записи
при {$A+}

Если можно объясните на пальцах.

Пальцы такие :

1) TSomeRec = record
srF1 : Extended;
srF2 : Extended;
srF3 : Char;
end; //TSomeRec

2) TSomeRec2 = record
srF3 : Char;
srF1 : Extended;
srF2 : Extended;
end; //TSomeRec

SizeOf(TSomeRec) = 32 байта
SizeOf(TSomeRec2) = 40 байт

Как всё это дело вычисляется, т.е. какая(ов) логика (алгоритм) ?

Памажите !

← →
Anatoly Podgoretsky © (2003-05-12 16:33) [1]

Ну со вторым понятно, выравнял Extended на границу 8 байт: 8+16+16
А вот первую наверно 16+12+4 - тоже 8 байт для Extended и 4 для остальных

Правил выравнивания нигде не видел. В Д6 и Д7 возможности выравнивания еще выше, не знаю сделали в Д7 выравнивание на выравнивания на границу 16 байт или нет, а оно очень нужно для Р4

← →
Игорь Шевченко © (2003-05-12 16:51) [2]

Object Pascal Language Guide внимательно читаем...

"Record type field alignment is described in the Object Pascal Language Guide."

← →
Skier © (2003-05-12 16:55) [3]

>Игорь Шевченко
Я же говорю, что читал, смотрим вопрос... :)
Не мог бы на примере объяснить ?

← →
Johnmen © (2003-05-12 17:16) [4]

1) 10->2*8 + 10->2*8 = 32 из которых 1 байт под char
2) 1->8 + 10->2*8 + 10->2*8 = 40

← →
McSimm © (2003-05-12 17:20) [5]

1)
srF1 : Extended; - alignment 8, size 10
srF2 : Extended; - alignment 8, size 10
srF3 : Char; - alignment 1, size 1
Finally, the compiler rounds the total size of the record upward to the byte boundary specified by the largest alignment of any of the fields.

Получается расклад по смещениям:
srF1: 0-9
unused: 10-15
srF2: 16-26
srF3: 27
unused: 28-31
-------------------------------------
2)
srF3: 0
unused: 1-7
srF1: 8-18
unused: 19-23
srF2: 24-34
unused: 35-39

← →
MBo © (2003-05-12 17:21) [6]

{$A+}
procedure TForm1.Button1Click(Sender: TObject);
type
TSomeRec = record
srF1 : Extended;
srF2 : Extended;
srF3 : Char;
end; //TSomeRec

TSomeRec2 = record
srF3 : Char;
srF1 : Extended;
srF2 : Extended;
end; //TSomeRec
var a:TSomeRec;
b:TSomeRec2;
BEGIN
Memo1.Lines.Add(IntToStr(SizeOf(a)));
Memo1.Lines.Add(IntToStr(Integer(@a.srF1)-Integer(@a)));
Memo1.Lines.Add(IntToStr(Integer(@a.srF2)-Integer(@a)));
Memo1.Lines.Add(IntToStr(Integer(@a.srF3)-Integer(@a)));
Memo1.Lines.Add("");

Memo1.Lines.Add(IntToStr(SizeOf(b)));
Memo1.Lines.Add(IntToStr(Integer(@b.srF3)-Integer(@b)));
Memo1.Lines.Add(IntToStr(Integer(@b.srF1)-Integer(@b)));
Memo1.Lines.Add(IntToStr(Integer(@b.srF2)-Integer(@b)));
end;

32
0
16
26

40
0
8
24

← →
Skier © (2003-05-12 17:28) [7]

>Johnmen
Я так понял что alignment из таблицы type alignment masks (Object Pascal Reference), это есть множитель 8-ки ?
И кстати почему именно 8 байт ?
Ведь слово это 2 байта, а двойное слово - 4 байта

← →
Anatoly Podgoretsky © (2003-05-12 17:34) [8]

Там есть есть одна особенность, связанная с математическим соопроцессором, ему требуется что бы операнд был выровнен по границе 8 байт.

← →
Johnmen © (2003-05-12 17:35) [9]

>Skier © (12.05.03 17:28)

Насколько помню, там и написано quad-word :) Т.е. = 8

← →
Skier © (2003-05-12 17:36) [10]

>McSimm © (12.05.03 17:20)

Судя по хелпу, (alignment - 2 for Real48 and Extended ) не так :
srF1 : Extended; - alignment 2, size 10
srF2 : Extended; - alignment 2, size 10
srF3 : Char; - alignment 1, size 1

← →
Skier © (2003-05-12 17:37) [11]

>Johnmen © (12.05.03 17:35)

Из хелпа :

By default, the values in a structured type are aligned on word or double-word boundaries for faster access.

← →
McSimm © (2003-05-12 17:49) [12]

>Судя по хелпу, (alignment - 2 for Real48 and Extended ) не так :

Цитата из LG:
Alignment 2 for Real48, 4 for Single, 8 for Double and Extended

← →
Skier © (2003-05-12 17:52) [13]

>McSimm © (12.05.03 17:49)
Shit. Я совсем запутался...
А вот моя цитата из LG (книжка перед глазами - D5 Enterprise).
Цитирую :
Alignment 2 for Real48 and Extended, 4 for all other real types

И что нам с этим делать ? :)

← →
Johnmen © (2003-05-12 17:53) [14]

>Skier © (12.05.03 17:37)

Это старый-старый хелп... :)

In the {$A8} or {$A+} state, fields in record types that are declared without the packed modifier and fields in class structures are aligned on quad-word boundaries.

← →
Skier © (2003-05-12 18:00) [15]

>Johnmen © (12.05.03 17:53)

> Это старый-старый хелп... :)

Не знаю, не знаю...но у меня стоит лицензионная D5 Enterprise (и, соответственно, хелп от неё), которая стоила много баксиков.

Караул ! Кому же верить-то ?! :)
Судя по тому что выводиться в SizeOf(...), то
похожи на правду посты
McSimm © (12.05.03 17:20) и Johnmen © (12.05.03 17:53)

Чаво делать-то ? :)

← →
Anatoly Podgoretsky © (2003-05-12 18:07) [16]

В Д6 сказано
Real type 2 for Real48, 4 for Single, 8 for Double and Extended
Возможно в Д5 неверный хелп, очень часто он отстает от действительности

← →
Skier © (2003-05-12 18:10) [17]

>Anatoly Podgoretsky © (12.05.03 18:07)
Да, очень похоже...

← →
Anatoly Podgoretsky © (2003-05-12 18:16) [18]

Мне кажется да и размеры показывают, что выравнивание на границу 8 байт. А хелп исаравляется иногда только через две версии, хотя у меня установлен самый последний для Д5

← →
Skier © (2003-05-14 11:57) [19]

>McSimm © (12.05.03 17:20)
1) Вычислить расклад по смещениям, зная адреса полей - задача
тривиальная. Но вопрос-то как раз в том как эти адреса и размер
записи вычисляются
2)

> srF1: 0-9
> unused: 10-15
> srF2: 16-26
> srF3: 27
> unused: 28-31

IMHO, вот так правильней :

unused: 0-5
srF1: 6-15
srF2: 16-26
unused: 27-30
srF3: 31

>IMHO, вот так правильней
С чего бы это????
поле должно начинаться по "ровному" адресу
Тест (12.05.03 17:21) видел?

>Skier © (14.05.03 11:57)
Вообще-то я в своем посте ошибки заметил(я делал без Делфи, не проверяя), но не стал их исправлять, т.к. MBo это сделал.

Однако то что ты пишешь мне не понятно. Смотри:

srF1: Exnended;
Выравнивание на 8, т.е. смещение будет 0.
Длина 10 байт, поэтому расклад 0-9

srF2: Exnended;
Выравнивание на 8, т.е. от позиции 10 до 15 пропуск, смещение будет 16.
Длина 10 байт, поэтому расклад 16-25

srF3: Char;
Выравнивание на 1, т.е. размещается в 26
Размер 1, значит расклад 26-26

Record выравнивается по размеру, чтобы быть кратным максимальному значению выравнивания своих членов, т.е 8.
Поэтому байты с 27 до 31 будут принадлежать record, но не использоваться.

Имеем:
srF1: 0-9
unused: 10-15
srF2: 16-25
srF3: 26
unused: 27-31

>26 - это "ровный" адрес ?
Для Char - да. А Extended на 8 выровнены.

>McSimm & MBo
Вроде проблема для меня проясняется....
Господа, главное в выравнивании это то что поле (его адрес) должно начинаться по "ровному" (в зависимости от типа поля) адресу ? Так ?

Так, ровный именно для первой составляющей

Да, так обеспечивается наиболее быстрый доступ.
always aligned for optimal access. In the {$A+} state, execution will be faster.

Всё. Понял.
Всем кто принимал участие в разъяснении выражаю
глубокое решпектование !

Какова логика выравнивания полей в записи ? Найти похожие ветки