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

После ухода Стива Балмера компания Microsoft продолжает радовать приятными новостями: спустя несколько лет наконец-то вышел MS Office для iPad, опубликован исходный код JS-библиотеки WinJS (Windows Library for JavaScript), и даже в IE11 внедрили достойные инструменты веб-разработки.

А вот теперь самый большой сюрприз: сегодня запущен сайт .NET Foundation, на котором «для начала» собрано 24 проекта с открытыми исходными кодами, в том числе недавно вышедший .NET Compiler Platform (Roslyn)!

В этой статье я расскажу более подробно об истории проекта JPHP и каким образом он был разработан с технической стороны. Текст будет интересен как простым разработчикам PHP, так и любителям компиляторов. Я постарался описать все на простом языке.

JPHP это компилятор языка PHP для Java VM. Две недели назад я писал статью о проекте. Похожие проекты — JRuby для ruby, Jython для python. После публикации первой статьи о JPHP, проект за два дня набрал 500 звёзд на гитхабе и успел засветиться не только в РУнете, но и на зарубежных ресурсах, успел побывать на первом месте в рейтинге гитхаба.

Представляю вам свой open-source проект — JPHP. Это альтернативная реализация PHP для JavaVM с поддержкой JIT. Я начал проект в одиночку в октябре 2013 года и за 4 месяца реализовал компилятор php в байткод JVM. Язык поддерживается на уровне PHP 5.3, частично поддерживаются возможности PHP 5.4 и 5.5. По своей идеологии проект напоминает JRuby и Jython.

Я подготовил небольшую презентацию, которая расскажет о проекте и не отнимет у вас много времени:

Данный туториал описывает создание плагина для Clang и покрывает следующие шаги:

• настройка окружения
• создание базового плагина
• создание Xcode-проекта для разработки плагина
• генерирование предупреждений
• генерирование ошибок
• интеграция плагина в Xcode
• интерактивные подсказки по устранению предупреждений и ошибок

TL;DR

Готовый плагин можно найти здесь

Мои наблюдения за развитием языков программирования оставляют странное ощущение тупика. В последнее время появилось достаточно много новых языков. Но прогресса в этой области никакого нет. Такое впечатление что развитие в этой области топчется на месте. По возможностям языки мало отличаются друг от друга. Явное противостояние видно на поле типизации переменных.

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

Используемые программы и библиотеки

