Пишем интерпретатор трехадресного кода

[@shushu]

Посмотреть всё это в работе можно здесь.

Page does not exist! Read the Full Documentation
Instructions for setting up username.github.com *

Да и было бы лучше что бы вы пример запостили куда-то вживую (например pastehtml.com/), а не собирать пример самому из скачаных исходников.

[@mark_ablov]

там не нужно собирать, github предоставляет так же возможность публикации статик-страниц.
Но как-то не стабильно работает эта функция, сразу не всегда открывает.

[@JokerOfGod]

а micromodal вам больше нравиться нежели jqm?)

[@mark_ablov]

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

[@alman]

Спасибо. Интересная статья. Разрешите задать несколько дилетантских вопросов?

Реально ли (теоретически) описать грамматику для ваших анализаторов, чтобы получился интерпретатор С++? Хотя бы без темплейтов.

Какая пропасть лежит между «деревом исходного кода» и объектным файлом для x86 формата Elf/WinPE? То есть если вообще отказаться от любой оптимизации, насколько сложно из дерева построить объектный файл? Есть ли такие планы на будущее?

P.S. Одно время я искал русскоязычных разработчиков компиляторов, нашёл, да не тех — один умелец, судя по всему, потерял интерес к своему проекту и пропал из видимости, второй вёл оживлённую переписку, но когда дело дошло до дела — сказал, что он уже давно живёт в США и пишет мемуары, а третий вообще не нашёл нужным общаться.

P.P.S. Этот вопрос несколько не по теме. Насколько реально создать линкёр, который мог бы связывать объектные файлы разных форматов, а именно Elf и WinPE? И чтобы формат выходного файла чтобы задавался ключом.

[@mark_ablov]

Реально ли (теоретически) описать грамматику для ваших анализаторов, чтобы получился интерпретатор С++? Хотя бы без темплейтов.

Вполне, только само собой не LR(0)-анализатор используется, да и большую часть кода генерит «компилятор компиляторов» — yacc.
Если интересно — ftp.iecc.com/pub/file/c++grammar/

Какая пропасть лежит между «деревом исходного кода» и объектным файлом для x86 формата Elf/WinPE? То есть если вообще отказаться от любой оптимизации, насколько сложно из дерева построить объектный файл?

После синтаксического анализа идёт этап семантического (контекстного), который работает не с конкретной синтаксической единицей, а со всем кодом (например, проверка типизации, если объявили int a, а через 10 строк записываем туда float). После этого чаще всего происходит оптимизация (возможно перед оптимизацией перевод во внутренний промежуточный язык, в качестве которого можно использовать и описанный в статье). Далее идёт кодогенерация, это процесс получения байт-кода, понятного машине (виртуальной, а-ля Java, или реальной — x86, arm, ...). А уже потом приходит время «форматтера» — модуля, который собирает получившийся байт-код в один из форматов, ожидаемый на выходе (объектные чаще всего, но можно генерировать сразу в исполняемый, как делает например компилятор fasm). Такие дела. Для простейшего языка, наподобие трехадресного, кодогенерация проста, а сложность форматтера зависит от сложности выходного формата, что логично.

Есть ли такие планы на будущее?

Именно ELF/PE не особо интересует в том плане, что существует довольно большое число открытых исходников и компиляторов, и форматтеров. Достаточно умеючи выпилить их из сорцов и использовать в своих проектах.

P.P.S. Этот вопрос несколько не по теме. Насколько реально создать линкёр, который мог бы связывать объектные файлы разных форматов, а именно Elf и WinPE?

Иногда возможно, если присутствует необходимая информация, например таблица релокации.
Чтоб точно ответить на вопрос нужно внимательно изучить и сравнить оба этих формата.

[@humbug]

switch ©
Ну хабрапарсер как всегда…

[@mark_ablov]

fixed.