Рубрика «LLVM» - 9

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

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

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

Сегодня я хочу рассказать об одной интересной сложности декодирования/дизассемблирования IA-32 инструкций.

Перед прочтением этой статьи рекомендую обратиться в статье «Префиксы в системе команд IA-32», описывающей общую структуру IA-32 команды и существующие префиксы. В этой статье я подробнее расскажу про обязательные префиксы (англ. mandatory prefixes) и некоторые нюансы, связанные с ними.
Читать полностью »

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

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

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

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

Читать полностью »

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

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

Yarr — dataflow фреймворк (обработки изображений) на Хаскеле

Зондирование обстановки на Реддите показало, что едва ли хоть кто-то всерьез занимается обработкой изображений на Хаскеле, несмотря на то, что достаточно популярная библиотека Repa предполагает работу с изображениями как одно из основных приложений. Надеюсь, ситуацию сможет изменить библиотека Yarr (документация, гитхаб).

Я называю библиотеку dataflow-фреймворком, потому что она обобщена для обработки массивов (от одномерных до трехмерных) элементов любых типов, в том числе векторов чисел, например координат, комплексных чисел. Но основное предполагаемое применение — обработка двумерных массивов из векторов цветовых компонент, т. е. изображений. Фреймворк непосредственно не содержит алгоритмов обработки изображений, а предоставляет мощную инфраструктуру для их написания.
Читать полностью »

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

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

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

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

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

Native Client (NaCl) позволяет браузерным приложениям запускать нативный низкоуровневый код в изолированной «песочнице». Благодаря этому критически важные для производительности части можно переписать на C или C++. До сих пор NaСl мог работать лишь на x86-совместимых компьютерах. Поддержка ARM имеет для Google большое значение, так как младшие модели ноутбуков на Google Chrome OS построены на архитектуре ARM.
Читать полностью »

Я не люблю программировать. Мне нужен результат.

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

Но главное — чтоб заработало. И чем раньше — тем лучше.

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

Так вот. Современные языки программирования мешают излагать мысли, обременяя множеством деталей, не относящихся к решаемой задаче, и требующихся лишь для того, чтобы до транслятора языка «дошло». И речь даже не о синтаксисе, хотя многие, особенно компилируемые, языки чрезмерно многословны. Речь, прежде всего, о языковых сущностях, что и есть те «термины», в которых должно изъясняться. Эти сущности — например функции, переменные, классы, методы, пакеты, пространства имён, обобщения, шаблоны — слишком узкие, специализированные, предназначенные больше для машинного представления, нежели для человеческого понимания. Они заставляют переводить мысли на их язык. Это не сложно, конечно. Но это совершенно не относится к решаемой задаче. Выбор подходящих языковых сущностей и перевод на них отвлекают от задачи, снижают концентрацию и, следовательно, снижают эффективность разработки. И, я подозреваю, существенным образом. Понимание же сути в процессе чтения такого кода ещё более затруднительно, что также не лучшим образом влияет на производительность труда, особенно при командной разработке.

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

Основная идея o42a — автоматизировать труд программиста. И достигается это путём радикального сокращения видов языковых сущностей до одного-единственного, способного непосредственно заменить их все. Задача же эффективного машинного представления такой сущности целиком ложится на компилятор.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js