Предположим, что эти два по существу одинаковы:
push 1
и
0x1231
Что говорит о том, что каждая инструкция по сборке сопоставляется с машинным кодом.
Но обязательно ли, чтобы каждый машинный код мог сопоставляться только с одним ассемблерным кодом?
Язык ассемблера MIPS имеет несколько «псевдоинструкций». Например, «переместить» — это внутренне просто «добавить» с неявным операндом $0.
Вы вполне могли бы определить программу на ассемблере, которая поддерживает "синонимы" для инструкций: никакого вреда не будет, если вы позволите коду пользователя FOO означать то же самое, что и BAR. Я не знаю навскидку ассемблеров, которые это делают, но вы, безусловно, можете добиться того же эффекта с помощью тривиально простого макроса в любом макроассемблере ;-).
je и jz. Они означают одно и то же, но иногда программисту немного легче понять одно из двух.
- person Earlz; 25.05.2011
да. Реальным примером этого является ассемблер 68k, где
Официальные мнемоники BCC (ветвь при переносе) и BCS (ветвь при переносе) можно переименовать в BHS (ветвь выше или равно) и BLO (ветвь меньше) соответственно. Многие ассемблеры 68000 поддерживают эту альтернативную мнемонику.
Даже без синонимов ассемблерная инструкция может соответствовать более чем одному машинному коду.
Например. add eax, ebx можно представить как 03 C3 или 01 D8.
На самом деле это может быть полезно, например. для идентификации конкретных компиляторов.
Дополнительные примеры можно найти в этой статье.
Обратное также может быть правдой, в некотором смысле.
Пример немного надуманный, но один и тот же машинный код (F3 90) отображается либо в REP NOP, либо в PAUSE на x86.
Какой из них выполняется, зависит от процессор, на котором выполняется код.
Хотя один и тот же код операции был выбран преднамеренно и что касается состояния процессора, они не имеют значения, время выполнения и точная внутренняя реализация могут различаться в зависимости от HT (PAUSE) и ЦП без HT (NOP).
Помимо разницы между PAUSE и REP NOP, которая не имеет большого значения, можно написать машинный код, который трудно дизассемблировать статически.
Например. можно тщательно сконструировать последовательность машинного кода, которая приводит к совершенно другим инструкциям сборки, если дизассемблирование начинается, скажем, со смещения 0 по сравнению со смещением 1.
Можно также написать самомодифицирующийся код сборки, чтобы усложнить статический анализ.
Я не вижу никакой концептуальной причины, по которой вы не могли бы разработать язык ассемблера, в котором более одного оператора ассемблера сопоставляются с одним и тем же кодом операции на базовом процессоре.
Я тоже не сразу вижу какой-то особенно веский повод для этого, но уже поздно и, возможно, я что-то упускаю.
То, что делает конкретная инструкция машинного кода, определяется процессором (или семейством процессоров), для которого она предназначена. И одна и та же инструкция машинного кода всегда будет делать одно и то же.
Обычно конкретная инструкция машинного кода дизассемблируется только до одного оператора. В некоторых более сложных наборах инструкций есть несколько способов написать одно и то же выражение на ассемблере. Хорошим примером является индексированный поиск. Некоторые операторы также могут иметь синонимы, но, опять же, для процессора они будут означать одно и то же.
Однако для архитектуры может существовать несколько целых наборов сборок. Это произошло с архитектурой x86, где есть стандартный набор, определенный Intel, и другой, основанный на стандарте, созданном AT&T, который используется GCC.
Как правило, цель сборки состоит в том, чтобы позволить вам напрямую программировать машину без двусмысленности в отношении того, что будет выполняться. В значительной степени требуется отображение 1: 1.
Я не удивлюсь, если где-то в каком-нибудь ассемблере есть какие-то косвенные отображения, возможно, для обработки изменений кодов операций в какой-то линейке процессоров. Хотя я не знаю ни одного.
