У меня было желание написать небольшую статью понятным языком (а не книгу — мануал) и рассказать про принцип работы транслятора на примере написанного мной проекта.
Про алгоритмы разбора, разного рода анализаторы и способы записи грамматики люди могут прочитать и так.
Но, согласитесь, приятно прочитать о чем то сложном в простой форме.
Не все пишут на FPC. Моей задачей было рассказать по какому принципу можно написать транслятор, а не закидать читателя кучей кода (!), который возможно и не каждый поймет даже, потому что не будет сидеть разбираться в нем (!).
Считаю, что в статье довольно подробно описаны основные этапы реализации транслятора.
Полный код доступен в репозитории (!).
Примеры входных и выходных текстов тоже (!).
В качестве промежуточного представления в конечном счете генерируется листинг на ассемблер-подобном языке (!), который я описывал в предыдущей статье, чем вам не промежуточное представление?)
Разве моя практика плоха, чтобы её прививать новичкам?(
Цель написания транслятора была поставлена и была успешно выполнена. Да, не самым оптимальным способом и транслятор работает медленнее, чем мог бы. Но тут есть и положительная сторона — разработка транслятора шла в быстром темпе, благодаря такой архитектуре. Да и разве критична скорость трансляции, если в конечном итоге приложение собирается в независимый формат и будет выполняться на ВМ.
Спасибо за комментарий, теперь, если заинтересованные люди увидят его и не поймут половину аббревиатур — они полезут в гугл и прокачают свой мозг.
Простой запуск с параметром запускает выполнение приложения. Что касательно готовых реализаций — считаю более оптимальным решением написать ВМ полностью самому, чтобы иметь власть над каждым куском кода.
Да особо ничего новаторского нету. Но архитектура спроектирована в ходе моей работы над проектом, так что можно считать, что она новая. Из новаторского можно разве что сборщик мусора отметить. Он реализован отлично от реализаций в других языках.
1. Да. И реализуется в ручную. При этом, разработчик на 200% уверен в каждой переменной и объекте, что они не пропадут в никуда при вызове сборщика мусора, если он не написал соответствующий код.
2. Мне кажется, что увеличение в 2 раза размера стека каждый раз может привести к Access Violation.
Object Pascal — прекрасный язык общего назначения. Транслятор мне на нем было писать одним удовольствием, спасибо удобной реализации строк в языке. На плюсах я бы возился гораздо дольше. Да и переписывать нет смысла проект. Хочу в качестве бекенда LLVM взять. Позже соответственно и статью накатаю, если разберусь с этим.
rem() вызывается для классов, чтобы освободить память из под структуры класса. Это генерируемый деструктор класса.
Стек не используется таким образом. Он используется для вычислений, вызовов и прочих операций но почти всегда он остается пустым по завершении операции.
Поиск ошибок в коде — довольно сложный процесс. Возможно в будущем я напишу более хитрый код для этого.
Про алгоритмы разбора, разного рода анализаторы и способы записи грамматики люди могут прочитать и так.
Но, согласитесь, приятно прочитать о чем то сложном в простой форме.
Не все пишут на FPC. Моей задачей было рассказать по какому принципу можно написать транслятор, а не закидать читателя кучей кода (!), который возможно и не каждый поймет даже, потому что не будет сидеть разбираться в нем (!).
Считаю, что в статье довольно подробно описаны основные этапы реализации транслятора.
Полный код доступен в репозитории (!).
Примеры входных и выходных текстов тоже (!).
В качестве промежуточного представления в конечном счете генерируется листинг на ассемблер-подобном языке (!), который я описывал в предыдущей статье, чем вам не промежуточное представление?)
Разве моя практика плоха, чтобы её прививать новичкам?(
Цель написания транслятора была поставлена и была успешно выполнена. Да, не самым оптимальным способом и транслятор работает медленнее, чем мог бы. Но тут есть и положительная сторона — разработка транслятора шла в быстром темпе, благодаря такой архитектуре. Да и разве критична скорость трансляции, если в конечном итоге приложение собирается в независимый формат и будет выполняться на ВМ.
Спасибо за комментарий, теперь, если заинтересованные люди увидят его и не поймут половину аббревиатур — они полезут в гугл и прокачают свой мозг.
Для этого кодировку консоли менять нужно. Есть winapi для этого соответствующий, который я ещё в либу языковую не портировал.
Ставите себе Lazarus с офф сайта, можно последний. Собираете все проекты из репозитория.
Нужно собрать:
Все должно работать.
Ну. Я не шибко уж красноречив на названия.
Третья статья (ч. 2) уже на подходе ;)
Надеюсь, что проделанная работа будет оценена обществом по достоинству.
Простой запуск с параметром запускает выполнение приложения. Что касательно готовых реализаций — считаю более оптимальным решением написать ВМ полностью самому, чтобы иметь власть над каждым куском кода.
Сравните перечень поддерживаемых платформ у того же FPC и у C#)
2. Мне кажется, что увеличение в 2 раза размера стека каждый раз может привести к Access Violation.
Object Pascal — прекрасный язык общего назначения. Транслятор мне на нем было писать одним удовольствием, спасибо удобной реализации строк в языке. На плюсах я бы возился гораздо дольше. Да и переписывать нет смысла проект. Хочу в качестве бекенда LLVM взять. Позже соответственно и статью накатаю, если разберусь с этим.
rem() вызывается для классов, чтобы освободить память из под структуры класса. Это генерируемый деструктор класса.
Стек не используется таким образом. Он используется для вычислений, вызовов и прочих операций но почти всегда он остается пустым по завершении операции.
Проект без проблем собирается под unix системы.
Похожее реализовано на уровне транслятора.