Компиляторы *

Недавно на хабре появилась неплохая статья про вычисление N-ного числа фибоначи за O(log N) арифметических операций. Разумный вопрос, всплывший в комментариях, был: «зачем это может пригодиться на практике». Само по себе вычисление N-ого числа фибоначи может и не очень интересно, однако подход с матрицами, использованный в статье, на практике может применяться для гораздо более широкого круга задач.

В ходе этой статьи мы разберем как написать интерпретатор, который может выполнять простые операции (присвоение, сложение, вычитание и урезанное умножение) над ограниченным количеством переменных с вложенными циклами с произвольным количеством итераций за доли секунды (конечно, если промежуточные значения при вычислениях будут оставаться в разумных пределах). Например, вот такой код, поданный на вход интерпретатору:

loop 1000000000
  loop 1000000000
    loop 1000000000
      a += 1
      b += a
    end
  end
end
end

Незамедлительно выведет a = 1000000000000000000000000000, b = 500000000000000000000000000500000000000000000000000000, несмотря на то, что если бы программа выполнялась наивно, интерпретатору необходимо было бы выполнить октиллион операций.

Сейчас с уверенностью можно утверждать, что времена самописных C++-парсеров постепенно отходят в прошлое. На сцену медленно, но неумолимо выходит clang — полноценный C++-фронренд и компилятор, предоставляющий своим пользователям богатое API. С помощью этого API можно распарсить исходный текст на C/C++/Objective C, и вытащить из него всю необходимую информацию — от простого лексического значения токенов, до таблицы символов, AST-деревьев и результатов статического анализа кода на предмет всяких разных проблем. В связке с llvm и при сильном на то желании C++ можно использовать в качестве скриптового языка, парся и исполняя C++-программы «на лету». В общем, возможности перед программистами открываются богатые, надо только понять — как ими правильно воспользоваться. А тут, как это не редко случается, и начинается самое интересное.

Уважаемое сообщество, я хочу рассказать вам о языке программирования Gentee. Я уверен, что вы о нем ничего не слышали, но это не новинка. Первая рабочая версия компилятора увидела свет в 2008 году, а в конце 2010 была выпущена последняя на данный момент 3-я версия. Gentee является open source проектом и распространяется под MIT лицензией, то есть без всяких условий и ограничений. Кроме меня над компилятором, библиотеками и всей документацией работал еще один человек. В начале я хочу написать об истории возникновения языка. Начиная с 2000 года я работал над инсталляторами, в которых пользователь мог строить сценарии из определенных команд. То есть, каждая команда из параметров на форме должна была конвертироваться в код на каком-то языке, который можно было бы компилировать в байт-код и создавать исполняемый файл. Начинали с примитивного языка, но в конце концов решили сделать язык широкого применения. Основные требования были следующие: быстрый компилятор, легкая работа с Windows API, маленький размер движка виртуальной машины, лаконичный и понятный синтаксис, возможность использования компилятора и виртуальной машины из любого языка программирования. На языке C был написан компилятор в байт-код и виртуальная машина. Gentee.dll (компилятор и ВМ) занимает всего 112 КБ и может быть включена в любой проект, которому требуется встроенный язык программирования. Программа на Gentee может быть выполнена сразу после компиляции или можно создать исполняемый файл с байт-кодом и вшитой виртуальной машиной.

22 мая состоялся релиз LLVM 3.1, семейства компиляторных инструментов, построенных на модульной основе. Проект активно развивается как альтернатива GCC такими компаниями, как Apple и Google.

Наиболее заметные изменения включают в себя улучшенную поддержку нового стандарта C++'11 Clang'ом (включая лямбды, списки инициализации, константные выражения, пользовательские литералы и атомики); появление AddressSanitizer — инструмента для динамического отлова ошибок работы с памятью; серьёзные улучшения времени компиляции и появление новых фич для ARM архитектуры; заметно улучшенная поддержка архитектуры MIPS (включая MIPS64).


Для тех, кому интересны подробности — добро пожаловать под кат.

