Синтаксис языка ассемблера одинаков для разных архитектур

Question

Я знаю, что не могу написать язык ассемблера, который будет запускаться / компилироваться на всех машинах, потому что у них разные наборы команд, коды операций, регистры и т. Д. c. Мой вопрос, хотя набор инструкций будет другим, синтаксис сборки (или сам язык) одинаков для любой архитектуры?

Answer 1

Мой вопрос, хотя набор инструкций будет другим, синтаксис сборки (или сам язык) одинаков для любой архитектуры?

Нет!

Только для x86 существует дюжина различных ассемблеров, каждый из которых имеет свою уникальность, заставляя их принимать немного другой язык - есть GAS, MASM, NASM, TASM, FASM, ASM ... Мало программы будут собираться со всеми этими ассемблерами x86.

Синтаксис at & t против intel - цель первая против цели последняя.

Существуют различные требования к директивам: .pro c, .endp , et c ..

Существует прекрасный синтаксис Intel byte ptr для определения размера / ширины операции, по сравнению с большинством других суффиксов .b, .w, .l остального мира ( иногда без .).

Некоторые ассемблеры, такие как: after label, другие не разрешают это (или вместо этого требуют a).

Некоторые требуют специальных символов, чтобы отличать имена регистров от других идентификаторов (например, префикс% для некоторые, префикс $ для других), другие нет.

Синтаксис для режимов адресации также значительно различается, например, в нотации ARM [] необычное расположение константы после скобок указывает на обновление переменной указателя.

И это без учета названий кодов операций.

В Intel мы используем call для инструкции, которая вызывает функцию (передает p c в функцию при захвате адреса возврата), jal на MIPS & RIS C V, bsr, jsr или bl, jms на других и т. Д. c ..

Термин для вызова системных вызовов, по-разному syscall, ecall, trap, sc, int, swi, svc et c ..

Короче говоря, не существует стандартизации языка, грамматики, или синтаксис на ассемблерах.

---

Что касается simil Вообще говоря, есть понятия условного ветвления if-goto (и безусловного ветвления) как механизма для конструкций потока управления, понятия меток как целей ветвления и целей данных, одна инструкция на строку (как упоминает @Peter), mnemoni c код операции с отдельными операндами - но эти сходства являются скорее концептуальными, чем синтаксическими c.

Answer 2

Существует большое сходство между большинством ассемблеров. Он всегда ориентирован на строки, как

[label:]  mnemonic [operand list]

, хотя некоторые ассемблеры используют пробелы вместо запятых для разделения операндов.

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

Некоторые синтаксисы ставят операнд назначения последним, многие другие ставят его первым , но что касается базовой c грамматики разбора строк в токены, это проблема семантики c, а не syntacti c.

Существует несколько ассемблеров со значительно отличающимся синтаксисом, например x86 HLA , где инструкции выглядят как C вызовы функций.

Макропроцессор, встроенный в большинство ассемблеров, значительно отличается в разных ассемблерах. Названия директив, такие как .long против dd против dword.

Classi c MIPS на ассемблере, имеют директиву a .align, которая приносит предыдущие метки вместе с ней , вместо того, чтобы просто создавать отступы в текущем местоположении. (А без .set noreorder ассемблер фактически оптимизирует ваш код для заполнения интервалов задержки ветвления.) Опять же, это не syntacti c, а большая разница в семантике c в том, что означает .align.

Кроме этого, довольно универсально, что каждая строка asm собирается в 0 или более байтов вывода в некотором разделе, независимо от окружающих строк.

Answer 3

Существует такой термин, как ассемблер высокого уровня https://en.wikipedia.org/wiki/High-level_assembler. Однако теперь нет смысла использовать его, так как на этой странице написано:

Высокоуровневые ассемблеры, как правило, предоставляют инструкции, которые непосредственно собирают один-в-один в низкоуровневый машинный код, как в любом ассемблере.

Разные архитектуры предоставляют обычно разные функции, такие как условные инструкции, которые нельзя сопоставить с другой сборкой.

Если вам нужно создать переносимый код, используйте язык C. Это дает вам много возможностей для создания низкоуровневых программ. Если вам нужно использовать специфическую c функцию архитектуры, вы можете использовать встроенный ассемблер (в G CC это расширенный ASM).