Компиляторы

Это последняя часть моего обзора компилятора Swift. Я покажу, как можно осуществить генерацию LLVM IR из AST и что выдаёт настоящий фронтенд. Если вы не читали предыдущие части, то переходите по ссылкам:

• Общий обзор компонентов
• Разбор исходного файла
• Swift intermediate language

Продолжаем изучать компилятор Swift. Эта часть посвящена Swift Intermediate Language.

Если вы не видели предыдущие, рекомендую перейти по ссылке и прочитать:

• Общий обзор компонентов.
• Разбор исходного файла.

Введение

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

На одном личном проекте на C++ мне потребовалось получать информацию о типах объектов во время выполнения приложения. В C++ есть встроенный механизм Run-Time Type Information (RTTI), и конечно же первая мысль была использовать именно его, но я решил написать свою реализацию, потому что не хотел тянуть весь встроенный механизм, ведь мне нужна была лишь малая часть его функционала. А еще хотелось попробовать на практике новые возможности C++ 17, с которыми я был не особо знаком.

В этом посте представлю пример работы с парсером libclang на языке Python.

Эквивалентен ли по производительности код, представленный ниже?

// (A). Вызов HasPrefix будет встроен.
return strings.HasPrefix(s, "#")
// (B). Ручное встраивание тела HasPrefix.
return len(s) >= len("#") && s[:len("#")] == "#"

Ответ: нет.

За подробностями и объяснениями прошу под кат.

Вторая часть моего рассказа о компиляторе Swift. Мы начнём изучать фронтенд, а точнее те его части, которые отвечают за первоначальный разбор и анализ исходного кода.

Swift — это не только язык программирования. Это проект, в который помимо компилятора входит много других компонентов. Да и сам компилятор — это не большая и страшная коробка, которая с помощью магии превращает ваш код в набор понятных для машины инструкций. Его тоже можно разбить на компоненты. Если вам интересно, на какие именно — добро пожаловать под кат.

И снова я несколько переоценил объем статьи! Планировал, что это будет заключительная статья, где сделаем компилятор и выполним тестирование. Но объем оказался велик, и я решил разбить статью на две.

В этой статье мы сделаем практически все основные функции компилятора. Он уже оживет, и можно будет писать, компилировать и выполнять достаточно серьезный код. А тестирование сделаем в следующей части. (Кстати, предыдущие части: раз, два, три).

Я впервые пишу на Хабре, возможно, получается не всегда все хорошо. На мой взгляд, статьи 2, 3 получились довольно сухими, много кода, мало описания. В этот раз я постараюсь сделать по другому, сосредоточиться на описании самих идей. Ну а код… код, конечно будет! Кто захочет разобраться досконально, такая возможность будет. В многих случаях я помещу код под спойлер. И, конечно, всегда можно заглянуть в полный исходник на гитхабе.

Компилятор продолжим писать некоторое время на ассемблере, но потом перейдем на форт и продолжим писать компилятор на самом себе. Это будет напоминать барона Мюнхаузена, который вытаскивал сам себя за волосы из болота. Но, для начала, я расскажу в общих чертах, как устроен компилятор на форте. Добро пожаловать под кат!

Доброго времени суток тем, кто решил ознакомиться с моей очередной статьёй.

Первым делом выкладываю ссылки на предыдущие части:
Часть 1: пишем языковую ВМ
Часть 2: промежуточное представление программ
Часть 3: Архитектура транслятора. Разбор языковых структур и математических выражений

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

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

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

Начнем творить…

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

В Новосибирске вот уже 18 лет делают свою собственную JVM, написанную полностью самостоятельно и востребованную далеко за пределами России. Это не просто какой-то форк HotSpot, делающий всё то же самое, но чуть лучше. Excelsior JET — это комплекс решений, позволяющих делать совершенно другие вещи в плане AOT-компиляции. «Пфф, AOT есть в GraalVM», — можете сказать вы. Но GraalVM — это всё ещё очень исследовательская штука, а JET — это проверенное годами решение для использования в продакшене.

Это интервью с одними из разработчиков Excelsior JET. Надеюсь, оно окажется особенно интересно всем, кто хочет открыть для себя новые вещи, которые можно делать с Java. Либо людям, которые интересуются жизнью JVM-инженеров и сами хотят в этом поучаствовать.