Автор: Хищник
Дата публикации: Ноя 25, 2006 на данном форуме.

Постфиксный нуль-операндный ассемблер

Наличие ассемблера в составе форт-системы представляется привлекательным по целому ряду факторов. Поддержка транслятором машинного языка предоставляет программисту лишнюю степень свободы и возможность реализовывать наиболее ответственные участки кода. Общая идеология Форта существенно облегчает стыковку ассемблерных модулей со словами высокого уровня. Как правило, ESP указывает на вершину стека возвратов, EBP – на вершину стека данных, а математический сопроцессор изначально организован в виде стека. Соответственно, ассемблерный модуль может довольно просто получить передаваемые ему параметры и отправить на стек результаты.
Интеграция ассемблерного кода с Фортом позволяет, кроме того, использовать высокоуровневые определения внутри ассемблерных вставок, в том числе и на этапе трансляции кода. Например, вычисление смещения или начального адреса в ассемблерном коде может быть выполнено с использованием обычных слов форт-системы, в том числе и высокоуровневых.

При создании ассемблера, интегрированного с форт-системой, разумно было бы использовать возможности транслятора по обработке входного потока. В этом случае использование постфиксной формы записи ассемблерных команд позволит минимизировать объем ассемблера, но за счет отказа от привычного ассемблерного синтаксиса. Следует заметить, однако, что выигрыш в объеме ассемблера при переходе к постфиксному представлению получается весьма значительным.
Классический пример постфиксного ассемблера для процессора i8080 (580ВМ80) приведен в книге Баранова и Ноздрунова «Язык форт и его реализации». В этой книге приведен полноценный ассемблер, объем листинга которого составляет всего полторы страницы. Ассемблер интенсивно использует особенности системы команд процессора i8080, вычисляя код операции на основе переданных на стеке параметров – номеров регистров. При этом используется тот факт, что команды i8080 слабо кодированы, т.е. код команды включает в себя битовые поля, которые могут быть разобраны отдельно и соответствуют, в том числе, номерам регистров, используемых в команде.
Например, команда пересылки между 8-разрядными регистрами в процессоре i8080 имеет формат:

0 1 a a a b b b

В этом случае очень удобно организовать компиляцию команды MOV в виде:



Если символическим обозначениям регистров поставить в соответствие номера, то далее слово MOV можно использовать так:



В более привычном формате эта команда выглядела бы как MOV A, B
Поскольку во всех командах, где необходимо указывать регистры, используется одна и та же интерпретация битовых полей, в ассемблере можно определить следующие слова:
A B C D E H L BC DE HL
A, B, C, D, E, H, L, BC, DE, HL,

Однако ассемблер процессора i8080 имеет интересную особенность, существенно облегчающую построение для него форт-ассемблера. Каждому типу команды соответствует уникальная мнемоника – например, загрузка в регистр непосредственного значения вместо MOV записывается как MVI (MoV Indirect – загрузить непосредственно). В ассемблере же процессоров x86 для всех типов команд загрузки используется запись MOV, которая может иметь больше десятка различных сочетаний параметров. Так же обстоит ситуация с другими группами команд. В итоге постфиксный ассемблер для процессоров x86 должен анализировать типы операндов, переданных на стеке для формирования кода операции. В отличие от этого, ассемблер, подобный ассемблеру для i8080, может определять тип команды и сочетание операндов, ориентируясь только на мнемонику.
Альтернативным подходом, обеспечивающим классическую префиксную запись команд, может быть введение отдельных наборов слов, ответственных за команды и отдельные группы операндов соответственно. При этом начало команды сбрасывает состояние внутренней машины ассемблера в исходное состояние, а машинный код генерируется после сбора транслятором информации обо всех требуемых операндах.
Например,



MOV – установка ассемблера в состояние «команда пересылки»; ассемблер ожидает два операнда
EAX, – команда «первый операнд – регистр EAX»
# – выделить следующий токен и рассматривать его как второй операнд команды – непосредственное значение; после получения второго операнда команда пересылки становится завершенной и может быть сгенерирован машинный код.

