1, 2, 3 и 5: обозначения несколько избыточны, но я считаю, что это хорошо при разработке на ассемблере. Избыточность помогает читать. Идея «пусть ассемблер поймет это» легко превращается в «пусть программист, который читает код, разберется», и мне не нравится, когда я выполняю чтение. Программирование не только для записи; даже сам программист должен читать свой собственный код, а избыточность синтаксиса очень помогает.
Другой момент заключается в том, что '%' и '$' означают, что новые регистры могут быть добавлены без нарушения обратной совместимости: нет проблем с добавлением, например, регистра с именем xmm4, так как он будет записан как %xmm4, который нельзя путать с переменной с именем xmm4, которая была бы записана без "%".
Что касается количества набираемого текста: обычно при программировании на ассемблере узким местом является мозг, а не рука. Если «$» и «%» замедляют вас, то либо вы думаете намного быстрее, чем то, что обычно считается выполнимым для человека, или, что более вероятно, ваша задача слишком сложна и не должна выполняться в монтаж; его следует оставить автоматическому генератору кода, общеизвестному как «компилятор C».
Был добавлен суффикс 'l' для обработки некоторых ситуаций, когда ассемблер "не может" понять это. Например, этот код:
mov [esp], 10
является неоднозначным, потому что он не говорит, хотите ли вы записать байт со значением 10 или 32-битное слово с тем же числовым значением. Затем синтаксис Intel требует:
mov byte ptr [esp], 10
, что довольно уродливо, когда вы думаете об этом. Сотрудники AT & T хотели сделать что-то более рациональное, поэтому они придумали:
movb $10, (%esp)
и они предпочитали быть системными и иметь суффикс 'b' (или 'l' или 'w') везде . Обратите внимание, что суффикс не всегда требуется . Например, вы можете написать:
mov %al, (%ebx)
и пусть ассемблер GNU «выяснит», что, поскольку вы говорите о «% al», этот шаг предназначен для одного байта. Это действительно работает ! Тем не менее, я все же считаю, что лучше указать размер (это действительно помогает читателю, а сам программист является первым и главным читателем своего собственного кода).
Для «инверсии»: все наоборот. Синтаксис Intel имитирует то, что происходит в C, где значения вычисляются справа, а затем записываются в то, что слева. Таким образом, запись идет справа налево, в «обратном» направлении, учитывая, что чтение идет слева направо. Синтаксис AT & T возвращается в «нормальное» направление. По крайней мере, так они считали; поскольку они все равно решили использовать свой собственный синтаксис, они подумали, что могут использовать операнды в том, что они считают «правильным порядком». Это в основном соглашение, но не нелогичное. Соглашение C имитирует математические обозначения, за исключением того, что математика составляет около , определяя значений («пусть x будет значением 5»), а не о присваивая значений («мы записываем значение 5 * 1032»). * в слот, называемый «х» "). Выбор AT & T имеет смысл. Это сбивает с толку только тогда, когда вы конвертируете код C в сборку, задача, которую обычно следует оставлять компилятору C.
Последняя часть вашего вопроса 5 интересна с исторической точки зрения. Инструменты GNU для x86 следовали синтаксису AT & T, потому что в то время они пытались завладеть миром Unix («GNU» означает «GNU - это не Unix») и конкурировать с инструментами Unix; Unix находился под контролем AT & T. Это до появления Linux или даже Windows 3.0; ПК были 16-битными системами. Unix использовал синтаксис AT & T, поэтому GNU использовал синтаксис AT & T.
Хороший вопрос заключается в следующем: почему AT & T сочла разумным изобрести собственный синтаксис? Как описано выше, у них были некоторые причины, которые были не безосновательны. Разумеется, стоимость использования собственного синтаксиса ограничивает возможности взаимодействия. В те дни компилятор или ассемблер C не имел никакого смысла как отдельный инструмент: в системе Unix они должны были предоставляться поставщиком ОС. Кроме того, Intel не была крупным игроком в мире Unix; В больших системах в основном используются VAX или Motorola 680x0 производные. Никто не предполагал, что ПК MS-Dos через двадцать лет превратится в доминирующую архитектуру в мире настольных компьютеров и серверов.