Маркетинговые ходы вокруг языка Ассемблер?

Question

[PrayHero]

Почему в книгах по высокоуровневым языкам ассемблер обвиняют в непортируемости? Ведь опытные программисты укладываются в набор команд 8086. Как и программы на Си, программы на Ассемблере нужно пересобирать под каждую следующую платформу. Разве нет? Почему тогда ассемблерные программы не портируемы? Объясните, пожалуйста, доходчиво.

Answer 1

[galaxy]

Ведь опытные программисты укладываются в набор команд 8086

Нет. Лет 30 уже никто не пытается уложиться в 8086. Наоборот, если уж берутся писать на ассемблере, то часто с целью использования каких-то железо-зависимых вещей.

Как и программы на Си, программы на Ассемблере нужно пересобирать под каждую следующую платформу. Разве нет?

Что вы вкладываете в слова "новая платформа"?
Другая ОС? - да, надо пересобирать, и часто менять, ведь API разных ОС отличается. При этом C часто позволяет исходный код программы не трогать, т.к. функции стандартной библиотеки, POSIX API предоставляют платформонезависимый интерфейс. А вот в программе на asm соответствующий код придется переписать.

Новая версия ОС? - здесь есть свои нюансы, но собранная статически программа обычно прекрасно работает на протяжении многих поколений ОС (вы же не загружаете новую версию, допустим, игры под каждую версию Windows? Взять вон diablo 2 - как работала она под Win 98, так же отлично тот же бинарник заведется в Win 10).

Новый процессор? - эти вообще паталогически обратно совместимы. Код, написанный или скомпилированный чисто под 30-летний 386 будет работать на i9 (при условии совместимости по пунктам выше).

Возвращаясь к первоначальному вопросу: вы, видимо, не понимаете или не придаете значения тому, что существуют не только x86 процессоры. Изначально ЯП высокого уровня разрабатывались именно с целью абстагировать код программы от конкретного железа. В 60-80-е годы не было единой и даже какой-то одной распространенной железной платформы, что же прикажете, допустим, стандартные утилиты Unix переписывать каждый раз с начала и до конца на новом (подчеркну, НОВОМ, другом) ассемблере?
Даже сейчас, когда вроде бы кругом x86, есть Itanium (ну ок, был в недавнем прошлом), ARM (в виде нескольких версий архитектуры и огромном количестве железных воплощений), где-то теплятся SPARC и PowerISA. Наконец, микроконтроллеры (привет ардуинщикам).

Коротко: ЯП высокого уровня (не только C) позволяются абстагироваться (до определенных пределов) от железа и от ОС и не менять исходный код программ при переносе на другую платформу, ограничиваясь механической процедурой перекомпиляции.

Comments

[PrayHero]

Где-то писали, что программы в рамках команд 8086 лучше оптимизируются автоматически. Тут мне пишут, что программа на Си позволяет абстрагироваться от железа. Но для каждой новой платформы ОС плюс железо еë заново нужно собирать. Если говорить о процессорах, поддерживающих архитектуру команд 8086, то программу на ассемблере точно так же нужно будет только пересобрать один раз под каждую платформу, разве нет? Тогда от программы на ЯВУ она мало отличается.

[galaxy]

Но для каждой новой платформы ОС плюс железо еë заново нужно собирать. Если говорить о процессорах, поддерживающих архитектуру команд 8086, то программу на ассемблере точно так же нужно будет только пересобрать один раз под каждую платформу, разве нет?

Вы все-таки определитесь, что вы подразумеваете под платформой (выше я написал варианты).
Скажем, программу не надо пересобирать под каждый новый процессор на базе x86. Это имеет смысл, если вы, например, хотите задействовать новые инструкции (типа SSE4 или AES-NI).

Под совсем новую/другую платформу, когда меняется архитектура ЦП или меняется ОС (Windows->Linux, например), программу на ЯВУ достаточно обычно просто пересобрать, программу на асме нужно либо сильно переписывать, либо просто выкинуть и написать новую.

Поймите 2 момента:
- нет одного ассемблера, под каждую архитектуру свой, и они друг от друга отличаются не меньше, чем разные ЯВУ
- в ассемблере нет стандартной библиотеки (для взаимодествия с ОС, ввода-вывода и пр), поэтому такие вещи становятся очень сильно зависящими от платформы

[PrayHero]

galaxy, я эти два момента прекрасно понимаю. Вопрос о программе без использования библиотек с набором команд исключительно 8086: нужно ли еë пересобирать для каждого процессора, поддерживающего 8086, при условии использования одного и того же сборщика, и если нет, то в каких случаях да?

[galaxy]

нужно ли еë пересобирать для каждого процессора, поддерживающего 808

нет, там же обратная совместимость

[Василий Банников]

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

[PrayHero]

Василий Банников, переносимость программы на языке ассемблера зависит только от поддержки всех использованных в ней инструкций на целевой машине?

[Василий Банников]

PrayHero,
1. Инструкции
2. Регистры
3. Системные API
4. Модель памяти
5. Разрядность

Answer 2

[Иван Шумов]

Сразу видно человека, который ни Таненбаума не читал, ни даже Википедию не открыл. Ассемблер это не язык, это транслятор инструкций в машинный код. Ассемблеров ровно столько же столько аппаратных архитектур. Инструкций для одного процессора не будет в другом процессоре и они не взаимозаменяемые. Это самый низкий уровень где нет абстракций (немного утрирую, но по отношению к другим языкам это так)

Answer 3

[Saboteur]

Потому что программу на Си можно просто пересобрать.

А программу на ассемблере переписать.

Answer 4

[CityCat4]

Почему тогда ассемблерные программы не портируемы?

Потому что программа, написанная на Ассемблере для IBM/360 никогда не заработает на IBM PC :) несмотря на то, что изначально как бы делались одной конторой :)
В 1990 - 1995 годах я очень много программировал на IBM/360, на PL/1 и ассемблере (а там другого не было), гигантские программы писал, сотни макросов имел в запасе.
После того, как перешел на i8086 - большая часть этих знаний пошла в корзину, осталось только общее понимание того, как устроен процессор :)
Ассемблер - это самый нижний из доступных уровней разработки, на нем сейчас пишут только misson-critical секции, потому что это реально машинно-зависимо - на другом семействе процессоров даже той же самой архитектуры уже может не заработать, на другой архитектуре не заработает гарантированно.

Answer 5

[VitalyChaikin]

Если доходчиво, то в этом и отличие высокоуровневого языка от низкоуровневого;
Высокоуровневый -> Компилятор в низкоуровневый язык на заданной архитектуре -> исполняемый код
Низкоуровневый язык на заданной архитектуре -> исполняемый код
Легко заметить что Ассемблер (он же Низкоуровневый язык на заданной архитектуре) уже включает в себя заданную архитектуру, поэтому и не может портироваться на другую архитектуру;