Оглавление:
Часть 1: Введение и лексический анализ
Часть 2: Реализация парсера и AST
Часть 3: Генерация кода LLVM IR
Часть 4: Добавление JIT и поддержки оптимизатора
Часть 5: Расширение языка: Поток управления
Часть 6: Расширение языка: Операторы, определяемые пользователем
Часть 7: Расширение языка: Изменяемые переменные
Часть 8: Компиляция в объектный код
Часть 9: Добавляем отладочную информацию
Часть 10: Заключение и другие вкусности LLVM

8.1. Введение

Добро пожаловать в главу 8 руководства “Создание языка программирования с использованием LLVM”. Эта глава описывает, как компилировать программы на нашем языке в объектные файлы.

Всем привет! Написал небольшой скрипт, который ищет заданную фразу по всем субтитрам в папке (и во всех подпапках) и показывает соответствующий видеофайл с этого места. Если было несколько совпадений, то будет создан плейлист, по которому можно перемещаться либо с помощью «Enter» либо «Shift + <» и «Shift + >».

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

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

Каждый электродвигатель обладает некоторыми отличительными свойствами, которые обуславливают его область применения, в которой он наиболее выгоден. Синхронные, асинхронные, постоянного тока, коллекторные, бесколлекторные, вентильно-индукторные, шаговые… Почему бы, как в случае с двигателями внутреннего сгорания, не изобрести пару типов, довести их до совершенства и ставить их и только их во все применения? Давайте пройдемся по всем типам электродвигателей, а в конце обсудим, зачем же их столько и какой двигатель «самый лучший».

Вдохновившись некоторое время назад статьей «Умные часы своими руками за 1500р.», я тоже решил попробовать сделать подобный девайс.

Эта статья не позиционируется как руководство к действию или инструкция, скорее как указание на ключевые моменты, с которыми мне пришлось столкнуться. Быть может, кому-то она послужит источником вдохновения и полезной информации.

Подбор компонентов, разводка платы, пайка в суровых условиях, 3D-печатный корпус и JavaScript на часах — под катом. Welcome!

Эта статья про управление светодиодами WS2812b, немного о синтезе логических схем и реализации их внутри микроконтроллера. Статья с небольшими отступлениями и двумя бонусами. Первый бонус основывается на том факте, что когда мы пишем, то одновременно читаем (разве нет?). Второй бонус поможет начать программировать микроконтроллеры и за 10 минут самим повторить реализацию, описанную в статье.

Так иногда бывает, что занимаешься одной технической проблемой, но, по мере погружения в задачу и во время поиска ее решения, появляются «побочные продукты». Так случилось и в этот раз. Я исследовал различные методы измерения временных интервалов с помощью ПЛИС. В одном из предложенных методов измерений был использован динамический сдвиг фазы тактовой частоты с PLL. Позже пришла идея: используя свойства PLL можно попробовать сделать в ПЛИС простейший радиопередатчик с фазовой модуляцией.

И кое-что получилось!

Продолжаем цикл про основы работы STM32MXCube и программированию микроконтроллеров STM32.

→ Часть 1
→ Часть 2

В прошлых частях мы освоили базовые настройки микроконтроллера, работу с GPIO, таймером, DMA и DAC. В этой части мы познакомимся с ADC и USB.

Очередное продолжение цикла заметок об операционной системе реального времени QNX. Сегодня я бы опять хотел рассказать о межзадачном взаимодействии, но только об одном определённом механизме — Persistent Publish/Subscribe (PPS, устойчивая служба публикации/подписки). Сразу хочу отметить, это новый вид взаимодействия в QNX Neutrino, который появился только в версии 6.5.0. Технология PPS реализована не в микроядре, и за работу этого механизма отвечает специальный менеджер с говорящим названием pps.

Служба PPS оказалась настолько надёжной, удобной и простой в использовании, что применяется в новых решениях и продуктах, таких как, например, Smart Energy, QNX Car и даже планшет BlackBerry PlayBook.

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

Надеюсь, что долгожданное продолжение цикла заметок об операционной системе реального времени QNX. В этот раз я бы хотел рассказать о Qnet — собственном сетевом протоколе QNX. Сразу уточню, что помимо родной сети Qnet, в QNX поддерживается стек протоколов TCP/IP, работа с которым в общем-то должна быть знакома администраторам Unix-подобных систем. Поэтому в заметке сначала немного расскажу о сетевом администраторе io-pkt, а потом более подробно о протоколе Qnet. По ходу повествования нас также ждут четыре лирических и одно техническое отступления.

Что такое Qnet?