Нетрудно заметить, что быстрая разработка форт-ассемблера для процессоров x86 существенно затруднена наличием в этих процессорах разнообразных сочетаний аргументов команд. Все эти сочетания должны корректно распознаваться, недопустимые сочетания аргументов должны формировать точное описание ошибки, а от самого ассемблера требуется некоторый запас расширяемости. Например, команда MOV в процессорах 80486, Pentium и выше получила дополнительные варианты сочетаний операндов – добавились группы регистров DR и TR. Кроме того, для поддержки наборов MMX, 3DNow!, SSE и им подобных (в том числе и ожидающихся в будущем) ассемблер должен обладать существенной гибкостью. В итоге возрастание сложности и функциональной насыщенности форт-ассемблера приведет к тому, что он станет сравним по сложности разработки с обычным ассемблером, использующим классическую префиксную запись. Очевидно, что затратив подобные усилия, можно было получить и ассемблер с классическим синтаксисом, который был бы способен обрабатывать огромное количество существующих ассемблерных текстов. В то же время выгода постфиксного форт-ассемблера заключается как раз в простоте его разработки и адаптации к новым условиям.

Для нуль-операндного форт-ассемблера предлагается следующий синтаксис:

Группа операций Ассемблерная запись Постфиксная запись Пример
Пересылка данных MOV dest, src src->dest EAX->EBX
[EBP+4]->ECX
[EBX]->XMM0
1234 ->EBX
1234 [EBX+ECX*8+OFFSET]->F
Стековые операции PUSH reg PUSH_reg PUSH_EAX
POP reg POP_reg POP_EAX
Инкремент INC reg reg++ [STACK]++
AL++
AX++
EAX++
Декремент DEC reg reg-- EAX--
Сравнение CMP src, dest src==dest 1234 EAX==
AL==CL
ESI==EDI
Проверка TEST src, dest src??dest ESI??EDI
Инверсия NOT reg ~reg ~EAX
Смена знака NEG reg -reg -ECX
Логическое И AND src, dest src&&dest EAX&&EAX
1234 EAX&&
Логическое ИЛИ OR src, dest src||dest EAX||EAX
1234 EAX||
Логическое ИСКЛ ИЛИ XOR src, dest src~~dest EAX~~EAX
1234 EAX~~
Сложение ADD reg, reg/imm reg+= 1234 EAX+=
EAX+=EBX
EAX+=[EBP+4]
Вычитание SUB reg, reg/imm reg-= 1234 EAX-=
EAX-=EBX
EAX-=[EBP+4]
Умножение MUL reg *reg *ECX
IMUL reg I*reg I*ECX
Деление DIV reg /reg /ECX
IDIV reg I/reg I/ECX
Логический сдвиг SHR reg reg>> EAX>>
SHL reg reg<< EAX<<
Арифметический сдвиг SHRA reg reg>>> EAX>>>
Вращение ROR reg reg->> EAX->>
ROL reg reg<<- EAX<<-
Следующая группа имеет одинаковую запись для стандартного и постфиксного предстиавления
Безоперандные команды CLD STD CDQ CLI STI NOP IRET
Префиксы строковых операций REPZ REPNZ
Префиксы замены сегмента CS: DS: ES: FS: SS: GS:
Переход по регистру JMP reg JMP_reg JMP_EAX
CALL reg CALL_reg CALL_EAX
Условные переходы JC offset JC JA JAE JB JBE JC JE JZ

Арифметические FADDPP reg1, reg2 Fop F+
операции сопроцессора FSUBPP reg1, reg2 F-
FMULPP reg1, reg2 F*
FDIVPP reg1, reg2 F/

Рассмотрим исходный текст форт-ассемблера.


Приведенный выше фрагмент решает две задачи: управление памятью при размещении кода и организация работы с метками. Переходы явно разделены на переходы назад (адрес перехода уже известен) и переходы вперед (адрес перехода неизвестен, известно место, с которого делается переход). Объявление метки выполняется словом LABEL: ( например 1 LABEL: ). При этом текущий адрес добавляется в таблицу локальных меток, хранящуюся в массиве LOCALS[].
При объявлении новой метки может оказаться, что на нее уже имеются ссылки – объявленные ранее переходы вперед. В этом случае ссылки необходимо разрешить (resolve), т.е. вписать полученный адрес по всем запомненным ранее и зарезервированным для этой цели ячейкам. Эта операция выполняется словом ?RESOLVE-REF, которая получает на стеке номер только что объявленной ссылки и просматривает таблицу ссылок вперед на предмет наличия в ней ссылок на только что созданную метку. Каждая найденная ссылка сообщает адрес, куда необходимо вписать только что полученный адрес метки:



Приложения следуют

Стековые макросы выглядят следующим образом:



Необходимо обратить внимание на организацию команд перехода в данном ассемблере. Нетрудно заметить, что эти команды формируют код сразу после обработки соответствующего слова. После команды перехода необходимо использовать одну из двух команд перехода по меткам.

