Użytkownik "Marcin 'Qrczak' Kowalczyk" napisał:

======================================
Załóżmy, że rozwijasz swój program w 32-bitowym asemblerze. Program ma
już setki tysięcy linii kodu.

Tymczasem ja mam 64-bitowy procesor i co prawda system operacyjny może
uruchamiać również 32-bitowe programy, ale jest się wtedy ograniczonym
do 2GB pamięci i tylko podstawowe biblioteki systemowe są
zainstalowane w wersji 32-bitowej. Oprócz zmiany wielkości rejestrów
architektura x32_64 oferuje kompilatorowi więcej rejestrów i
adresowanie względem rejestru RIP, co ułatwia tworzenie kodu
niezależnego od adresu, pod którym się znajdzie. Niemal wszystkie
zainstalowane u mnie programy i biblioteki są 64-bitowe; są generowane
z tych samych źródeł, co 32-bitowe. Resztki 32-bitowości są coraz
mniejszym marginesem zachowywanym tylko dla kompatybilności z
programami, które nie są dostępne w źródłach, a producent udostępnia
tylko wersję 32-bitową (acroread, flash, Google Earth).

To jak, piszesz swój program od nowa?
======================================

Pozdrawiam w Nowym Roku!

Z Tobą nie śmiał bym polemizować, ponieważ znam Twój dorobek i darzę Cię
wielkim szacunkiem. Moje trochę prowokacyjne wypowiedzi odnoszą się do
trolli zaśmiecających wątek. Wypisują bzdury nie mając najmniejszego
pojęcia o czym piszą.

A wracając do tematu. Przetransformowanie 32 bit programu na pełne 64 bit
nie jest proste w żadnym języku. Nie brałem się dotychczas za to i
niewiele mogę powiedzieć. W assemblerze będzie to pewnie żmudne i
pracochłonne. W HLach pewnie zrobi to odpowiedni kompilator (jeśli już
takie są). Problem jest złożony i wart dyskusji. Porównując dawne
programy 16 bit z późniejszymi 32 bit, możemy wyciągać pewne wnioski. W
odniesieniu do 64 bit pewnie trzeba radykalnie zmienić podejście. Chociaż
pewne wnioski co daja większe rejestry można wyciągać na podstawie dawno
już istniejących mechanizmów - MMX/3dnow wykorzystujących 64 bitowe
rejestry, czy 80 bit rejestry FPU. Moim zdaniem ułatwiają operacje na
dużych liczbach i umożliwiają znaczne przyspieszenie takich operacji, co
ma zastosowanie w grafice wektorowej, czy kodekach/dekodekach
audio/video. A takie procedury można wyciągnąć do DLL'i i nie trzeba
przepisywać całego programu. To ciekawy temat.

Pozdrawiam Remek