Перенос под 64 бита

Какие существуют руководства по переносу 32-битных программ под 64 бита?

Есть программа на С (заточена под GCC 2.95), у неё библиотека на ассемблере, мейкфайл компилирует библиотеку NASM-ом. При попытке собрать программу под 64 бита NASM ругается "instruction not supported in 64-bit mode" на команды вроде: pusha, push ecx, jmp dword [OpTable+eax*4].

Есть ли какие-либо стандартные рекомендации, как это переделывать? Пока разобрался только с pusha/popa и push/pop r32.

Программа, если кому интересно — http://www.thedopefish.com/playspc/

 

Я не понял в чем прелесть переносить плеер в 64-бита. Он что в режиме 32-бита тормозит?
Я понимаю кодеки сложные, а у вас там простейший формат и длины файлов не заоблачные.

 

Тянет десятки мегабайт библиотек совместимости.

Может тогда подскажете документацию, как слинковать 32-битную библиотеку, скомпилированную NASM-ом, и 64-битные *.о, скомпилированные GCC? По каким ключевым словам искать?

Насколько я понял, для проигрывания формата там эмулируется соответствующий процессор.

 

cmpayc Вы хоть прочитали бы что-то : обычные(!) 32-битные программы прекрасно работают под 64-битными системами. Может в Линуксе это чуть тяжелее, но Касперский окромя дравера ничего больше не компилил... Ну может пару чего-то специфического. Но ваша задача не такая. Чего она может тянуть ?

И что? На фига его перекомпилировать. Проблема появляется при работе в ядре, т.к. адресация другая.
Для вашей задачи 2 Гбайт за глаза хватит.

 

Если речь идёт именно про асмовый код - то очевидно, что нужно переписывать всю логику с нуля, под нужный процессор/архитектуру, в чём вам поможет Intel Software Developer's Manuals. Просто взять и собрать код для x86 под AMD64/EM64T не получится в связи с относительно большим кол-вом различий, связанных с его разработкой (другая размерность адреса, новые регистры, другая конвенция вызовов, каке-то команды убрали, какие-то работают по-другому, итд).
Ещё есть вариант использовать т.н. crossplatform-assembler (конкретных названий вспомнить не могу, но гугл подскажет), в случае с ним, код пишется на неком псевдоассемблере, который затем транслируется в нативный асмовый код для нужной архитектуры.

 

GTK-1

Причём ей нужна какая-то версия не вполне совместимая с моей 1.2.10. В результате программа на 1.2.10 грузит процессор на 100% и не реагирует на SIGQUIT, только на SIGTERM.

Если проблема в несовместимости версий GTK, перекомпилированная программа заработает нормально. Проблема в том, что если этого не сделали дистростроители, разворачивать окружение для сборки 32-битных программ под 64-битной системой эквивалентно установке второй ОС. Надеялся, что можно сделать проще.

Мне нужна библиотека, преобразующая SPC в PCM на лету. Сама по себе эта программа мне интересна только как пример работы с такой библиотекой. Либо искать способ подключать эту библиотеку к 64-битной программе, либо перенести её под 64-битный процессор. Либо искать программу с другой библиотекой.

 

Уже читаю.

Жалко.

Чувствую, что проблемы будут, в основном, с адресами. Много констант завязано на 4-байтные целые.

Первый заголовок: "C: The Cross-Platform Assembler." Далее, в основном, про 6502.

Ищу...

Это как-то связано с синтаксисом AT&T?

 

ещё придется переделать WinAPI функции, так как:

push rcx, jmp qword [OpTable+rax*4] )

 

valterg

Вы не представляете себе всей прелести ситуации. Вот у меня дома стоит gentoo собранная под x86_64. И есть в этой генту 32-х битное приложение -- wine. У него нет никаких проблем с железом: 32-битный код выполняется на 64-битной системе без проблем, а поскольку я предусмотрительно собрал ядро с поддержкой 32-битных процессов, то и с этой стороны всё отлично. Но, из-за такого рода приложений, у меня под файлики библиотек отведено не две директории (/lib и /usr/lib), а четыре: /lib32 /lib64 /usr/lib32 /usr/lib64. Так происходит потому, что wine не признаёт библиотек собранных для 64-битных программ. То есть ld отказывается запускать такое приложение, если не найдёт библиотеки подходящей версии (с подходящей разрядностью адреса). А поскольку сообщество gentoo ещё не готово официально поддерживать сборку _каждой_ библиотеки в двух вариантах, то у меня стоит оверлей к портажам, на который сообщество поглядывает одобрительно, но воспринимает как фичу экспериментальную, и не спешит мергать в основное дерево портажей. Этот оверлей позволяет собирать основную массу библиотек в 32-битном варианте.
И, обратите внимание, ради одного приложения, у меня в системе около 200 библиотек поставлены в двух вариантах.
Кстати можно точнее сосчитать:

