На данный момент LLVM стала уже очень популярной системой, которую многие активно используют для создания различных компиляторов, анализаторов и т.п. Уже написано большое количество полезных материалов по данной тематике, в том числе и на русском языке, что не может не радовать. Однако в большинстве случаев основной уклон в статьях сделан на frontend и middleend LLVM. Конечно, при описании полной схемы работы LLVM генерация машинного кода не обходится стороной, но в основном данной темы касаются вскользь, особенно в публикациях на русском языке. А при этом у LLVM достаточно гибкий и интересный механизм описания архитектур процессоров. Поэтому данный материал будет посвящен несколько обделенной вниманием утилите TableGen, входящей в состав LLVM.

Причина, по которой компилятору необходимо иметь информацию об архитектуре каждой из целевых платформ вполне очевидна. Естественно, у каждой модели процессора свой набор регистров, свои машинные инструкции и т.д. И компилятору нужно иметь всю необходимую информацию о них, чтобы быть в состоянии генерировать валидный и эффективный машинный код. Компилятор решает различные платформенно-зависимые задачи: производит распределение регистров и т.д. К тому же в бэкендах LLVM также проводятся оптимизации уже на машинном IR, который больше приближен к реальным инструкциям, или же на самих ассемблерных командах. В подобных оптимизациях нужно заменять и преобразовывать инструкции, соответственно вся информация о них должна быть доступна.

Список переведённых частей серии:

1. Приготовления
2. Компиляция с Emscripten
3. Конвертация avi в mp4 (вы тут)

---

В этой части ма разберём:

1. Компиляцию библиотеки FFmpeg с оптимизированными аргументами.
2. Управление файловой системой Emscripten.
3. Разработку ffmpeg.js v0.1.0 и конвертацию видео.

Список переведённых частей серии:

1. Приготовления
2. Компиляция с Emscripten (вы тут)
3. Конвертация avi в mp4

---

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

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

В этой части мы разберём:

1. Как настроить окружение для Emscripten в Docker
2. Использование emconfigure и emmake 
3. Как решать проблемы, возникающие при компиляции FFmpeg с Emscripten

Список переведённых частей серии:

1. Приготовления (вы тут)
2. Компиляция с Emscripten
3. Конвертация avi в mp4

---

Из этой части вы узнаете:

1. Зачем это всё нужно
2. Как скомпилировать FFmpeg в Docker

---

Зачем это всё нужно

Главные задачи у серии публикаций такие:

1. Создать туториал по использованию Emscripten для компиляции C/C++ библиотек в JavaScript (более детальный и полезный, чем написанные ранее)
2. Персональная памятка

Почему FFmpeg?

FFmpeg — это свободный проект с открытым исходным кодом, состоящий из обширного набора библиотек и программ для обработки видео, аудио и других мультимедийных файлов/трансляций. (из Википедии)

Библиотеки JavaScript, которая предоставляла бы подобные возможности, попросту не существует. Если вы погуглите «ffmpeg.js», то найдёте несколько решений, подобных тому что мы собираемся сделать:

• ffmpeg.js
• videoconverter.js

Эти библиотеки, конечно, можно использовать, но у них есть свои недостатки:

1. Используемые версии как FFmpeg, так и Emscripten устарели
2. Проекты не поддерживаются уже долгое время

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

Современные процессоры суперскалярны, то есть способны выполнять несколько инструкций одновременно. Например, некоторые процессоры могут обрабатывать за цикл от четырёх до шести инструкций. Более того, многие такие процессоры способны инициировать команды не по порядку: они могут начать работать с командами, расположенными в коде намного позже.

В то же время, код часто содержит ветвления (операторы if–then). Такие ветвления часто реализуются как «переходы», при которых процессор или переходит к выполнению инструкции ниже по коду, или продолжает текущий путь.

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

Я занимаюсь автоматизацией Android устройств и часто SDK или ОС Android не имеют нужного функционала или его работа выполняется медленно/очень медленно.

Используя возможности Native Development Kit (NDK) мы можем написать функционал, который будет выполняться быстрей, чем тот же функционал на Java. За счет данного кита мы можем добавлять в свое приложение код, написанный на C/C++ или создавать свои бинарные файлы под мобильные Android устройства.

