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

Давайте попробуем посмотреть на 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 для межпроцедурных оптимизаций. А начну я с рассказа о моделях межпроцедурного анализа и графе вызовов.

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

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

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

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

Скоро первое сентября. Кто-то собирается в школу, кто-то — в институт. А мы предлагаем начать новые проекты с компилятором clang, который теперь поддерживает OpenMP!

Проект доступен здесь. Сейчас в его основе лежит clang 3.3. Небыстрый процесс ревью уже идет, и скоро код будет залит в транк clang'а, а значит войдет в его новые релизы.

Реализована полная поддержка стандарта OpenMP версии 3.1. Успешно проходятся следующие тесты: набор для валидации OpenMP от OpenUH Research Compiler, SPEC OMP2012 и внутренние тесты Intel. Исполняемый код c OpenMP, собранный clang'ом, демонстрирует производительность, сравнимую с другими компиляторами, поддерживающими OpenMP.
В качестве библиотеки времени выполнения использована библиотека Intel OpenMP Runtime Library, также доступная под свободной лицензией.

Как в сравнительно короткие сроки написать компилятор какого-либо языка программирования. Для этого следует воспользоваться средствами разработки, автоматизирующие процесс. Я хотел бы рассказать о том, как я писал компилятор языка программирования MiniJava под платформу .NET Framework.

Весь процесс написания компилятора в целом отображён на следующем изображении. На вход подаётся файл с исходным кодом на языке программирования MiniJava. Выходом является PE-файл для выполнения средой CLR.



Далее я хотел бы сконцентрироваться на практической части описания.

Давайте попытаемся понять, что нового сделано в GCC компиляторе для процессоров архитектуры Intel Atom и как это влияет на производительность и размер кода известного бенчмарка EEMBC CoreMark.
Выше приведен график, отображающий производительность CoreMark, откомпилированного с пиковым и базовым набором опций разными версиями GCC относительно производительности базового набора опций для GCC версии 4.4.6 (выше – лучше).

Используете GCC в проекте с закрытым исходным кодом? Применяете OpenMP? Вы же в курсе, что библиотека libgomp, с которой компонуются все OpenMP программы, распространяется на условиях GPLv3? Будьте так добры, откройте ваши исходники…

Для тех, кто не следит пристально за развитием Clang/LLVM, сообщаю — состоялся релиз версии 3.3. LLVM продолжает развиваться семимильными шагами и новый релиз, как заявлено, первым поддерживает все фичи C++11, добавлена поддержка целой пачки новых таргетов и появилось несколько интересных тулов, основанных на инфраструктуре LLVM. Также продолжает развиваться оптимизатор — появился автовекторизатор, который работает по умолчанию на -O3, много сделано для улучшения уже существующих оптимизаций. Кому интересны подробности — добро пожаловать под кат.

На хабре уже упоминался язык D. Но популярности он не получил из-за невозможности практического использования, а точнее большинству он просто не нужен.Сегодня хочу рассказать вам об одном полезном фреймворке для D. Большинство программистов хоть раз писали веб-сервер на компилируемом языке, но эти языки слишком низкоуровневы для такой задачи. Для такой задачи можно использовать этот язык в связке с фреймворком vibe.d;

Компьютер DEC с носителем DECtape

На Github выложили last1120c и prestruct-c — ранние версии самого первого компилятора С в истории. Код написан самим Деннисом Ритчи в 1972-1973 гг.

Компиляторы найдены несколько лет назад на старой магнитной ленте DECtape, вставленной в антикварный компьютер VAX производства компании DEC.

Привет, %habra_user%!

Решил в продолжение цикла статей о Flex-компиляторе перевести хорошую статью автора сего творения о том, какие же процессы происходят внутри компилятора при сборке приложения. Датируется она 2008м годом, но при этом в русскоязычном сообществе (да и в других особо тоже) замечена не была. А так как ближайшее время именно этот компилятор остаётся актуальным для сборки подавляющего большинства Flash-проектов, то я решил продолжить цикл статей о его расширении.

Как обычно всех, кто не устал дочитав до этой строчки — прошу под кат!