JMP 1 LABEL
JMP 1 FORWARD

Краткий FAQ, составленный по результатам обсуждения и эксплуатации форт-ассемблера

Q: Существует достаточное количество ассемблеров для x86, в том числе свободно распространяемых. В чем смысл разработки еще одного ассемблера, тем более с нестандартным синтаксисом?

A: Действительно, при разработке программного продукта, тем более инструмента, необходимо прежде всего уяснить цели такого проекта. Главный недостаток рассмотренного подхода – нуль-операндная запись не совместима ни с одной из распространенных форм ассемблерного представления команд. В то же время существуют и достоинства. Прежде всего, это простота разработки, позволяющая в короткие сроки добавить ассемблер к любому транслятору или проекту. Второе качество – независимость отдельных модулей, которая позволяет наращивать возможности, не вникая в тонкости внутреннего механизма разбора строк. Фактически нуль-операндный ассемблер имеет только один сколько-нибудь связный внутренний механизм – расстановка меток. Дополнительные команды могут быть введены всего одной строкой (при этом программист не обязан вносить изменения в какие-либо проверки корректности операндов и прочие вспомогательные процедуры). В текущей версии форт-ассемблера успешно поддерживаются специальные команды процессоров 80486 и выше, команды наборов MMX, SSE и SSE2. Любая команда из каких-либо будущих наборов также может быть легко добавлена в систему без изменения «движка» форт-ассемблера.
В итоге следует все же отметить, что подобный продукт есть скорее «личный инструмент» программиста, который позволяет быстро получать готовый код для разных платформ.

Q: Синтаксический разбор хорош тем, что он позволяет обрабатывать группы команд. Здесь же предлагается для каждого сочетания операндов завести свое слово в форт-системе. Это очень большой объем!

A: Да, все обстоит именно так. Тем не менее:
1) Число команд, включая различные сочетания операндов, исчисляется тысячами. Это не запредельный объем, учитывая то, что современные компьютеры оперируют уже мегабайтами кода. Добавление большого количества новых слов не замедляет работу форт-системы, поскольку ассемблерные операции добавляются в отдельный контекстный словарь, таким образом, список для просмотра не перегружается чрезмерно.
2) Для реальной работы достаточно всего нескольких сотен часто используемых команд. Это проверено на практике.
3) Отсутствие группировок команд делает форт-ассемблер легко адаптируемым к новым наборам команд, и легко портируемым на другие платформы.

Q: Подготовка большого количества команд «вручную» очень трудоемка. Синтаксический разбор как раз и призван облегчить этот труд.

A: Синтаксический разбор можно использовать для автоматической генерации исходного текста форт-ассемблера. Именно так были сгенерированы однообразные варианты команд – например, MOV reg, reg.

Q: Для освоения этого продукта необходимо изучить новый синтаксис и запомнить, какие команды поддержаны текущей версией ассемблера. Не замедлит ли это работу над большими проектами?

A: Данный продукт не предназначен для разработки больших проектов (хотя транслятор PM-Forth написан именно на нем). Его основное предназначение – обеспечить возможность использования ассемблерных вставок в обычных форт-определениях. Типичное применение подобных вставок – использование команд MMX, SSE/SSE2 и быстрый доступ к памяти, ликвидирующий лишние стековые перестановки.

от себя добавлю, что такой ассемблер не обязательно должен быть постфиксным
что и сделано в том ассемблере, что используется в СПФ4.
Единственно, там нет лишних имен.

У меня была идея написать асм основанный на словарях И даже инструментик для этого имеется уже
все могло бы выглядеть так:


а там достаточно MOV EAX, # 3E9C
ну и так далее

но по-моему, лучше даже псевдоассемблер заиметь

Code DUP
mov subtop, top
add sp, # cell
Next,
EndCode

Такие ассемблеры уже есть. Подчеркну, что в приведенном материале развивается именно идея постфиксности и того, как именно можно организовать ассемблер. Перспектива - софт-процессоры, которые можно делать быстро, и на которые псевдоассемблеров не напасешься. Это для x86 мнемоники уже устоялись, и можно смело закладывать более или менее развитые средства синтаксического анализа. А с псевдоассемблером не получается ни полного соответствия стандартам (например, # приходится ставить на непосредственные операнды... или заводить теги и усложнять анализ, приходя в конечном итоге к masm/tasm/fasm/nasm), ни быстрой разработки с получением работоспособного кодогенератора после двух страниц кода.

Постфикс даже в чем -то гибче, но запись его менее привычна:)
Для повышения удобства создания ассемблеров на новые архитектуры
можно ввести более-менее универсальные мнемоники и с помощью
их уже транслировать родные мнемоники.

