Прошу подсказать какую-нибудь информацию о написании простешего транслятора ассемблера( по типу того что встроен в debug.exe). Я, конечно, понимаю что принципы построения такого транслятора можно позаимствовать из книг по написанию компиляторов ЯВУ.. но(!) Первым делом, я начал читать книгу Ахо и Ульмана "Книга Дракона", но, к моему глубокому сожалению, вследсвие моего "не программерского" образования мне она показалась тяжеловата, читал всякие статейки, коими полон интернет,но в них ничего толкого, нужного мне не нашел . К тому же, компиляторы, которые описаны в таких доках генерируют ассемблерные листинги сомнительно качества, мне естественно нужны полноценные исполнимые файлы. Возможно, у вас есть какие-то свои наработки, которыми можете поделится, либо имеются лекции, лабораторные работы по данному вопросу. Проще говоря, все что можете посоветовать, чем можете поделится, всему буду благодарен. PS. конечно, вы можете поорать:"какой ты тупой, не можешь разобраться в такой фигне!", и т.п., но давайте побережем свои нервы и время, и будем давать советы конкретные. Заранее благодарен.
начал читать книгу Ахо и Ульмана "Книга Дракона" это ты молодца - лучше книги я еще не встречал! если надо для жирафов, то могу кинуть учебное пособие "Основы теории построения компиляторов", оглавление в аттаче, 100 стр., ~1.3Мб, пиши куда... з.ы. посмотри еще в разделе документы Assemblers and Loaders (ничего) и Linkers and Loaders (так себе) _1451004341__summ.doc
Max Кидай книжку, лишней не будет , правда у меня у самого этого добра по ЯВУ накопилось %). SeDoYHg(собака)list.ru Хрен его знает, что я за животное , скорее свинья, столько уже земли перерыл, в поисках вкусных и полезных корений .
ты возьми исходники gas и медитируй над ними что-то мне подсказывает, что flex+bison тебе должно хватить для написания транслятора
slow, only tomorrow, exactly today maybe it'll be better to place it in doc section? Volodya, what do you think about it?
IMHO "Книга Драгона" полезна, но необязательна для написания ассемблера. Живой пример тому - RosAsm. традиционный ассемблер имеет довольно простой синтаксис, поэтому использование генераторов вроде flex+bison IMHO излишество, это быстрее кодится вручную. НО нужно различать ассемблер и макроассемблер. Во 2м случае нужен препроцессор, это по сути отдельный модуль. Хотя наиболее сложная, на мой взгляд, часть ассемблера - это сам кодогенератор x86. Проблема в том, что многие команды можно кодировать разным количеством байт, отсюда выбор: или будет простой неэффективный генератор, делающий все jump'ы near, или сложный многопроходный как в fasm. Поэтому важно сразу определиться с синтаксисом. Например, если обязать указывать размер операндов (т.е. генерировать короткий переход только при явном указании jmp short) то можно заметно упростить реализацию. Хотя остаются ещё команды вида add, sub, xor и т.п. особенно варианты вроде: Code (Text): foo: add edx, bar-foo bar: например, MASM не способен (!) эффективно ассемблировать такой код. Для простейшего транслятора как ы debug IMHO достаточно Opcodes Book by the Svin и мануалов от intel - там даже таблицу символов строить не нужно, кодировать команды только.
slow,MrHammer ушло S_T_A_S_ НО нужно различать ассемблер и макроассемблер сама книга замечательна тем, что расписывает некоторые приемы оптимизации кода, что важно для макроассемблера (циклы, условия и т.п.) мне она даже больше понравилась как мануал по реинжинирингу - определение циклов, анализ графов и т.п.
infern0 может на васм закинешь да я предлагал - maybe it'll be better to place it in doc section? Volodya, what do you think about it? (инглиш, т.к. писал с мобилы) Я бы тоже глянул тогда пиши куда, я кину...
2 SeDoY Есть 5-метровый архив на эту тему (там все перемешано, но м.б. что-то пригодицца). Порезать или так и отправить?
const Кидай все , ящик то безразмерный =). Почитаю на досуге. Max Спасибо за книжку, буду читать. S_T_A_S_ Согласен полностью, что самая важная часть (не знаю как точнее сказать) в асссемблере это именно генератор кода. Ибо каким бы не был крутом препроцессор, если код выходит кривой то грошь цена такому ассемблеру. дебаг я привел как самый примитивный вариант и первый шаг на пути к полноценному транслятору =). Вспомнилось вдруг , переписывал я примеры с ТАСМА на ФАСМ, какого же было моё удивление, когда я сравнил два экзешника , сделанные ТАСМомо и ФАСМом(по одному исходнику) . То что выплюнул ТАСМ меня просто поразило (на повал), откуда-то появилась куча нопов (именно КУЧА!!!), про друкие аспекты "оптимизации" можно и не говорить %). Так что кодогенерация самый важный и ответсвенный момент ( ИМХО самый важный). PS и сгинет всяка нечесть комерционная(мелкософто турболетная =), и приде век чистого и открытого для всех великого Языка =)
Хм, странно немного , рассчитывал, что будут хоть какие-нибудь исходники и информация именно по ассемблеру, все таки, я думал, что этим заморачивались многие, ну да ладно, на нет... будем сами кумекать. Спасибо всем кто откликнулся, тема не закрыта, думаю, вопросы у меня еще возникнут, есть кому на них ответить =)? (вопрос все таки риторический, наверно)
А что ты хотел ? =) Давай посчитаем известные opensource проекты. на асме написаны fasm & rosasm. из них 2й не оптимизирует размер команд. gas и nasm написаны на Си и, при этом, как я понял, имеют теже недостатки, что и rosasm. Остаётся один ассемблер !!!!! Это выглядит довольно странно на фоне высказываний Хайда, что генерация кода - пара пустякофф. почему-то многие компиляторы при этом являются fron-end для fasm. НаписАть функцию генерирующую опкод из мнемоники - не слишком большая проблема: делаем табличку, где каждой мнемонике соответствует адрес ф-ции обработчика. Мнемоники можно сгрупировать. например, однобайтные будут обрабатываться одной и той же ф-цией, но тогда в табличку нужно будет добавить ещё параметр для неё - сам опкод. 2я группа - команды требующие один операнд: div, mul, neg, not, idiv. первый байт у них одинаков 0xF7/0xF6, в таблице хранить ModR/M биты (6, 4, 3, 2, 7 соответственно) остальные биты 2го байта и младший бит 1го вычислять исходя из операнда. таким образом можно разделить на группы почти все инструкции. Сложность в том, что размер опкода x86 может быть различен для одной мнемоники. Причём его размер зависит не только от самой этой мнемоники, но и от тех мнемоник, которые вокруг! Практически все реализации (кроме fasm) закрывают глаза на этот факт. fasm решает эту проблему за счёт множества проходов. я думаю дроугого пути нет - backpatсhing здесь мало поможет. Однако, существуют ситуации, когда минимальный размер опкода не является оптимальным. Вот как быть здесь? AFAIK это ещё никто не решил :-(
Я много чего хотел . А если серьезно, то думал "позаимствовать" из путевых исходников анализ (хотя копаясь в исходниках ФАСМА понял, что гиблое это дело, без комментраиев тяжко будет понять что к чему)и занятся более основательно генерацией кода, так как для меня это более интересное и важное занятие. Ну да ладно, "сами с усами" =). Ктсати, Юров в своем практикуме(у меня первое издание) описывает создание препроцессора для поддержки ХММ-команд, но что то я его не нашел, ни на дискете ни на сайте издателя , хотя в книге написано, что он есть. Видать дюже секретный сырец .
Ну дык возьми и пиши кодогенератор сразу. Без предварительной обработки текста это вполне можно сделать приняв несколько упрощений. Например, фиксированный формат строки, т.е. мнемоника располагается строго в начале строки, далее через один пробел операнд (если он есть), потом второй. Ошибки синтаксиса не обрабатывай. ещё больше можно упростить, отказавшись от операторов размерности dword, byte и т.п. объединив их с мнемоникой например так: MOV1 [0],0 ; это аналог mov byte[0], 0 MOV4 [0],0 ; это аналог mov dword[0], 0 когда напишешь для всех основных инструкций, можно будет думать о таблице символов и количестве проходов.. или "да ну его нах" по ходу дела начнут появляться вопросы, а на них ответы получить будет проще, чем на общие. > Может он его вообще не писАл? А что, imho вполне реально :-/
Была такая мысль, но она показалась мне кощунсвенной, но, видимо, это для меня будет оптимальным решением... цитата из практикума: Его (препроцессор, мое прим. описание содержит множество технических подорбностей, не относящихся к предмету книги. По этой причине программа-препроцессор с соответсвующими пояснениями деталей реализации вынесена на дискету, прилагаемую к книге. Вот так вот ...
SeDoY > Почему, потом можно будет немного модифицировать и подавать на вход то, что выдаёт препроцессор + парсер. конечно, хорошо сначала досконально разобраться в теории, всё спланировать, но на это может уйти сверхмного времени. зачем делать препроцессор который будет выкидывать лишние пробелы, если это не , его можно будет реализовать и потом. > У меня есть книга + дискета, и я читал это перед своим постом. Просто какой ему смысл что-то кодить, когда можно и не делать этого, я вот например только что с твоих слов об этом узнал =)
