Экстремальный разгон процессора
для наглядности выделенная полужирным шрифтом)
00000000: 33C9 XOR ECX, ECX ; (начальное значение ECX == 87h)
00000002: 33D2 XOR EDX, EDX
00000004: 3BC2 CMP EAX, EDX
Листинг 1 инструкция XOR ECX, ECX ( для наглядности выделенная полужирным шрифтом) вызвала нарушение доступа, обратившись к памяти по адресу C23BD2BAh
Ничего не напоминает?! Постойте-постойте! Но ведь… адрес, вызывавший исключение, содержит в себе байты инструкции CMP EAX, EDX и частично XOR EDX, EDX, а если записать опкоды этих команд и сложить их со значением регистра ECX, получится: C23BD233h + 87h == C23BD2BAh, то есть тот самый непонятно откуда взявшийся адрес исключения (ну это раньше он был непонятным, теперь же все стало ясно). Записав инструкцию XOR ECX,ECX в двоичном виде (00011 0011 1100 100) и изменив всего один бит, превращающий C9h в 89h, мы получим… мы получим вот что!
00000000: 338933D23BC2 XOR ECX,[ECX][0C23BD233]
Листинг 2 предыдущий фрагмент кода, в котором искажен всего один бит в инструкции XOR (C9h à 89h)
Оторвать мне хвост!!! Вот как оказывается в _действительности_ выглядела машинная команда, возбудившая исключение и вызвавшая сбой. Сразу видно, что АЛУ тут совершенно не причем. Процессор функционировал в общем-то исправно. Весь вопрос в том, почему Доктор Ватсон показал не "XOR ECX, [ECX][0C23BD233]", а "XOR ECX, ECX"?! Да потому, что искажение бита произошло в кэш-памяти первого уровня, а при составлении отчета Доктор Ватсон возвратил неискаженное содержимое кэш-памяти второго уровня!!! Откуда у меня такая уверенность, что все именно так и происходило? Так ведь процессор использует раздельную кэш память первого уровня для кода и данных, поэтому, прочитать истинное содержимое инструкции, вызывавшей сбой, Доктор Ватсон просто физически не в состоянии и это можно установить только косвенным путем.
Так, значит, главный виновник — это кэш? Дальнейшие эксперименты показали, что все обстоит именно так.Причем, сбои происходят в кэш памяти обоих уровней и вероятность их возникновения напрямую связана с интенсивностью кэш-промахов (т. е когда приложение обновляет большое количества кода/данных). С другой стороны, длительное хранение кода/данных без их модификации, создает другую угрозу — угрозу "загнивания" байт, особенно часто случающуюся при некачественном питании.
Изменить тактовую частоту кэш-модуля невозможно, но… если пораскинуть хвостом, можно найти довольно простое и элегантное решение.
Forekc.ru
Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий