> -- Сергей Губанов писал(а):
> Ядро тоже программа и компилируется компилятором.Да, конечно. Но это ничего не меняет в том, что сказано ранее.
> -- Сергей Губанов писал(а):
> Ядро может запустить либо старую 32-разрядную прикладную программу в 32-разрядном legacy mode, или новую 64-разрядную в 64-разрядном long mode.Правильно.
> -- Сергей Губанов писал(а):
> Старую 32-разрядную невозможно запустить как 64-разрядную.Совершенно верно. Загрузчик прочитает заголовок исполняемого файла и... корректно запустит программу.
> -- Сергей Губанов писал(а):
> Для компиляции в 64-разрядную нужен специально обученный для этого компилятор.Тоже верно.
> -- Сергей Губанов писал(а):
> Там много чего по-другому. Например, первые четыре аргумента в процедуру передаются через регистры (уже одно только это делает невозможным смешивание 32-разрядного и 64-разрядного кода).А никто и не говорит про смешивание кода. Речь шла о том, что сохраняются таблицы кодогенерации. Да, раньше, например## Код:
```
в 16-разрядном режиме:
8B D8        MOV BX,AX
в 32-разрядном:
8B D8        MOV EBX,EAX
в 64-разрядном:
8B D8        MOV RBX,RAX
```
Код операции сохраняется, меняется только разрядность регистров. Поэтому если в компиляторе используются отлаженные таблицы генерации, то они будут работать и с новой разрядностью операндов. Да, нужно пересчитывать переходы (размер констант тоже вырастет, адреса (ссылки/указатели) станут больше), да, нужно внести изменения в вызовы подпрограмм, да, надо сформировать новый заголовок (PE) исполняемого файла, да, надо откорректировать размеры памяти под стек, код и пр. Но самая тонкая часть работы: преобразование исходного текста в код, не будет делаться с нуля. Постепенно от версии к версии компилятора добавят использование новых команд процессора, сделают дополнительную оптимизацию по скорости, улучшат взаимодействие с новой ОС и т.п.