1. GOLD Parsing System — IDE для написания грамматик и генерации кода лексеров и парсеров под различные языки (C, C#, Java, JavaScript, Objective-C, Perl, Python, Ruby и др.). Основана на LALR парсинге.
2. Visual Studio 2010
3. GOLD.Engine — сборка под .NET, подключаемая для взаимодействия со сгенерированными таблицами.
4. NUnit — Открытая среда юнит-тестирования приложений для .NET.
5. ILSpy — OpenSource дизассемблер под .NET.

Этапы, на которые я разбил весь процесс:

1. Построение дерева выражения
2. Вычисление аналитической производной
3. Упрощение (симплификация) выражения
4. Обработка рациональных дробей
5. Компиляция выражения

Давайте попробуем посмотреть на Sweet.js, компилятор, который реализует гигиенические макросы для JavaScript.

Работает он довольно просто — вы определяете набор шаблонов, по которым выполняется поиск по синтаксическому дереву. При совпадении макрос получает кусок дерева, который ему нужен и тело макроса определяет как этот кусок дерева должен трансформироваться. Далее результат встраивается обратно в дерево и процедура продолжается с того самого места.

Sweet.js оперирует своим собственным форматом синтаксического дерева, почти на уровне токенов, с минимальной структурой. С одной стороны это делает возможным определять довольно экзотические синтаксисы для своих макросов, с другой — делает написание макросов несколько сложнее, как если бы они были определены над стандартным AST JavaScript.

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

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

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

Видели linux на эмуляторе PC, написанном на javascript?
Если нет — вот небольшой пост о нем.
А вот он сам.

Этот эмулятор — неплохой способ познакомится с консолью linux.
Если у вас есть или была Ubuntu(а это тоже linux), в ней был пользовательский интерфейс, как в Windows, программы и игры устанавливаются при помощи менеджера пакетов.

Ну а что же можно сделать здесь?

Каждая новая спецификация OpenMP вводит очень полезные и необходимые дополнения к уже существующему функционалу. Например, в версии 3.0 были добавлены так ожидаемые задачи (tasks), позволившие решать ещё больший спектр задач по распараллеливанию приложений. В 3.1 целый ряд улучшений по работе с задачами и редукциями.

Но по сравнению с тем, что нам теперь даёт стандарт 4.0, предыдущие нововведения кажутся какими-то мелкими. Последняя версия расширила типы поддерживаемого параллелизма, чего раньше никогда не замечалось.

Эта книга французского профессора Кристиана Кеннека об интерпретаторах Лиспа и Scheme довольно хорошо известна в англоязычном мире. Даже пару раз проскакивала на Хабре. Но в русскоязычном сообществе Scheme чаще всего ассоциируется со «Структурой и интерпретацией компьютерных программ» (aka SICP). Это хороший учебник для новичков, где целых две главы посвящены реализации используемого языка, однако в нём не рассматривается реализация довольно интересных и важных для Лиспа вещей вроде макросов, продолжений, динамических вычислений.

Однажды «Lisp in Small Pieces» попался мне в руки, и через несколько десятков страниц я осознал, что подобному бриллианту негоже пропадать в безвестности. А так как лучший способ получить больше адептов в секту популяризовать иностранную книгу — это перевести её на родной язык целевой аудитории, то этим я и занялся вместо того, чтобы нормально читать. Наконец, перевод, вёрстка и вычитка были завершены; результаты усилий представляются вашему вниманию.

Внутри читателя ожидают:

• более 37000 скобок!
• разбор по косточкам семантики всех конструкций Scheme, а также его родственников;
• в том числе разбор его денотационной семантики — формального математического описания языка в терминах лямбда-исчисления;
• 11 интерпретаторов и 2 компилятора (в машинный код описываемой там же VM и транслятор в код на Си);
• объяснение сути рекурсии, замыканий и окружений, продолжений и стека вызовов, реализации макросов и метаязыков, а также чуть рефлексии и самомодифицирующегося кода;
• множество экскурсов в историю Лиспа и причины принятых решений в дизайне языка;
• собственная CLOS-подобная объектная система автора (и её реализация, разумеется);
• время от времени возникающее чувство: «Да это же X из языка Y»;
• список литературы по теме на 230 наименований.

В общем, отличный учебник по основам реализации языков программирования, с которым стоит ознакомиться не только любителям скобочек.

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

Ранее мы познакомились с языком Smalltalk, а точнее с его микро реализацией Little Smalltalk. Разобрались с синтаксисом языка, форматом представления объектов в памяти и набором основных инструкций. Теперь мы вплотную подошли к вопросам взаимодействия Smalltalk и LLVM (ради этого и затевалась вся серия статей).

Сейчас у нас есть вся необходимая база знаний для того чтобы понять, что именно делается в нашем JIT компиляторе. В этой статье мы узнаем, как байт-коды Smalltalk преобразуются в IR код LLVM, как происходит компиляция и выполнение кода, и почему это работает быстрее, чем программная интерпретация. Самые нетерпеливые могут посмотреть шеллкасты (раз и два) с циферками и бегущими строчками (не забывайте про возможность скроллинга).

Всем привет! Совместно с humbug, мы предлагаем вашему вниманию третью статью из цикла о Low Level Smalltalk (LLST). Надемся, что статья будет интересна не только любителям велосипедов необычных языков программирования, но и тем, кто интересуется такой замечательной вещью, как LLVM.

Напомню, что целью нашего проекта является создание собственной виртуальной машины, совместимой с Little Smalltalk на уровне байт-кодов. Ключевым отличием является гетерогенная архитектура, которая позволяет исполнять байт-коды как программно, так и компилировать их в низкоуровневые инструкции процессора посредством трансляции в IR код LLVM. Разумеется, второй способ позволяет достичь более высокой производительности и задействовать имеющиеся в нашем распоряжении вычислительные ресурсы оптимальным образом.

Однако, обо всем по порядку…

Коллеги,

а помните была такая статья-перевод на Хабре Чек-лист разработчика языка программирования Колина Макмиллена о проблемах новых языков программирования? Статья просто изумительная! Если не читали — обязательно посмотрите.

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

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

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

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

Введение

С недавнего времени я увлекся микроконтроллерами. Сначала AVR, затем ARM. Для программирования микроконтроллеров существует два основных варианта: ассемблер и С. Однако, я фанат языка программирования Форт и занялся портированием его на эти микроконтроллеры. Конечно, существуют и готовые решения, но ни в одном из них не было того, что я хотел: отладки с помощью gdb. И я задался целью заполнить этот пробел (пока только для ARM). В моем распоряжении была плата stm32vldiscovery с 32-битным процессором ARM Cortex-M3, 128кБ flash и 8 кБ RAM, поэтому я и начал с нее.
Писал я кросс-транслятор Форта конечно на Форте, и кода в статье не будет, так как этот язык считается экзотическим. Ограничусь достаточно подробными рекомендациями. Документации и примеров в сети по предмету почти нет, некоторые параметры подбирались мной путем проб и ошибок, некоторые — путем анализа выходных файлов компилятора gcc. Кроме того, я использовал только необходимый минимум отладочной информации, не касаясь, например, relocation-ов и множества других вещей. Тема очень обширна и, признаюсь, разобрался я с ней только процентов на 30, что оказалось для меня достаточным.

Одной из самых интересных и важных компонент современного оптимизирующего компилятора является межпроцедурный анализ и оптимизации. Хороший стиль программирования и необходимость разделения работы между разработчиками диктует необходимость разбиения большого проекта на отдельные модули, в которых основные утилиты реализованы как «черные ящики» для всех основных пользователей. Детали реализации, в лучшем случае, известны паре-тройке конкретных разработчиков, ну а иногда, за давностью лет, и вообще никому неизвестны. (А что поделаешь – специализация, глобализация). Ваш код, зачастую, содержит вызовы внешних функций, тела которых определены во внешних файлах или библиотеках и ваши знания о этих функциях минимальны. Ну и помимо этого при разработке больших проектов плодятся всякие глобальные переменные, с помощью которых компоненты большого проекта обмениваются ценной информацией, и для того, чтобы разобраться в работе вашей части кода в случае каких-то проблем, бывает необходимо перелопатить массу кода. Очевидно, что все это сильно осложняет и работу оптимизирующего компилятора. Какие негативные эффекты порождает модульность и есть ли в компиляторе специальные средства для их преодоления – тема для большого разговора. Сейчас я попытаюсь начать такой разговор. Я расскажу о некоторых интересных особенностях работы оптимизирующего компилятора на примере работы компилятора Intel. Ориентироваться буду на OS Windows, поэтому опции компилятора привожу характерные для этой платформы. Ну и чтобы облегчить себе жизнь, я иногда буду использовать аббревиатуры IPA для межпроцедурного анализа и IPO для межпроцедурных оптимизаций. А начну я с рассказа о моделях межпроцедурного анализа и графе вызовов.

Для справки: xBase — семейство систем программирования, СУБД, берущих начало с dBase (1980 г.). Их объединяет общий язык программирования ( естественно, с вариациями, присущими конкретной реализации ) и встроенные в этот язык средства доступа к реляционным базам данных формата DBF. Собственно, dBase начинался как СУБД с языком, предназначеннным для обслуживания баз данных. Это процедурный язык программирования, он относится к группе интерпретируемых языков и обладает многими, если не всеми, их родовыми чертами, такими, например, как динамическая типизация.

Clipper, непосредственный предшественник Harbour, был создан в 1985 г. с целью повышения производительности dBase III. Для этого исходный код программы преобразовывался на стадии компиляции в байт-код, который встраивался в исполнямый файл вместе с виртуальной машиной, предназначенной для исполнения этого байт-кода. Таким образом, Clipper давал на выходе автономный exe файл, не требующий для своего запуска и выполнения внешнего интерпретатора, как в случае dBase или FoxBase ( другой популярный xBase продукт ).

В течение некоторого промежутка времени — возможно, совсем недолго — все желающие имеют возможность скачать и использовать Linux компилятор Intel C++ v13.0 для Android совершенно бесплатно. Предлагаем воспользоваться этим шансом! Компилятор позволит вам существенно ускорить работу ваших приложений на устройствах, работающих под Intel Atom — результат можно увидеть, даже просто перекомпилировав проект. В качестве ОС для запуска компилятора используется Ubuntu 10.04 или 11.04. В настоящее время поддерживается только работа в режиме командной строки. Приложения компилируются под Android Jelly Bean и Ice Cream Sandwich.

Скачать компилятор — пока что совершенно бесплатно.

Во многих новостях про Clang на хабре я наблюдал один и тот же вопрос: «когда будет нормальная поддержка Windows?».

Уверен, задававшим подобные вопросы будет интересна свежая новость из мира LLVM.