Подскажите как можно протестировать кэш процессора или
URL с примером

Из когда-то прочитанного в интеловских мануалах я не припомню такого, чтоб камень предоставлял какие-то возможности прямого тестирования кеша. Есть WBINVD/INVD/INVLPG объявляющие кеш недействительным. В новых камнях есть PREFETCH, позволяющая загружать кеш и CLFLUSH сбрасывающая содержимое кеша. Чем CLFLUSH отличается от INVLPG я уже не помню. Есть RDPMC позволяющая узнать как часто загружается кеш и наверное еще че-нить про кеш с её помощью узнать можно. Есть CPUID, позволяющая вытянуть кое-какую инфу про кеш (см аттач). Возможно еще что-то есть и возможно из всего этого и можно слепить какой-то тестер кеша. В общем ищи на интеловский сайт и сливай их мануалы по камням. Если у тя че-то получится, интересно было бы посмотреть.


_408078008__cpuid.zip

Вопрос скорее к Four-F Ж:)
Слепил драйвер, для отключения и тестирования кэш, чтобы добраться до привилегированных команд под w2k поставил команду CPUID и .... заработал BSOD :(( Тоже происходит при пресылке из/в регистры tr5, tr4... это, что получается я не в 0-ом кольце защиты процессора ? Понимаю, что эти регистры устарели (от 486), но зачем же так "бить по рукам" Да и в user-mode CPUID работает, а в режиме ядра нет, может есть объяснение ?

[ s_work: Да и в user-mode CPUID работает, а в режиме ядра нет, может есть объяснение ? ]

CPUID одинаково хорошо работает и в user-mode и в kernel-mode. А объяснение очень простое: CPUID затирает содержимое ebx, который ты перед этим не сохранил. Угадал? :-)

По поводу tr5, tr4. Мне очень стыдно, но я не знаю, что это такое. Покажи кусок кода.

Trx - это тестовые регистры. Предпологалось использовать их для тестирования проца. Но похоже что в интел от них отказались. Или просто не документировали, чтобы потом проблем с обратной совместимостью не было. Но даже изначально интел заявляла, что информация которая в них находится интерпретируется в зависимости от модели проца.

На счет CPUID Вы абсолютно правы, некоторые исходники, работающие под Вынь 98 не работают в 2000 и мне приходилось в процедуре окна ставить pushad, чтобы не морочиться (как оказалось, в Вынь 2000 нельзя менять ebx), и так в будущих версиях Виндов будет работать, вдруг опять чё поменяют :)
Регстры Trx пусть остаются на совести Intel. Только мне надо написать программу тестирования кэша у проца. У меня на работе Celeron 1.8, а в институте - древние пни и как в этом случае вывернуться с таким раскладом ? Если эти регистры интерпретируется в зависимости от модели :=( Придётся изобретать...

[ s_work: ...как оказалось, в Вынь 2000 нельзя менять ebx... ]

И не только в 2000, а вообще во всех Вынях. Это камень преткновения практически всех, кто на асме под вынь кодить начинает. Система гарантирует, что она сохраняет только регистры esi, edi, ebp и ebx. И ты должен поступать точно так же, т.к. система ожидает, что esi, edi, ebp и ebx останутся неизменными после возвращения управления назад в систему.

s_work
А какую конкретно информацию необходимо получить про кеш?

Получить информацию про кэш - не проблема, а проблема его протестировать. В доке по 486 проц написано как это сделать, но там используются TRx регистры. Если Intel эти регистры интерпретирует по разному, то соотвественно... в Celeron под вынь 2000 - BSOD.
Кэш отключается просто (биты CD,NW в CR0) нашёл команды: PREFETCHh—Prefetch Data Into Caches (спасибо Four-F), но MASM их не переваривает выдает: error A2085: instruction or register not accepted in current CPU mode, хотя стоит в начале .686p Это я тоже обошел, втавив "db 0fh, 18h, 0с8h" Проблема как раз в логике работы, не знаю алгоритма тестирования P4 и подобных ему урезанных Celeron - ов. Может у кого есть опыт в составлении подобной проги ?

s_work
Я имел ввиду какую информацию должна выдать программа после проведения тестирования?

Очень просто: какой кэш тестировали (L1,L2) и результат "Ok" или "не Ok"

s_work
Ладно поставим вопрос по другому: в каком случае программа должно сказать "ок" а в каких "не ок"? На основе какой информации она принимает это решение? Какая вообще информация нужна для принятия такого решения?

Если кэш - память то при записи в туда одного значения, считывать должны тоже самое (Ок!), если нет, то (не Ок!). В свете последних данных тестировать можно L3 в даже в celeron, но считывать от туда можно очевидно не то, что записали, т.к. celeron не что иное, как отбраковка от pentium :))

s_work
Зачем писать тестирующую программу которая всегда говорит "Ок"? Если с кешем случится такая неполадка, то до запуска твоей программы дело даже не дойдет. А в целеронах неисправные блоки кеша отключаются на аппаратном уровне, и доступа к ним получить нельзя. Разве что только через JTAG.

В этом вся "засада" :( надо показать алгоритм тестирования.