Сеть QNX представляет собой группу соединённых между собой целевых систем, каждая из которых работает под управлением ОСРВ QNX Neutrino. В такой сети любая программа имеет доступ к любому ресурсу на любом узле (node, именно так называются отдельные компьютеры в сети). В качестве ресурса может выступать файл, устройство или процесс (в том числе обеспечивается и запуск процессов на другом узле). При этом целевые системы (те самые узлы) могут представлять собой компьютеры различных архитектур — x86, ARM, MIPS и PowerPC (текущая реализация Qnet работает в том числе и в cross-endian среде). Но словно этого мало, любое POSIX-приложение, портированное в QNX (для переноса зачастую требуется только пересборка) без всякой доработки будет обладать перечисленными выше способностями работы в сети Qnet. Заинтригованы, как это получается?

Продолжение цикла заметок об операционной системе реального времени QNX. В этот раз я хотел бы рассказать о межзадачном взаимодействии в QNX Neutrino (мы будем рассматривать QNX 6.5.0). В ОСРВ существует широкий набор механизмов межзадачного взаимодействия — от специфичного для QNX обмена сообщениями до знакомых разработчикам UNIX и POSIX сигналов и разделяемой памяти. И хотя большая часть заметки будет посвящена обмену сообщениями, но особенности использования сигналов, сообщений POSIX и разделяемой памяти будут также описаны. А дочитавшие до конца получат две плюшки к чаю.

Понимание принципа обмена сообщениями является необходимым для системного программиста QNX, т.к. этот механизм играет фундаментальную роль в ОСРВ. Многие привычные и знакомые разработчикам функции операционной системы являются лишь надстройками и реализованы при помощи обмена сообщениями (например, read() и write()).

Продолжение цикла заметок об операционной системе реального времени QNX. В этот раз я хотел бы рассказать о планировании потоков в QNX6^*. Как уже известно читателям (которые ознакомились с предыдущей заметкой цикла), микроядро QNX6 управляет потоками, а не процессами. И именно микроядро осуществляет загрузку контекста того потока, который должен получить управление в следующий момент. Выбор потока, который будет выполняться процессором (т.е. активно использовать процессорное время) и есть планирование потоков.

Когда происходит планирование потоков

Микроядро QNX Neutrino не работает постоянно, а получает управление только в случае системных вызовов, исключений и прерываний. Также микроядро во время своей работы выполняет планирование потоков. Отсюда можно сделать верный вывод, что операция планирования потоков происходит не сама по себе, а по какому-то событию.

Поскольку мой первый небольшой обзор операционной системы реального времени QNX показал, что среди жителей Хабра есть к ней интерес, то я решил продолжить цикл заметок. Мне кажется, что стоит немного рассказать о системной архитектуре QNX6. Думаю, что нелишне дать определение тому, что такое микроядро, и какие задачи оно решает. По ходу повествования будут также развенчаны два мифа, связанные с QNX. Но сначала…

Немного о POSIX

С выпуском каждой новой версии QNX (а надо отметить, что первая версия ОСРВ QNX появилась теперь уже в далёком 1981 году), разработчики использовали накопленный ранее опыт и делали систему лучше, в том числе и удобнее для разработчиков. Именно поэтому QNX Neutrino поддерживает стандарты POSIX 1003.1, например, управление потоками (threads), расширения реального времени (Realtime Extensions), дополнительные расширения реального времени (Additional Realtime Extensions) и профили прикладных окружений (Application Environment Profiles, AEP).

Зачем я об этом говорю?

Недавно прочитал пост из «Дополненной реальности», в котором упоминается Фильтр Калмана в сравнении с более простым «альфа-бета» фильтром. Давно собирался сочинить нечто вроде сниппета по составлению ФК, и вот думаю самое время. В статье я вам расскажу как на практике можно составить расширенный ФК не особо утруждая себя высоконаучными размышлениями и глубокими теоретическими изысканиями.

Доброго времени суток, хабр! Сегодня я бы хотел рассказать про жадные алгоритмы.

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

Думаю, каждый программист в своей жизни хотя бы раз написал жадину, может быть, даже не задумываясь об этом. Что же это такое? Добро пожаловать под кат.

Так уж случилось, что пару лет назад по долгу службы на команду разработчиков, к которой я отношусь, свалилась неожиданная задача — разработка системы управления оборудованием (в этом-то как-раз неожиданности нет, ибо направление разработок такое) с управляющим PC под Linux.
Разработки линуксовой части велись (да и ведутся) под Ubuntu, в среде Code::Blocks. Но, как показала практика, для качественной работы нужно что-то гораздо более легкое с гарантированным временем отклика. Для работы было достаточно консоли, так как задачи организации пользовательского интерфейса решались на подключаемом по TCP/IP удаленном компьютере.
Тогда и пришла идея использовать дистрибутив Linux собственной сборки, чем (сборкой дистрибутива), собственно, в свободное время я и занялся. Выбор пал на LFS. Про то что такое LFS уже неоднократно писали даже на Хабре, я же опишу решение нескольких дополнительных (кроме простенького Linux'а) задач, вставших передо мной в нашем конкретном случае.
Поначалу такая задача была одна — использовать real-time ядро.
Однако дальше, когда идея USB-флешки с дистрибутивом, пришлась всем по душе, то появились задачи размножения флешек и запуска системы на различных компьютерах (тестовых стендов много, имея свою флешку суешь в карман и иди к любому). Вот тут и появились проблемы — LFS не обладает 100% переносимостью с одного компьютера на другой. Для ее адаптации к конкретному компьютеру нужно править некоторые скрипты, что в условиях команды вчерашних Windows-кодеров проблематично (на виртуалку с Ubuntu некоторые пересели, но консоль и скрипты — это беда). Размножение системы также требует повторения некоторых манипуляций, проделываемых в процессе сборки (тот же GRUB установить).

Копаясь в дебрях LLVM, я неожиданно обнаружил для себя: насколько всё же интересная штука — оптимизация кода. Поэтому решил поделиться с вами своими наблюдениями в виде серии обзорных статей про оптимизации в компиляторах. В этих статьях я попытаюсь «разжевать» принципы работы оптимизаций и обязательно рассмотреть примеры.
Я попытаюсь выстроить оптимизации в порядке возрастания «сложности понимания», но это исключительно субъективно.
И ещё: некоторые названия и термины не являются устоявшимися и их используют «кто-как», поэтому я буду приводить несколько вариантов, но настоятельно рекомендую использовать именно англоязычные термины.

Так сложилось, что моя деятельность связана с операционной системой реального времени (ОСРВ) QNX. Уже несколько лет занимаюсь разработкой как под эту ОС, так и некоторых частей самой системы. Обратил внимание на то, что поиск на хабре выводит немного результатов по запросу QNX, однако, мне кажется, что эта ОСРВ может быть интересна не только специалистам по встраиваемым и высоконадёжным системам, но и более широкой публике. Не секрет, что планшетный компьютер BlackBerry PlayBook производства компании RIM основан на QNX и имеет популярность и у нас.

Немного о QNX

ОСРВ QNX это не клон или дистрибутив Linux или ответвление какой-то другой UNIX-подобной системы. QNX самостоятельная UNIX-подобная операционная система реального времени, основанная на микроядре и передаче сообщений. Современные версии QNX имеют поддержку стандартов POSIX (и сертифицированны по ним). Первая версия QNX вышла в далёком 1981 году. С тех пор утекло достаточно много времени и поколения QNX сменяли друг друга: QNX2, QNX4 и, наконец, QNX 6 (или QNX Neutrino). Старичок QNX2 и сейчас ещё используется, хотя его расцвет пришёлся на 80-е годы прошлого столетия. Надёжная и более современная ОСРВ QNX4 могла конкурировать на десктопе с Windows в середине 90-х

Рано или поздно каждый пользователь Линукса задумывается над созданием собственного дистрибутива. Некоторые аргументируют это тем, что можно «все настроить под себя». Другие сетуют на то, что среди уже представленных дистрибутивов в Ветке нет идеального. А у них, якобы, есть суперконцептуальные идеи для собственной системы. Зачем я всю эту психологию затеял? Для того, чтобы сразу перекрыть кислород играющимся с Линуксом новичкам, которым делать нечего. Если уж задумались над созданием ОС, думайте до конца. Итак,

Я хочу создать ОС на базе Linux.
Сразу предупреждаю: был бы XVIII век, всех тех, кто для основы своей будущей системы выбирает другой развитый дистрибутив (и, не дай Бог, популярный...) ждала бы виселица. Пост именно про создание системы с нуля, а значит, всякие Slax и Linux Mint мы трогать не будем.

Фильтр Калмана — это, наверное, самый популярный алгоритм фильтрации, используемый во многих областях науки и техники. Благодаря своей простоте и эффективности его можно встретить в GPS-приемниках, обработчиках показаний датчиков, при реализации систем управления и т.д.

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

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

Я постоянно дёргал их, снова и снова расспрашивал о всяких мелочах, а потом эти мелочи благополучно забывал. В конце концов, я задал им вопрос — а нет ли какого-нибудь обзорного документа, уткнувшись в который я бы избавил ребят от своего назойливого внимания? Не получив утвердительного ответа я решил написать эту статью, которая по завершению была вычитана Эдэмом Джексоном и Дэвидом Эйрли. Они оба работают над этим стеком.