Создание (проектирование) собственного компилятора и/или языка

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

 

например, с этого можно начать:
http://cf.viplast.ru/programming/theory/algebra/algebra.shtml

 

Поговорил со своим преподователем.Он посоветов начать с малого а именно описать хотябы ситаксис короче не буду даваться в подробности суть в том ячто нужно использовать теорию конечных автоматов. И он еше назвал одну вещь но не помню название толи БНф толи еше как то.Может кто знаетСкажите пожалуйста полное название остальное вроде помню :/

 

DoubleOn
статья в вики

 

varnie
точно!спасибо большое!А то так бы и бросил)

 

уж лучше не бнф, а ебнф. это антл, коко итд. мне больше коко, тк он проще и нагляднее. коко инее порты на кучу языков, очень прост в изучении (ман в 5 стр). в поставке идут синтакс-три нескольких яву. также несколько полных движков - от простого калькулятора, до полного интерпретатора простого оберонподобного (пасподобного если угодно) языка.
бэкенд, тут я присоединюсь к Inv лучше использовать койнить готовый. бэкенд даже посредственного качества для х86 архитектуры - задача непростая.

Blackbeam

??

 

_basmp_
если я понял правельно Blackbeam
он имел ввиду то что что происходит на Бацике.и его интерпретаторах. :rolleyes:

 

Посмотри
Джек Креншоу. Давайте создадим компилятор!
http://www.kulichki.net/kit/crenshaw/crenshaw.html

 

Статья не зачётная. Слишком много ляпов.
Вот к примеру:

Написана полная ерунда.
Не компилируя код (не переводя мнемоники в машинный код) невозможно определить адреса меток.
Код компилируется уже на первом проходе, вместо неизвестных адресов пишется любое число и составляется карта неизвестных адресов (которые надо править).
На втором проходе вычисляются правильные адреса и правятся адреса в командах в соответствии с созданной на первом проходе картой.

 

cppasm

Вообще-то можно. Определить длину инструкции без её компиляции - совсем не проблема. Насколько эффективна такая операция или нет - отдельный вопрос. Экономия памяти при предварительном сборе информации о метках в ассемблерном тексте могла быть существенной для 8-разрядной машины с 16-32-64 килобайтами ОЗУ.

 

Да ну, и как? Это ж не дизассемблер длин, а наоборот надо
Чтоб узнать длину, надо знать машинный код.
Ну или по таблице, но эффективность будет...
Вот скажи мне размер "jmp some_label" или "xor eax,eax".
Куча будет ответов - в машинный код можно по разному перевести.

 

cppasm

То, что машкоды x86 сочинял долбанутый на всю голову человек, ещё не значит, что везде такой же бардак. На более других процессорах всё было намного проще.

Когда надо втиснуть в 34 килобайта ОЗУ текст программы и откомпилированный результат, под "эффективностью" понимается не время компиляции, а прожорливость этого процесса до памяти. Я ещё помню, как у меня все метки в проге выглядели как L1, L2, L3 и т.д., потому что короткие имена меток уменьшали размер исходника и таблицы меток. И если бы ассемблер попытается отжать под свои меточно-ссылочные нужды драгоценные 10 килобайт памяти, он был бы немедленно и совершенно справедливо послан программистом на... .

А хрен его знает, я x86 в уме не ассемблирую. А вот аналоги с Z80 помню наизусть: jp xx: 3 байта; xor r,r:1 байт.

 

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

Но рассматривается ведь общий случай.
Да, для RISC с постоянной длинной команды всё чуть проще, но это частный случай.

Для x86 аналогично, но есть разные варианты кодирования.
К примеру jmp бывает short, а бывает near в зависимости от адреса назначения.

 

cppasm

Ну не знаю, у меня после Z80 долгие годы при разглядывании опкодов x86 постоянно возникала мысль "и вот нахрена бы такие извращения?" Когда на 16-разрядный процессор с 8-разрядными потрохами образца 70-х годов начинают навешивать то, для чего он не был предназначен, ничего иного, в общем-то, получиться и не могло.

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