exst Не знаю такого, можно ссылочку. Я знаю еще про PSE-36 режим, где на адрес приходится 36 бит. Он недоступен в 64 битном режиме. Состоит из PDE и Page Offset. Страницы размером в 4 мегабайта. Всего в PDE 1024 элемента. Позволяет адресоваться в 64 гигабайта виртуального адресного пространства.
AMDшная документация): http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf Я читал про PSE36 режим. Там вроде сразу все 64 ГБ недоступны. Там какой-то свой хитрый механизм.
exst Угу , не посмотрел у AMD. У интела не нашел такого. Амд извратились, как обычно Мой AMD Turion 64 X2 Mobile не поддерживает такое.
Я полагаю, что поддержка включена в новую Барселону. Ни Athlon X2 4400, ни Intel E8500 не держат) Проверял) Оффтоп: Если по хорошему... Весь Х86 - это такая помойка... Совместимость со старьем до добра не доведет...
exst Поправлюсь. Во первых Поддерживают эти процы AMD K10 family. А следовательно это Phenom II, Phenom X4, Phenom X3 ну и конечно же Operton (он уж точно поддерживает. Плюс по ссылке http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6587615 видно что солярка уже в курсе дела. Да и еще, удалось узнать сведения: IA64 (Itanium) поддерживает 4gb страницы Так что интел не в проигравших , в какой-то мере)
вот мои наработки по части перехода в 64 битный режим. просто переходим в long mode и выводим сообщение, без прерываний и установки TSS. FASM Код (Text): format MZ entry ALL_CODE:start STACK_BASE_ADDRESS equ 08000h PM_CODE_BASE_ADDRESS equ 010000h PM_CODE_SIZE equ PM_CODE_END - PM_CODE_BASE_ADDRESS ;LM_CODE_BASE_ADDRESS equ 100000h ;LM_CODE_SIZE equ LM_CODE_END - LM_CODE_BASE_ADDRESS CODE_SELEKTOR equ 8h DATA_SELEKTOR equ 10h CODE64_SELEKTOR equ 18h PML4_addr equ 100000h PDPE_addr equ 101000h PDE_addr equ 102000h heap 0 segment ALL_CODE use16 start: mov AX,3 int 10h in AL,92h or AL,2 out 92h,AL xor EAX,EAX mov AX,ALL_CODE shl EAX,4 add EAX, PROTECTED_MODE_ENTRY_POINT mov [CS:ENTRY_OFF],EAX xor EAX,EAX mov AX,ALL_CODE shl EAX,4 add EAX, GDT mov dword [CS:GDTR+2],EAX lgdtfword [CS:GDTR] cli in AL,70h or AL,80h out 70h,AL mov EAX,CR0 or AL,1 mov CR0,EAX db 66h db 0EAh ENTRY_OFF dd PROTECTED_MODE_ENTRY_POINT dw CODE_SELEKTOR align 8 GDT: NULL_descr db 8 dup(0) CODE32_descr db 0FFh,0FFh,00h,00h,00h,10011010b,11001111b,00h DATA_descr db 0FFh,0FFh,00h,00h,00h,10010010b,11001111b,00h CODE64_descr db 00h, 00h,00h,00h, 00h,10011000b,00100000b,00h GDT_size equ $-GDT label GDTR fword dw GDT_size-1 dd ? use32 PROTECTED_MODE_ENTRY_POINT: mov ax, DATA_SELEKTOR mov ds, ax mov es, ax mov ss, ax mov esp, STACK_BASE_ADDRESS call delta delta: pop ebx add ebx, PM_CODE_START-delta mov esi, ebx mov edi, PM_CODE_BASE_ADDRESS mov ecx, PM_CODE_SIZE rep movsb mov eax,PM_CODE_BASE_ADDRESS jmp eax PM_CODE_START: ORG PM_CODE_BASE_ADDRESS mov esi, message1 mov edi, 0B8000h mov ecx, mess1end-message1 rep movsb mov eax, cr4 bts eax, 5 ; PAE = 1 mov cr4, eax mov dword [PDE_addr], 010000011b ; PS or Present or Write mov dword [PDE_addr+4], 0 mov dword [PDPE_addr], PDE_addr or 3 ; Present or Write mov dword [PDPE_addr+4], 0 mov dword [PML4_addr], PDPE_addr or 3 ; Present or Write mov dword [PML4_addr+4], 0 mov eax, PML4_addr mov cr3, eax mov ecx, 0xC0000080 ; EFER rdmsr bts eax,8 ; EFER.LME = 1 wrmsr mov eax, cr0 bts eax, 31 ; PG = 1 mov cr0, eax jmp CODE64_SELEKTOR:LM_CODE_START use64 LM_CODE_START: mov rsi, message2 mov rdi, 0B80A0h mov rcx, mess2end-message2 rep movsb jmp $ message1 db "W5e5 5i5n5 5p5r5o5t5e5c5t5e5d5 5m5o5d5e5!5" mess1end: message2 db "W5e5 5i5n5 5l5o5n5g5 5m5o5d5e5!5" mess2end: PM_CODE_END: конечно, довольно таки черезжопный подход, но тем не менее
насчёт VirtualBox 2.1.2 и PAE опасения подтвердились. Программа, которая работала на Bochs и на реальном процессоре не работает на VirtualBox (страница 0xB8000 я мэпил на 4 разных виртуальных адреса, один адрес был 48 битный). В общем, не рекомендую.
в х64 команда push gs ложит в стек 32 или 64 бита. просто у intel написано по умолчанию 32 битный операнд