Код (Text):

1. $ ls /lib32/*so /usr/lib32/*so | wc -l
2. 236

А всего библиотек:

Код (Text):

1. $ ls /lib64/*so /usr/lib64/*so | wc -l
2. 708

Часть из них -- это прямые зависимости, часть -- косвенные. Причём помнится, я имел достаточно геморроя (правда больше механического) с тем, чтобы заставить всё это работать. Геморрой этот, в общем-то отличительное свойство генту, но я упоминаю об этом не для того, чтобы поплакаться. Дело в том, что я-то могу разгрести все эти зависимости и собрать все необходимые библиотеки в двух вариантах, даже несмотря на то, что разработчики дистрибутива этого не поддерживают. Но что делать пользователю с бинарным дистрибутивом, если ему требуется 32-битная версия библиотеки, которую разработчики включили в дистрибутив лишь в 64-битном варианте?

cmpayc

Да. Рекомендация тут одна: переписать всё на C. Причём лучше сразу писать в 64-х битной системе, так как в этом случае проще не наделать ошибок, которые будут мешать портировать программу на платформу с иной разрядностью адреса.
Переписывать на асме выглядит несколько странно, ибо в дальнейшем придётся поддерживать две самостоятельные программы. А разговоры о "кроссплатформенном ассемблере" -- это на самом деле разговоры про C.

 

cmpayc
на рсдн сеть замечательная статья раскрывающая все(большинство) подводных камней при переходе с 32 на 64 с примерами на цэ

 

угу, для Си

 

Из ассемблерных библиотек ничего внешнего не вызывается, все вызовы системных функций из сишной части. Да и библиотека, имхо, была написана ещё до победного шествия Win32

Спасибо, но скорее там придётся менять структуру этой таблицы и ставить [OpTable+rax*8]. Или как-то можно перейти по 4-байтному адресу?

 

У меня тоже

По-моему уже есть и 64-битный вариант. Только пока не работает Тоже пользуюсь 32-битным.

Он доступен через layman? Как называется?

На другом форуме уже успели посоветовать MSIL. Но, пожалуй, Си проще

 

Эта? http://www.rsdn.ru/article/cpp/XXtraps64bit.xml Уже смотрел. То есть она достаточно полная и охватывает все основные сложности? Спасибо.

 

cmpayc

sjnewbury's multilib-overlay
Я не знаю что такое layman, почитаю как-нибудь, а ставил я его программкой git

 

git://github.com/sjnewbury/multilib-overlay.git
http://github.com/sjnewbury/multilib-overlay
Он? Спасибо, качаю.

Layman — утилита, которая упрощает установку и автоматическое обновление оверлеев. http://layman.sourceforge.net

В списке http://www.gentoo.org/proj/en/overlays/repositories.xml этот оверлей есть, то есть кто-то его одобрил.

 

можно было по 4-байтному смещению вроде... посмотри мануал по командах x64, если какую-то команду не поддерживает компилятор, но поддерживает архитектура, то может запрограммировать её в опкодах)))

 

cmpayc

Я думаю причина больше в этом, чем в различии 32 и 64. Все это устарело и у вас даже под 32-битами будет проблема. А вы пытаетесь скакнуть сразу через два порога. Я ковырялся в свое время в Линуксе: на предмет совместимости со старыми пакетами и компиляторами там угрохано много - действительно куча дополнительных библиотек и инклюдов. Для 64-бит такого никто не стал делать, видимо.

 

Другие программы под GTK-1 собираются без проблем и работают без видимых отклонений. Но они на чистом C, C++ или фортране.

 

Ну так все-таки, в чем проблема собрать 32-бита и попробовать? Может этот путь проще, чем ассемблер переделывать?