Детерминированный конечный автомат можно использовать для реализации очень быстрого способа разбора входной последовательности. Требуется всего один проход по входной последовательности, и минимальные действия на каждом шаге. К сожалению эта модель имеет ограничения — не всегда возможно построить ДКА, для имеющегося Недетерминированного конечного автомата (регулярного выражения, грамматики). Или даже если возможно построить, автомат может иметь слишком большое число состояний.

Тем не менее я решил попробовать создать парсер для HTTP запроса на основе ДКА. Основная задача не просто проверить корректность HTTP запроса, а именно выделить во входной строке элементы соответствующие определенным значениям полей HTTP запроса. Автомат должен генерироваться из BNF правил (разбросанных по) RFC2616. Реализовано все на C#, автомат на выходе тоже на C#. Хотя понятно что когда автомат готов, сгенерировать его на любом языке, в любом виде не проблема.

Сегодня ночью вышел долгожданный GCC 4.7, выпуск которого приурочен к 25-летию проекта.

Долгожданным этот выпуск является прежде всего для программистов C++, так как несет с собой обширную поддержку нового стандарта С++11.

Введение

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

Дабы задать контекст, сообщу, что грамматика для анализа — это ECMAScript, так же известный как JavaScript. Конкретная спецификация — ECMA-262, редакция 5.1 от июня 2011 года.

Предисловие

Добрый день.
Это вторая часть статьи про написание своего генератора LALR-анализаторов. В этой части я расскажу про эволюции от примитивных восходящих синтаксических анализаторов до наиболее актуальных, хотя и не шибко новых, LALR-парсеров. Тем, кто не читал первую статью (ссылки — снизу), советую прочесть хотя бы первую половину последнего раздела. О том небольшом фрагменте кода я буду упоминать несколько раз.

В комментариях к прошлой статье несколько человек интересовались моими мотивами в написании своего компилятора компиляторов. К сожалению, они в этой статье не найдут ответов на этот вопрос. Не скрою, изначально я планировал написать статью без особой теории, но с оправданием задач и целей, ради которых я начал писать генератор, да и хотел поделиться нюансами и особенностями реализации. То есть по объему это довольно прилично: несколько экранов. Но затем я решил всё же описать базовую теорию популистским языком, поэтому статья разрослась до трех частей. Таким образом, дабы не ломать логику изложения, я сначала расскажу про LR/SLR/LALR-анализаторы, а завтра опубликую заключительную, и, думаю, самую интересную часть.

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

Теперь, писать парсер больше не нужно. Модифицированный компилятор gcc анализирует ваш код и выдает описание всех пространств имен, типов, классов и функций, встреченных в программе. Данные выдаются в формате XML и в принципе готовы для дальнейшего автоматического анализа и обработки.

Для разбора XML данных, полученных от gccxml, пригодится библиотека pygccxml. Это не просто ридер формата gccxml — библиотека предоставляет интерфейсы для изучения собранных метаданных; в частности есть готовые функции, отвечающие на вопросы вроде «совместимы ли типы T₁ и T₂?» или «наследует ли класс C₁ от C₂?». Библиотека написана на языке Python.

В качестве хобби последние несколько месяцев я разрабатываю парсер языка PHP с помощью ANTLR. Сам проект для меня скорее просто Just for fun, но в ходе его реализации у меня, разумеется, возникали сложности. Тут сказывается как особенность языка PHP с полным отсутствием спецификаций, так и ограничения алгоритмов LL(k).

В этой статье я бы хотел поделиться техническими решениями и некоторыми хитростями в реализации парсера и процедуры его тестирования. Данная статья будет полезна тем, кто хочет подробнее разобраться в использовании средства ANTLR v2.

Введение, или зачем нужны синтаксические анализаторы

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

Эта часть посвящена базису, общей теории computer science. Возможно, что это даже преподаётся в школах/вузах России. Самая мякота пойдет со второй части.

Итак, зачем же кому-то может понадобиться писать парсер и что вообще это такое? Парсер — это код, который наделяет входящий набор символов семантическим смыслом. То есть, происходит анализ этих символов, и на основе этого анализа программа понимает как интерпретировать эти буквы и цифры. Простой пример — «1+2», после или во время процесса парсинга знак "+" это не просто символ плюса, но обозначение бинарноого оператора сложения, а в "+3" это унарный оператор знака числа. Большинству людей это очевидно, машине — нет.

