64 bitowe rejestry w 32 bitowym programie

Dawniej były 16 bitowe programy i mogłem w nich obliczać na 32 bitowych,
były nawet takie wstawki, funkcje 32 bitowe do obróbki dib w 16 bitowych bibliotekach Borlanda.

A teraz są 64 bitowe rejestry i jest ich aż 16,
więc chodzi mi o to czy też można używać 64 bitowych operacji z procesu 32 bitowego?

Wtedy można byłoby robić w zasadzie 64-bitowe programy, w środowisku 32-bit (w Windows 32).

Takie aplikacji byłby przecież szybsze od full 64 !

Nie marnowałby czasu na przewalanie zawsze podwójnych bloków pamięci!
Po co transferować zawsze aż 64 bitowe kęsy na stos, wszystkie wskaźniki również 64, czy nawet 128 w obiektowym...
przecież to istotnie spowalnia działanie.

Nie da się.

Da się, do tego jest wstawka "call 33h:nazwa_funkcji_x64" i stare dobre retf. Działa pod windowsem 7.
nazwa_funkcji_x64 jest labelem funkcji 64-bitowej, powinna rezydować pod stosownym adresem, podzielnym przez 16.
Retf kończy funkcję, wraca do 32-bitowego trybu.

Da się, do tego jest wstawka
To jest odpowiedź na inne pytanie.
Windows x64 musi umieć przełączać tryby, jeśli mają działać programy 32- i 64-bitowe jednocześnie.
Dlatego całkiem możliwe, że da się wykorzystać ten (nieudokumentowany) mechanizm do przełączenia trybu procesora.

Nie o to było pytanie.

Pytający zwraca uwagę, że w trybie 16-bitowym można bezpośrednio odwoływać się do 32-bitowych rejestrów (o ile procesor jest 32-bitowy), i żywi nadzieję, że podobnie da się w 32-bitowym procesie korzystać z 64-bitowych rejestrów, a nawet „można byłoby robić w zasadzie 64-bitowe programy, w środowisku 32-bit (w Windows 32)”.

Na to pytanie odpowiedź jest podwójnie negatywna: nie, nie da się w 32-bitowym procesie zakodować instrukcji operujących na nowych, 64-bitowych rejestrach; oraz nie, nie da się 64-bitowych instrukcji wykonać na 32-bitowym systemie, a sztuczka z call 33h tym bardziej nie zadziała.

Da się:
– przełączyć tymczasowo tryb procesora, w systemie 64-bitowym, jak @sapero pokazał

• jeśli procesor posiada sprzętową wirtualizację, uruchomić maszynę wirtualną z 64-bitowym systemem nawet na 32-bitowym systemie gospodarzu.

Oto wyjaśnienie problemu z dostępnością rejestrów:

16-bitowe rejestry w 32-bitowym procesie, oraz 32-bitowe rejestry w 16-bitowym procesie kodowane są prefixem 66h, dodatkowym bajtem umieszczonym przed kodem właściwej instrukcji. Obecność prefiksu 66h oznacza, że instrukcja operuje na „niewłaściwych” rejestrach (niezgodnych z bieżącym trybem pracy procesora), a jego brak że instrukcja dotyczy „właściwych”, domyślnych rejestrów.

W trybie 64-bitowym instrukcje na rejestrach 16- i 32-bitowych są kodowane tak samo jak w trybie 32-bitowym.
Dostęp do rejestrów 64-bitowych uzyskuje się poprzez nowy prefix 48h (właściwie cały zbiór 16 prefiksów, bo niektóre bity kodują dodatkowe informacje)

Dlaczego jednak nie można użyć prefiksu 48h w trybach 16- i 32-bitowych?
Dlatego że ma on inne znaczenie: koduje instrukcję dec ax, więc ciąg 48 89 D8 oznaczałby dec ax : mov ax,bx albo dec eax : mov eax,ebx zależnie od trybu.

Ponieważ instrukcję dec ax od zawsze można też zakodować jako dwa bajty FF C8, postanowiono zrezygnować z jednobajtowego wariantu tej instrukcji, a kodowi 48h nadać nowe znaczenie. Podobnie z trybu 64-bitowego wyleciał szereg innych nie używanych instrukcji, jak AAA, AAD i in.

W ten sposób, z powodu zmiany znaczenia niektórych opcode'ów, w trybach 16- i 32-bitowych nie ma żadnej możliwości dostania się do 64-bitowych rejestrów ogólnego przeznaczenia.

W C++ nie można mieć 32-bitowych pointerów w aplikacji 64-bitowej, jako opcja kompilatora? Pytam z ciekawości. Java taką optymalizację robi domyślnie, jeśli nie potrzebujemy więcej niż 64 GB RAMu.

W takim razie te 64 bitowce to kolejna porażka... wyścig megalomanów do przepaści. ;)

Znalazłem gdzieś na innym forum podobne pytanie, ale zgubiłem to.

Tam jakiś facio odpalał 64 bitowe programy na systemie 32, ale to nie był Windows, lecz coś innego.

Ale to przełączanie trybów jest skomplikowane - długo to trwa?

No, ale pewnie te pajace z MS zablokowali również i to - wyskoczy jakiś zasrany 'Windows Defender' i po zabawie... hehe!

W takim razie te 64 bitowce to kolejna porażka... wyścig megalomanów do przepaści.

Spokojnie. Straty na większym rozmiarze wskaźników z pewnością nadrabia się większą ilością rejestrów, co pozwala na rzadsze odwołania do pamięci i przekazywanie parametrów funkcji w rejestrach a nie na stosie.

Wyolbrzymiasz problem ;-)

No, ale w systemie 64 można zasuwać tymi rejestrami 64 w 32 bitowej aplikacji.

Nawet ten biedny Windows jakoś musi wyjść z tego trybu WoW64, czyli wejść w tryb 64 z 32, i robić to bardzo szybciutko - pewnie jednym prostym skokiem...