Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.191.5.239] |
|
Сообщ.
#1
,
|
|
|
org 0x100 ; Enable SSE mov eax,cr0 and al,0xFB ; clear coprocessor emulation CR0.EM (bit 2) or al,0x2 ; set coprocessor monitoring CR0.MP (bit 1) mov cr0,eax mov eax,cr4 or eax,0x40600 ; set CR4.OSFXSR (bit 9), CR4.OSXMMEXCPT (bit 10) and CR4.OSXSAVE (bit 18) mov cr4,eax ; Enable AVX xor ecx,ecx xgetbv ; load XCR0 register or al,7 ; set AVX, SSE, x87 bits xsetbv ; save back to XCR0 ; Test SSE xorps xmm0,xmm0 xorps xmm1,xmm1 addss xmm0,xmm1 ; Test AVX vzeroupper vxorps xmm0,xmm0,xmm0 vxorps xmm1,xmm1,xmm1 vaddps xmm2,xmm0,xmm1 ret Доходит до vzeroupper и виснет. Что ему ещё не хватает? Инфа: https://wiki.osdev.org/SSE Добавлено Даже добавляю код из Intel SDM для проверки поддержки AVX, выдаёт, что всё ок. mov eax, 1 cpuid and ecx, 018000000H cmp ecx, 018000000H; check both OSXSAVE and AVX feature flags jne not_supported ; processor supports AVX instructions and XGETBV is enabled by OS mov ecx, 0; specify 0 for XCR0 register xgetbv ; result in EDX:EAX and eax, 06H cmp eax, 06H; check OS has enabled both XMM and YMM state support jne not_supported mov eax, 1 jmp done not_supported: mov eax, 0 done: |
Сообщ.
#2
,
|
|
|
Попробуй перехватить исключения. Если они возникают, скорее всего вмварь глючит с виртуализацией AVX.
|
Сообщ.
#3
,
|
|
|
Короче, выяснилось, что в RMode и в V86 AVX не пашет, надо переходить в PMode (в 16 битном тоже должно работать).
https://software.intel.com/en-us/forums/int...ns/topic/297055 Добавлено Всё верно. Заменил or al,0x2 на or al,0x3, добавил cli и в конец: mov eax,cr0 and al,not 1 mov cr0,eax |
Сообщ.
#4
,
|
|
|
При нежелании работать всегда в PMode, можно даже переключаться на время работы с AVX в PMode, а после обратно в RMode.
При этом, если не писать в сегментные регистры, можно спокойно работать с памятью, как будто мы находимся в RMode. Не надо никаких таблиц грузить (GDT и пр) Я сейчас померил скорость переключения RM-PM-RM в VMware, у меня получилось порядка полумиллиона пар переключений в секунду. Довольно-таки неплохая скорость (в реале наверняка будет больше) |
Сообщ.
#5
,
|
|
|
Хм. Т.е. их тупо не пропускает декодер, останавливаясь на начальном этапе декодирования? Забавно.
|
Сообщ.
#6
,
|
|
|
Qraizer, не очень понятен смысл сего запрета.
В аттачах выдержка из мана (том 2A, раздел 2.4, страницы 60 и далее). Ну и: "VEX-encoded GPR instructions are not supported in real and virtual 8086 modes." (стр. 69) Прикреплённый файлno_vex_in_real_and_v86.zip (1,34 Мбайт, скачиваний: 176) |
Сообщ.
#7
,
|
|
|
Это не запрет. Так случайно вышло. Примерно как неправильное поведение механизма сегментной трансляции логических адресов в линейные при смене реального/защищённого режимов без последующей перезагрузки сегментных регистров. Ну, видит вот декодер неправильный объектный код для LDS, а микрокод для RM/VM никто не проапдейтил. Получите exception #6. Вероятно, интеловцы решили не фиксать VEX, т.к. реальный и виртуальный режимы нынче крайне маловостребованы.
|
Сообщ.
#8
,
|
|
|
Цитата Qraizer @ 16-битный PM тоже маловостребован, тем не менее он поддерживает VEX.Вероятно, интеловцы решили не фиксать VEX, т.к. реальный и виртуальный режимы нынче крайне маловостребованы. Про сегментные регистры можно поверить, что это просто баг, а здесь – лично мне не верится. ИМХО, это сделано намеренно... только какова причина? Должна же она быть! Есть более новые, чем AVX, расширения (без VEX), которые, судя по описанию (специально сейчас посмотрел SDM), прекрасно работают в RM: MOVBE, PCLMULQDQ, ADX, RDRAND, SHA, MPX, даже TSX (в т.ч. RTM, хотя, казалось бы, зачем это в RM вообще?) |
Сообщ.
#9
,
|
|
|
Кстати (вопрос не в тему), кто-нибудь знает, как расшифровывается аббревиатура BV (XGETBV, XSETBV, XSTATE_BV...)?
Мне прям любопытно, почему такое сокращение. Может, это Bit Values или что-нибудь такое? |
Сообщ.
#10
,
|
|
|
Думаю, был бы баг в PM16, тоже не стали бы фиксать, его там просто изначально не было. Микрокод – он такой... фиксать его непросто, а потом ещё распространять через патчи...
Скорее BlockValidate. Хотя вариантов масса. BitmapVector... почему нет. |