В данной статье я расскажу каким образом мы можем настроить компиляцию бинарного файла под ОС Android, а так же покажу процесс, как мы можем дополнить функционал уже существующих бинарных файлов в этой ОС.

Для примера я «прокачаю» screencap, который сможет не только получать скриншот всего экрана или выдавать «сырые данные», но и возвращать цвет пикселя по указанной точки или получать изображение только нужной области. Итак, поехали!

Еще с 1990-х годов меня поражало, что проектирование всей мировой цифровой микроэлектроники контролируется двумя конторами в Калифорнии, которые находятся в 10 минутах езды друг от друга — Synopsys и Cadence. В те времена четверть мирового проектирования делалось в Японии (континентальный Китай тогда находился в примитивном состоянии), и все эти Sony, Hitachi, Fujitsu и другие гиганты ездили на поклон в Америку и платили несчетные миллионы долларов за программы, которые потом использовали японские проектировщики. Сейчас это продолжается с Samsung, Huawei и даже с российскими конторами, которые проектируют микросхемы для космоса.

Русская земля умудрилась вырастить Yandex супротив Гугла, так почему бы и не попробовать создать какие-нибудь программы для проектирования микросхем? Начать можно с малого: популяризовать конкурсы и хакатоны по разработке алгоритмов автоматизации проектирования (Electronic Design Automation — EDA). Эти алгоритмы удобны тем, что у них много уровней сложности: простейшую программу Place & Route может написать студент за выходные, но вот на продвинутую потребуются десятилетия работы сотен людей и миллиарды долларов на R&D.

Сейчас в Иннополисе возле Казани делают мероприятие для студентов в формате «две недели подготовки + хакатон». Одной из тем стала традиционная задача EDA — размещение и трассировка графа электронной схемы на ряды стандартных ячеек. Будет интересно увидеть, что за это короткое время сможет осуществить небольшая команда студентов-программистов с базовым пониманием C++/Java/Python, методов парсирования текста, алгоритмов работы с графами и навыками визуализации структур данных с помощью GUI.

Итак — постановка задачи:

Команда разработчиков Rust рада сообщить о выпуске новой версии, 1.38.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если вы установили предыдущую версию Rust средствами rustup, то для обновления до версии 1.38.0 вам достаточно выполнить следующую команду:

rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта.

Что вошло в стабильную версию?

Изюминка данного выпуска — конвейерная компиляция.

Наконец-то я написал пост про [[trivial_abi]]!

Это новая фирменная фича в транке Clang-а, новая по состоянию на февраль 2018. Это вендорское расширение языка C++, это не стандартный C++, она не поддерживается транком GCC, и нет активных предложений WG21 включить её в стандарт C++, насколько мне известно.



Я не принимал участие в реализации этой фичи. Я просто просматривал патчи в списке рассылки cfe-commits и тихо аплодировал про себя. Но это такая крутая фича, что я считаю, каждый должен про неё знать.

Введение

Наша компания Leaning Technologies предоставляет решения по портированию традиционных desktop-приложений в веб. Наш компилятор C++ Cheerp генерирует сочетание WebAssembly и JavaScript, что обеспечивает и простое взаимодействие с браузером, и высокую производительность.

В качестве примера его применения мы решили портировать для веба многопользовательскую игру и выбрали для этого Teeworlds. Teeworlds — это многопользовательская двухмерная ретро-игра с небольшим, но активным сообществом игроков (в их числе и я!). Она мала как с точки зрения скачиваемых ресурсов, так и требований к ЦП и GPU — идеальный кандидат.


Работающая в браузере Teeworlds

Сегодня вышла новая версия джавы — Java/JDK 13. Гонка началась с весеннего выпуска JDK 12, состоявшегося 19 марта, а форк от основной ветки произошел 13 июня. Кого-то мы там по пути потеряли вроде JEP 343: Packaging Tool, но в целом всё норм, и пора пожинать плоды.

Скачать новый релиз можно по ссылке. Под катом будет небольшой обзор свежих JEP-ов, вошедших в этот выпуск.

Каждый уважающий себя программист хотя бы раз в жизни хотел придумать свой язык программирования – и сделать для него компилятор.

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

