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

Скоро первое сентября. Кто-то собирается в школу, кто-то — в институт. А мы предлагаем начать новые проекты с компилятором 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 (выше – лучше).

Пять лет назад мне довелось проектировать одну программу, обрабатывающую текст с управляющими командами. Количество этапов обработки было весьма существенным — 6-7 обработчиков последовательно могли пропускать через себя довольно большие объёмы данных, как бывает иногда в конвейерах Unix. Чтобы аккуратно выполнить поставленную задачу я разработал общий метод, который может пригодиться и в других местах. Идея, лежащая в основе этой статьи, действительно очень напоминает конвейеры Unix, но имеется несколько существенных отличий:

• конвейер Unix работает асинхронно, в разных процессах, в то время, как здесь требуется реализовать обработку в рамках одной программы, и распараллеливание может быть нежелательно;
• возможна передача любых данных, не обязательно текстовых, но которые можно охарактеризовать термином «линейные».

Под линейными данными я буду понимать последовательность объектов, допускающую переход к следующему (если он имеется). Примерами могут служить: бинарный файл, текст из символов UTF-8, последовательность лексем, команд. Сложная программа, обрабатывающая линейные данные, такая как транслятор, обычно выполняет несколько преобразований. Вот пример:

• чтение файла по байтам,
• декодирование в UTF-8,
• препроцессор,
• лексический анализ,
• синтаксический анализ.

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

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

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

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

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

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

Привет! Если ты это читаешь, значит знаешь, что такое Sublime Text 2 или слышал о нем хоть, что-то.

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

И так, я расскажу про то, как я:
1. Боролся с кодировкой при открытии. При открытии фала с кодировкой windows-1251, русские буквы превращались в кракозябры.
2. Установка словаря, для подсветки, если не правильно написал слово.
3. Установка плагина SFTP и подключение к серверу.

Поехали!

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

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

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

Привет, %habra_user%!

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

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

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

Мы проверили заголовочные файлы, входящие в состав Embarcadero C++Builder XE3. Фактически, это означает только проверку небольшого числа inline-функций. Соответственно найдено совсем немного подозрительных мест, но достаточно для небольшой заметки.

С выпуском GCC 4.8.0 разработчики набора компиляторов GNU Compiler Collection завершили переход на C++ в реализации GCC. Работа по переводу кодовой базы на C++ продолжалась c 2008 года, и теперь подошла к концу. Миграция на C++ означает, что теперь для сборки GCC из исходников обязательно требуется компилятор С++ 2003.

Ричард Столлман написал первый вариант GCC в 1985 году на непереносимом диалекте языка Паскаль. В 1987 году компилятор был переписан на языке Си, и в таком виде существовал до 2013 года.

Предыдущий мой пост был посвящен цикловым перестановочным оптимизациям, проблемам распознавания циклов, разрешению неоднозначности при работе с памятью, определению и важности зависимостей. Теперь я хочу сделать обзор одной из самых эффективных цикловых оптимизаций — автовекторизации. Хочется обсудить вопросы эффективности оптимизации, а также попытаться понять, какие факторы эту эффективность определяют. Всем, кому это интересно – добро пожаловать. При обсуждении я буду ориентироваться на интеловский автовекторизатор и автовекторизатор gcc 4.7.2. gcc я буду исследовать, чтобы подтвердить, что те принципы векторизации, которые я здесь пытаюсь сформулировать, имеют достаточно общую природу. Заодно мне, конечно, хочется понять уровень автовекторизации в gcc. Тут, конечно, есть некий элемент неравенства, поскольку я использую последний компилятор Интел, но не самую топовую версию gcc, но в основном я буду ориентироваться при сравнении на SSE инструкции. (Кстати, Intel активно участвует в разработке автовекторизатора gcc). Поскольку Intel и интеловский компилятор мне ближе, то ему я уделю кое-где больше внимания. Я не претендую на то, что я векторизаторный гуру и буду рад, если кто-то увидит мои ошибки и меня поправит. Букв будет много.

GHC (Glasgow Haskell Compiler) — стандартный компилятор Хаскеля. GHC — один из самых крутых компиляторов в мире, но к сожалению без дополнительных телодвижений скомпилированные им программы по скорости больше напоминают интерпретируемые, т. е. работают очень медленно. Однако если раскрыть весь потенциал компилятора, Хаскель приближается по производительности к аналогичному коду на C.

В этой статье я обобщаю опыт выжимания максимума из GHC при создании dataflow-фреймворка Yarr.

Если ты всегда мечтал написать свой язык программирования — добро пожаловать. Здесь ты наверняка найдёшь для себя что-нибудь интересное.