Кстати, я и предлагаю вариант постфиксных мнемоник. Пока срабатывал на ~5 архитектурах.

Как ты сам заметил, этот вариант громоздкий...
Я, проникшись идеями Мура , предложил бы использовать к-нибудь минимальный форт типа MachineForth или тот, 4х битный в качестве такого ассемблера.
- в начале мало команд, они м. не покрывать все возможности используемого проца (особенно если x86)
+ расширяемый, нужные команды можно дописывать по необходимости, так сам Мур делает, хотя заявляет, что только 27...
+ для кодирования что твоего варианта, что предлагаемого нужно смотреть справочник кодов команд
+ можно сделать встроенную оптимизацию - см. ColorForth

- приходится использовать другой подход к программированию - и не асмовский, и не процедурный, а рекурсивно-фортовый
+ получаешь высокоуровневый расширяемый язык

- надо переписывать весь софт (если хочешь эффективной работы)
+ а все равно прийдется!

- надо иметь под рукой справочник кодов используемого проца
+ зато часть слов может использовать ранее определенные! - меньше работы при портировании

Это, кстати, уже не ассемблер а вычислительная машина в рамках некоей системы команд. А если надо сделать нечто новое из низкоуровневых определений или непосредственно машинных кодов? Ассемблер для процессора нужен в любом случае.

Я делал по другому: ассембемблер для 8086, две переменные dst и src, и слова типа AX BX CX, DX, , без запятой клали идентификатор в переменную src, с запятой в dst, для литералов взводился флаг (#), а каждая команда типа MOV анализиовала эти переменные и компилировала команду (я использовал тупую серию IF THEN, иногда вложенные). В конце каждой команды выболнялся сброс переменных в значение по умолмению, соответствующее литералу-адресу. Самое сложное -- метки.

Такой подход использовался по меньшей мере 10 лет назад. Здесь я как раз и показываю, как можно избежать постоянного анализа сочетаний параметров.

Да, получается ассемблер виртуальной машины. И в кодах реальной машины делаются команды этой виртуальной.

Все равно смотреть справочник кодов - хоть при реализации ассемблера, хоть в этом нашем случае...

Да,его иметь желательно. Но даже если и нет, можно обойтись таким ассемблером для ВМ и записыванием кодов вручную.
Только это занимает мноооого времени!! Я вот на PERL-е так несколько ассемблеров сделал...
Сдел над каждым по нескольку дней... Правда, проверял каждую команду, как работает почти во всех режимах...
Но, что обидно, даже при переходе к другой разрядности 8-16-32 (не говоря о другом проце) прийдется много проверять поновой...


Это в Форте как раз неплохо сделано. А для ссылок вперед можно и переменные заводить в крайнем случае...
Кстати, если программировать в рекурсивно-фортовом стиле, много ссылок вперед и не будет, переменных хватит. А можно еще и таблицы сделать...

Не, это уже другая тема. Нельзя однозначно решить, что вот, дескать, мы обойдемся виртуальной машиной. Кто-то обойдется, кто-то нет. И вот для тех, кто нет, написана статья. На то и конференция - очерчивать круг проблем и пути решения, а не решать сразу и навсегда, кому что надо. Можно рядом выложить статью по ассемберу виртуальной машины - будет другой материал.

Да. Другое возможное решение, другая методика. Отделение от реального ассеблера вообще! И для них же можно к ВМ дописывать комады!
Самое серьезное неудобство ВМ-АСМа - трудно быстро добавить непредусмотренную ранее команду - надо в справочник проца смотреть! Но обычно при реализации твоего варианта расписывают все возможные команды...
Так что мое предложение можно рассматривать как врЕменное решение, когда (или пока?) нет твоего...
А твое удобнее и полнее... Если бы у меня оно тогда было...

У меня была поделка на уровне

: + -> --> (+) <- ;

Здесь -> - забрать со стека в первый регистр, --> - во второй, (+) - сложить "арифметические" регистры, <- - отправить регистр на стек. Из таких вещей можно было набрать команды Форта для разных архитектур, но по размышлению стало ясно, что возиться с лишней сущностью себе дороже. Можно и справочник по командам посмотреть, особенно с учетом того, что хорошие вещи с бухты-барахты все равно не получаются.