если это спек по женщинам - то все верно

Покурил эту информацию

Всё равно не понятно почему без выравнивания процессор будет неэфективно читать память.

Допустим у нас есть массив 32 байта. Мы его положили по адресу 1. Когда обращаемся к адресу 4, то все 32 байта последовательно выгружаются в кэш начиная с адреса 4. Ну и всё

Зачем выравнивать и ложить этот массив по адресу 0,32,64 и т.п. если и в теории и без выравнивания всё должно работать быстро?

"положить по адресу 4"
Это разве не выровнять на 32?

Че то я теперь запутался. Я думал надо ложить по адресу, кратному размеру

Вот сгенерил тут что -то:
fstcw word [cw]
xor word [cw], 0000001100000000b
fldcw word [cw]
------------------------
cw dw ?,0
получится ли вот так переключить fpu на одинарную точность?

Напутал, всё, Читается же по 32 бита а это 4 байта

Исправил на адрес 1

Это же получается уже не то?

или то

я запутался

Давай по-новой.

byte - выравнивание на 1 байт - 8 бит
word - выравнивание на 2 байта - выравнивание на 4 байт - 16 бит
dword - выравнивание на 4 байта - 32 бит
...

Примеры с учётом, что размер кэшлайна 32 байт:
Переменная типа word - 2 байта, массив 512 - (512*2). Нужно выравнивать адрес на начало, и последующие адреса на 4 байта, почему:

При получении данных типа word - процессор будет получать данные из кэшлайна, делив на 4 байт без остатка (т.к размер кэшлайна кратен 4 байт).
Итак, если выравнивать на 4 байта, то процессор спокойно считает часть из памяти.

Если выравнивание будет пересекать границу 4 байт, то процессору нужно будет считать первую часть, вторую, а потом отбросить ненужные байты, что займёт больше времени у процессора

Другой пример - dword - массив 512 - (512*4). Выравнивать все адреса на начало, и последующие адреса на 4 байта. При получении данных процесора будет получать данные из кэшлайна, делив на 4 байт без остатка, тем самым получая сразу нужную часть.

Ещё один пример - byte (char) - массив 512 - (512*1 = 512, но 512/4, значит размер позволяет сделать выравнивание адресов на 4 байта, и процессор спокойно сможет взять нужную часть из кэшлайна).

И так далее...
В том примере с форума - речь только о dword, из-за чего ты запутался, думая, что нужно выравнивать всё на 4 байта. Моя вина. Выравнивать на 4 байта нужно только тогда, когда размер данных и кэшлайна кратен 4, дабы процессор смог сразу считать адрес из памяти, делив его на 4 без остатка. При выравнивании на 4 при размере, не кратном на 4, больше размера кэшлайна - данные попадут в соседний кэшлайн, и оставшиеся данные процессор считает как те, которые не кратны на 4, но эти потери заметны будут не сильно. При выравнивании на 4 при размере, не кратном на 4, меньше размера кэшлайна - обьект попадёт в один кэшлайн, и так же остальные данные процессор считает как те, которые были бы не кратны 4

Всё, думаю, что после этого должно всё проясниться.

И в твоём примере: массив 32 байт при выравнивании на 1 байт ничего не даст процессору.
Адрес начала будет выравнен на 1 байт, из-за чего процессору придётся *брать первую часть, вторую, отбрасывать ненужное* что неэффективно:
0xFFFF01 (выравнивание на 1)
0xFFFF04 (выравнивание на 4)

Вот так будет браться по выравниванию 1. И что бы избежать вот этого возвращения на 3 байта, нужно сразу выровнять на 4 байта, дабы он считал сразу с 4 байт, и не возвращался с 4 байт на 3, дабы прочитать потерянные адреса, выровненные на 1 байт

а зачем тебе это? чем тебе расширенная точность не устроила?

напомните, как происходит перевод строки,  а то забыл? 10 и \n нет ведь.
https://hastebin.com/oqugomuzed.asm

да хочу мантиссу 24 бита и порядок 7 чтобы в dword вместилось и так потом переводить в dec проще будет по идее, просто у меня винда на 32 бита и компилятор ругается на qword не очень удобно

О прикольно, или можно же вот так решить:
mov eax, result
FBSTP [eax]
тогда компилятор не ругается на размер result!
а размер просто будет такой например:
result db 17 dup ? типа резерв под 16 цифр и пакет с положением точки или не знаю пока какой длинны он bcd выгрузит

Интересно bcd будет упакован или нет, пора запускать дебаггер походу, страшно но надо! :))

кстати возникла мысль если я сейчас запущу программу и поменяю флаги сопроцессора, надо ведь назад вернуть точность а то виндоуз потом может с ума сойти?

Даже если бы и не было кэша, физическая память sdram, сама по себе тоже отдает данные блоками, много конденсаторов за такт разряжается. Выравнивание и с этой точки зрения удобно -выровненные дворды и кворды, попадают в один и тот же блок конденсаторов.