GitHub-юзер yawnt собрал чудесную подборку ссылок для любителей драконов, языков и прочих вкусных внутренностей. А знающие камрады в комментариях наверняка поделятся с тобой и другими яствами.

Пишет yawnt следующее:

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

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.

      Времена, когда программисты пытались выжать максимум из размера своего приложения, безвозвратно ушли. Основной причиной является существенное увеличение объемов оперативной памяти и дискового пространства на современных компьютерах. Немногие помнят, как при загрузке приложения с кассеты можно было пойти покушать. Или как можно было считать моргания дисковода, косвенно определяя размер приложения. Пожалуй, только разработчики програмного обеспечения под встраиваемые системы до сих пор заботятся о размере кода и потребляемой памяти. Могут ли таблетки и смартфоны вернуть разработчиков «назад в будущее»?
      Данная статья призвана помочь разработчикам програмного обеспечения, использующим GCC компилятор, уменьшить размер кода своих приложений. Все данные в статье получены при помощи x86 GCC компилятора версии 4.7.2 на операционной система Fedora 17 для архитектуры Intel Atom.

Один мой друг, историк по профессии, подкинул мне замечательную идею об использовании древней мнемонической и счетной систем в современной криптографии. В процессе его рассказов об узелковой письменности Инков, я начал соображать, что все новое — хорошо забытое старое и было бы не плохо как-то применить древний опыт в современном мире. Первое, что пришло в голову — криптография. Это самое очевидное — просто сконвертировать узлы с ниток в байты и шифр готов. С одной стороны все казалось понятным, но потом я вспомнил про криптостойкость и другие параметры шифров и понял, что не обладаю достаточным опытом и знаниями в области криптографии, чтобы в одиночку разработать новый шифр.

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

Четвертая версия языка оказалось удачной: я написал факториал, затем генерацию последовательности Фибоначи и дюжину простых примерчиков аля “сумма чисел от 0 до 99”. Язык получился что надо: необычный и в тоже время с простой понятной идеей. Главное — язык может решить любую (ну или почти любую) задачу которую можно выразить в виде вычислимой функции.

Этот пост снова посвящается цикловым оптимизациям. Почему вообще речь зашла о цикловых перестановочных оптимизациях? Дело в том, что это одна из самых эффективных частей оптимизирующего компилятора. В число цикловых перестановочных оптимизаций входит как автовекторизация так и автопараллелизация. У этих оптимизаций существует своя специфика, но в целом у всех цикловых оптимизаций общие проблемы и общие методы их решения.
Часто приходится слышать мнение, что компилятор во многих случаях «тупит». Мне хочется здесь побыть адвокатом компилятора, чтобы показать, что жизнь компилятора не так уж легка, возможно вызвать легкую долю сочувствия к его нелегкой доле и показать, какие существуют объективные трудности при обработке программы и почему во многих случаях компилятор совершенно обоснованно не может сделать ту или иную оптимизацию, которая кажется очевидной программисту. Ну и заодно я хочу продемонстрировать некоторые возможности помочь компилятору в его работе. Понятно, что иногда существуют и субъективные факторы, в лице разработчиков, которые по како-либо причине не реализовали ту или иную функциональность внутри компилятора.

Есть несколько важных аспектов, которые нужно обязательно учитывать при создании приложения, производящего какие-либо вычисления, а точнее — операции с числами с плавающей точкой. Что мы ждём и планируем получить от таких приложений (в большинстве случаев, научных)? В первую очередь, нас интересует точность вычислений – полученный результат должен быть наиболее близок к «правильному». Другая сторона медали – стабильность результатов и портируемость приложения. Нам важно иметь возможность получать одинаковый, неизменно повторяющийся от запуска к запуску результат, причём на разных машинах/архитектурах. Ну и последний, но не менее значимый пункт – производительность. Насколько быстро при всём этом будет выполняться наше приложение, и когда мы получим результаты наших вычислений?

В компиляторе компании Intel есть набор опций, отвечающих за контроль оптимизаций вычислений над числами с плавающей точкой. Рассмотрим преинтереснейший ключик –fp-model, который, судя по описанию в документации, управляет семантикой вычислений над числами с плавающей точкой. Кстати, стоит отметить, что похожие ключи есть и в других компиляторах, не только Интеловском, об этом мы тоже поговорим. По сути, с помощью данного ключика мы и сможем контролировать баланс между производительностью и точностью вычислений. Возможные значения, которые могут быть указаны в опции –fp-model: precise, fast[=1|2], strict, source, [no-]except (Linux*) or except[-] (Windows*). Давайте разберёмся, что они дают при компиляции нашего кода.