Парсеры используются всюду — в Word'e для анализа приложений, словоформ, формул, etc; практически на любом сайте при валидации входных данных: email'а, телефонного номера, номера кредитки; конфигурационные файлы; сериализованные данные (например, в xml); во многих играх — скриптовые ролики, скрипты ИИ, консоль. В общем, это неотъемлемая часть computer science.

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

coco/r генератор компиляторов и трансляторов, который по атрибутной грамматике генерирует сканер (лексический анализатор) и парсер (синтаксичсекий анализатор). Сканер строится как детерминированный конечный автомат, а парсер — рекурсивным спуском.

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

При создании интерактивных приложений очень часто приходится делать выбор между двумя альтернативами: desktop приложение под Windows или веб-приложение, работающее в браузере. Основной девиз проекта p2js — «Один исходный код — две платформы».

Привет, Хабрахабр!

Введение

В данной статье, я, как и обещал, продолжу описание разработки компилятора для языка Cool, начатое в этой статье.

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

Введение

Здравствуй, уважаемый хабраюзер.Я хотел бы тебе представить материал о практическом создании компилятора, который будет транслировать код, написанный на языке Cool, в код виртуальной машины CIL (Common Intermediate Language) под платформу .NET.Данный материал я решил разбить на две части из-за лени все сразу это описывать

В первой части будет описан процесс написания грамматики с учетом приоритетов операторов в среде ANTLR, а также генерации лексера и парсера под язык C#. Также в ней будут рассмотрены подводные камни, которые встретились у меня на пути. Таким образом я постараюсь хоть кому-нибудь сэкономить время (может быть для себя в будущем).

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

1 декабря состоялся релиз LLVM 3.0 (Low Level Virtual Machine) — «инфраструктуры для компиляторов», которая генерирует платформонезависимый оптимизированный байткод низкого уровня (см. обзор на Хабре). LLVM используется в том числе в официальных средствах разработки для Mac OS X и iOS.

С момента выхода LLVM 2.9 прошло шесть месяцев, новшеств довольно много, в том числе новый «жадный» аллокатор регистров. Он применяет интересные способы оптимизации и способен значительно улучшить производительность кода.

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

Я сам долгое время считал, что создание компиляторов — это удел элиты, а простому смертному программисту не постичь этой науки. Попробую доказать, что это не так.

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

Задачей лексического анализа является разбить входную последовательность (в моем случае код на языке «Паскаль») на слова и лексемы.

Для начала я создал 5 типизированных листов для хранения данных, а именно: идентификаторов, констант, ключевых слов, разделителей и свертки. Также необходим массив разделителей

static char[] limiters = {',', '.', '(', ')', '[', ']', ':', ';', '+', '-', '*', '/', '<', '>', '@'};

и массив ключевых слов. Я ограничился одиннадцатью ключевыми словами, так как статья написана как начальный пример реализации лексического анализа языка «Паскаль» на языке C#.
Итак, массив ключевых слов:

static string[] reservedWords = { "program", "var", "real", "integer", "begin", "for", "downto", "do", "begin", "end", "writeln" };

Моему брату было 9 лет, и он очень хотел научиться программировать. Я долго думал, что бы ему такое предложить. Большинство начинало с Турбо-Паскаля. Но так как на втором курсе примата мы проходили компиляторы, то я решил написать собственный компилятор.

Предполагалось, что компиляция будет идти в байт-код, который затем будет исполняться виртуальной машиной. Язык предполагалось сделать похожим на Турбо-Паскаль, только проще.

В процессе написания я слишком увлёкся и получилось не совсем то, что изначально предполагалось (язык программирования для обучения). Нет, синтаксис языка предельно простой, с этим всё в порядке. Для обучения его вполне можно использовать, только у него два недостатка:

1) Нет литературы для обучения. Есть только список файлов с примерами.
2) Я думаю, некоторые свойства языка, такие как нестрогая типизация, не есть хорошо для первого языка программирования.

Получился 1С-подобный язык, который я сам стал использовать для автоматизации операций на компьютере. И соответственно, «нашпиговывать» его всё новыми, мыслимыми и немыслимыми функциями.