В чем смысл выравнивания данных для процессора ? То есть почему он не может(или не хочет читать данные которые не выровняные). А то интересно зачем выравнивать для некоторых WINAPI данные.
o Производительность. Чем короче адрес, тем выше скорость обращения. o Защита. Не выравненные данные могут рассматриваться как рандомные, для этого введена защита как хардварная(#AC), так и програмная(#STATUS_DATATYPE_MISALIGNMENT для NT).
То есть типа проще набрать его на шине ? Если я правильно понял то: Есть комп 32х разрядный, когда читаем один байт то комп читает 4 байта в любом случаи? Код (Text): mov al,byte ptr [eax] ; комп. прочитает из памяти 1 или 4 байта ?..
XshStasX Каждый элемент шины отвечающий за адресацию одного бита вносит задержки при переключениях. Вот чем короче адрес, тем меньше элементов вовлекается в адресацию и тем выше производительность.
XshStasX Зависит от типа памяти и протоколов. Например может адресаваться регистр(в рам) за один синхротакт, либо на шине формироваться адрес частями. В придачу зависит от размера регистра и память нынче динамическая. Этих нюансов я не знаю. Смотрите в даташитах.
Не пойму о каких-таких процессорах вы тут толкуете Современные x86 работают с обычной WB-памятью через кэш и соотв-но читают\пишут данные из\в ОЗУ линейками\секторами по 64 или 128 байт (а не бит !) по выравненным адресам. Обмен данными между кэшем и регистрами (точнее буферами чтения\записи) ес-но идет в соотв-ии с размером операнда, т.е. при mov al,mem пересылается только 1 байт, а не 4 и не 8. И требования к выравниванию в современных компах стали менее критичными, чем в древних 486\586 - в интеловских камнях существенная задержка возникает только при чтении операнда, пересекающего 64-байтную границу (т.е. чтение из двух линеек кэша), у АМД - тоже, плюс доп.задержка в 1 такт при пересечении 8-байтной границы. Однако несмотря на эти "поблажки", тем не менеее рекумендуется придерживаться устоявшихся правил выравнивания адресов на размер операнда (при этом и пересечения границ кэш-линеек не будет) PS: Помимо скорости, выравнивание влияет и на атомарность чтения\записи при многопоточном доступе, т.к. при пересечении кэш-линейки данные читаются\пишутся не атомарно - в два приема вместо одного
Эту тему создавал что понять почему NtQueryInformationFile не работает если ей передать не выровняные данные. Думал что это какая то особенно железа...
А как насчет некэшируемой памяти? Есть мнение что все то же самое. Тут попался интеловский талмуд по первому пеньку от 95 года. Там четко указано, что в момент включения проц читает память по адресу FFFFFFC0 хотя по сути ему нужна инструкция по FFFFFFF0.Понятно, что в данном случае кэш отключен.
medstrax1 Не то же самое, просто размер шины данных уже давным давно сотавляет 64 бита = 8 байт и соотв-но минимальный чанк обмена с ОЗУ = 8 байтам. Если нужно записать меньше 8-ми, то это (видимо) указывается в управляющем слове\заголовке пакета
Приведу цитату целиком When the CPU is released from reset, it will load the first instruction from the reset vector, 0xFFFF_FFF0 physical address. This address will be mapped to a Firmware Hub (FWH) on the Low Pin Count (LPC) Interface or a Serial Peripheral Interface (SPI) flash or on a PCI bus depending on the system straps option that is sampled at power up. If you have tried to probe the LPC bus or SPI interface to look for the first fetch of BIOS code from the firmware location, you will find that instead of address 0xFFFF_FFF0h, you will find 0xFFFF_FFC0h. This is due to the processor initiating a code fetch to read an entire cache line (64B) size. This is not a problem as the processor prefetches in cache line granularity. Понятно, что сразу после RESET# кэширование выключено, однако проц тем не менее выбирает код порциями равными размеру линейки кэша. Хотя физически за один цикл шины все равно читается только 8 байт.
Вообще-то тут речь идет о загрузке кода, а не данных. Фетч кода в процессор всегда осущ-ся выравненными блоками по 16\32\64 байта
Ясно, т.е. когда речь идет о данных, то на размер фактически считываемого блока памяти влияет кэширование. Когда речь идет о коде, эта зависимость отсутствует.
Ес-но, т.к. размер считываемых данных известен заранее из формата команды, а при загрузке кода ничего заранее не известно - и размер команд может варьироваться от 1 до аж 15 байт с учетом префиксов, и декодер расчитан на обработку не одной, а до 3-4 команд за такт - соотв-но чем шире "входное окно", тем лучше
