Является ли программа, поставляемая в формате ассемблера, переносимой между дистрибутивами Linux (различия в архитектуре процессора по модулю)?
Вот предыстория моего вопроса: я работаю над новым языком программирования (по имени Aklo), чей modus operandi будет классической компиляцией в .s и передачей результата в ассемблер GNU.
Очевидно, что в конечном итоге было бы неплохо, чтобы реализация была написана сама по себе, но я смирился с тем, что поддерживаю ее на C ++, чтобы решить проблему с курицей и яйцами: предположим, что вы загружаете компилятор впервые, а он сам написан на Акло, как ты это компилируешь? Насколько я понимаю, разные дистрибутивы Linux и другие UNIX-подобные системы имеют разные соглашения для двоичных форматов.
Но мне пришло в голову, что решение может состоять в том, чтобы отправить файл .s (ну, по одному на архитектуру процессора): справедливо предположить, что у вас есть или можно установить ассемблер GNU. Конечно, мне все еще нужен загрузочный компилятор, но это не обязательно должно быть быстро; Я могу написать это на Python.
Является ли ассемблер переносимым в отличие от двоичных файлов? Есть ли другие камни преткновения, о которых я не думал?
Добавлено в ответ на один ответ:
Я с тоской смотрел на LLVM, там наверняка есть много хорошего, и это облегчит мою жизнь, за исключением того, что это повлечет за собой зависимость от правильной устанавливаемой версии LLVM. Было бы не так плохо иметь такую зависимость от машин для разработки, но в мире, где распространяются программы в качестве исходного кода, такая же зависимость возникнет для каждого пользователя каждой программы, когда-либо написанной в Aklo, и я решил, что это слишком высокая цена, чтобы заплатить.
Но если решение доставки откомпилированных программ в качестве ассемблера работает ... тогда это решит эту проблему, и я все-таки смогу использовать LLVM, что было бы большой победой.
Таким образом, вопрос о переносимости ассемблера гораздо важнее, чем я предполагал.
Вывод: из ответов здесь и в списке рассылки LLVM http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028991.html кажется плохой новостью является то, что проблема неразрешима, но хорошая новость заключается в том, что использование LLVM делает ее не хуже, поэтому я свободен сделать это и получить все преимущества.