А если хочется конструировать компиляторы в своей профессиональной деятельности? Надо сказать, это действительно редкая профессия, можно даже сказать, элита программистского сообщества. Чтобы «с нуля» разработать компилятор хотя бы для весьма компактного и простого языка программирования, требуется знакомство с внушительным пластом математических оснований – теорией формальных грамматик, алгоритмами над деревьями и графами, механизмами оптимизационных преобразований – а также освоение богатого практического опыта реализации компиляторов, накопленного за несколько десятков лет.

Кому требуются специалисты этой редкой профессии? Основные работодатели – это крупные международные компании, производители вычислительной техники. И современные теоретические и практические знания по созданию компиляторов сосредоточены именно там.
Исследовательский Центр Samsung в Москве одно из таких редких мест, и мы предлагаем осуществить мечту о собственном работающем компиляторе, поступив на программу Samsung Compiler Bootcamp.



Подробности читайте под катом.

Это псевдорасшифровка моей презентации на !!Con 2019.

В большинстве используемых сегодня процессорных архитектур есть инструкция под названием popcount, сокращённо от 'population count'. Она делает следующее: подсчитывает количество установленных битов в машинном слове. Например (возьмём 8-битные слова для простоты), popcount(00100110) равно 3, а popcount(01100000) равно 2.

Вас это может сильно удивить, как и меня, но это всё, что она делает! Кажется не очень полезным, правда?

Всем привет!

Сегодня вашему вниманию предлагается перевод статьи, в котором на примерах разобраны варианты компиляции в JVM. Особое внимание уделено AOT-компиляции, поддерживаемой в Java 9 и выше.

Приятного чтения!

Введение

С 2016-го года (с перерывами) я разрабатываю собственный язык программирования. Название данного языка — «Ü». Почему Ü? Потому, что хотелось однобуквенного названия, а все буквы из набора A-Z уже заняты.

Данная статья имеет задачу ознакомить публику с данным языком, дать составить общее представление о нём. Статья не ставит целью описать язык полностью, более полное описание языка, если надо, будет дано в последующих статьях.

Зачем нужен ещё один язык?

← Часть 4. Программирование периферийных устройств и обработка прерываний

Библиотека генератора ассемблерного кода для микроконтроллеров AVR

Часть 5. Проектирование многопоточных приложений

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

Сергей Куксенко — перформанс-инженер, видевший Java еще версии 1.0. За это время успел поучаствовать в разработке мобильных, клиентских, серверных приложений и виртуальных машин. Производительностью Java занимается c 2005 года и в данный момент в Oracle работает над улучшением производительности JDK. Один из самых популярных докладчиков на Joker и JPoint.

Этот хабрапост — большое интервью с Сергеем, посвященное следующим темам:

• Культ Производительности;
• Когда и что нужно оптимизировать, изначальный дизайн языка и библиотеки;
• Перспективные направления для дальнейшей оптимизации;
• Как можно поучаствовать в разработке и что можно сломать оптимизациями;
• Компиляторные трюки, размещение регистров;
• Можно ли собрать кошку из фарша;
• Когда тесты работают пять дней подряд и прочая бытовуха;
• Как стать перформанс-инженером;
• Подготовка доклада на следующий Joker.

← Часть 3. Косвенная адресация и управление потоком исполнения
Часть 5. Проектирование многопоточных приложений. →

Библиотека генератора ассемблерного кода для микроконтроллеров AVR

Часть 4. Программирование периферийных устройств и обработка прерываний

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

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

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

Неожиданно тёплый приём, оказанный публикой Хабра моему посту о самодельном компиляторе XD Pascal для MS-DOS, заставил меня задуматься. Не досадно ли, что любительский проект, которому я отдал немало сил, лежит у меня мёртвым грузом с тех самых пор, как из Windows полностью исчезла виртуальная машина DOS? Итогом размышлений стал компилятор XD Pascal для Windows. Возможно, он лишился некоторой доли ностальгического шарма и утратил возможность наивной работы с графикой через прерывания BIOS. Однако переход на Windows вдохнул новую жизнь в проект и открыл дорогу к давней мечте — самокомпиляции.

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

← Часть 2. Начало работы
Часть 4. Программирование периферийных устройств и обработка прерываний →

Библиотека генератора ассемблерного кода для микроконтроллеров AVR

Часть 3. Косвенная адресация и управление потоком исполнения

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