Assembler *

Последняя статья про классические примитивы синхронизации.

(Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

Сегодня мы немножко заглянем в процессор. Чуть-чуть.

По сути, мы будем говорить про единственный примитив, который принципиально отличается от остальных: спинлок. Spinlock.

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

На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

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

Дело в том, что внутри ядра мьютекс реализован с помощью спинлоков, а вот спинлоки реализованы сами по себе, автономно. Они — действительно базовый примитив. Ниже — только сам процессор.

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

Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

Как устроен спинлок?

Развитие Колибри продолжается. И в последнее время было уделено больше усилий на то, чтобы сделать ее более дружелюбной и комфортабельной для простого пользователя. Для этого относительно недавно был внедрен новый системный шрифт и сейчас ведется работа по переводу программ на его использования, а также улучшение их внешнего вида. Были также написаны некоторые программы для простых пользователей, чтобы упростить им работу и знакомство с ОС, и уверен в том, что это только начало. Ну и, конечно, добро пожаловать под кат всем тем, кто хочет узнать больше.

Архитекторы процессоров архитектуры x86 исторически были против предоставления программистам возможности непосредственного управления кэшем. Один как-то сказал мне в 2009 году — «никогда мы этого не сделаем, кэш всегда должен быть прозрачным для программиста». Некоторые RISC процессоры представляют архитектурную возможность управления данными/кодом, который окажется в кэше. И вот, наконец-то, нечто подобное появилось и в архитектуре x86 (начиная с Broadwell*).

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

1. Искусственно загрузить ядро процессора, на котором запущена игра
2. Запускать игру в виртуальной машине с ограниченными ресурсами
3. Играть не по локальной сети, а по интернету — там задержки побольше

Можно ли добавить в микропроцессор инструкции (команды)? Если вы используете микросхемы ПЛИС / FPGA с реконфигурируемой логикой и микропроцессорное ядро, которые синтезирутся из описания на языках Verilog и VHDL, то можете. Причем это будет «честное», настоящее расширение системы команд, а не трюк типа программной эмуляции инструкции в обработчике исключения от зарезервированной команды, и не «микрокод», популярный в исторических процессорах 1970-х годов.

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

Главная проблема с модификацией исходников дизайна процессора на Verilog или VHDL — трудоемкость. Нужно понять, как работает логика различных блоков и избежать нежелательных побочных эффектов. К счастью, существует способ расширения процессора, который превращает семестровый студенческий проект в нечто, что студент может спроектировать за одну лабораторную работу. Этот способ — интерфейс CorExtend / UDI (User Defined Instructions) в микропроцессорном ядре MIPS microAptiv UP, которое используется в пакете для образования MIPSfpga.

В рамках университетской программы MIPSfpga компании Imagination Technologies можно скачать настоящий индустриальный код на Verilog процессора MIPS microAptiv UP.
https://community.imgtec.com/university/resources/

Одним из распространенных применений UDI является манипуляции битами в алгоритмах шифрования. Другой пример — создание специальных инструкций для ускорения алгоритмов ЦОС Accelerating DSP Filter Loops with MIPS® CorExtend® Instructions.

Однако в наборе документации к MIPSfpga интерфейс между ядром и CorExtend описан недостаточно подробно. Подробная документация предоставляется только лицензиатам ядер. В этой статье представлено мое описание данного интерфейса на основе изучения исходного кода. Его можно также скачать в формате pdf MIPS microAptiv UP Processor CorExtend UDI interface protocol guide.

CorExtend занимает следующее место в RTL иерархии ядра m14k microAptiv.

Недавно у нас были два юбилейных числа — 5000 пользователей в группе социальной сети ВКонтакте и 6000-й билд ОС. Поскольку группа vk.com/kolibri_os появилась относительно недавно и стремительно растет, то очевидно, что скоро количество участников этой группы обгонит количество билдов. И это значит, что нам надо понять, какая у нашего проекта активность и кто наши пользователи. И тут мы вспомнили, что 3 года назад начался уникальный социально-психологический эксперимент, о котором, среди прочего, мы и поведаем в этой статье.

“Кажется, что совершенство достигается не тогда, когда нечего более добавить, а тогда, когда нечего больше убрать."

(Антуан де Сент-Экзюпери)

По теме изучения программирования встроенных систем, ОС реального времени, Ассемблера и С позвольте представить очень простую операционную систему StartOS.

Предназначение:

— если вам необходимо создать устройство, начинающее работать через 1-2 секунды после включения питания и способное реагировать на сигналы из внешнего мира в течение микросекунд;
— для быстрого создания систем управления объектами с выводом данных в Интернет;
— отработка идей, алгоритмов, изготовлении прототипов устройств;
— приобретение опыта программирования встроенных систем на языках C и Assembler;
— получение полного доступа к «железу» компьютерного устройства, например, для разработки самомодифицирующихся программ.

Некоторые свойства системы:

Время готовности после включения питания: < 1 сек
Объем двоичного кода программы: < 40 kB

В комментариях к недавнему топику возникло обсуждение: до какого размера можно ужать Windows EXE, печатающий в консоли «Hello, World!» Ответ: 268 байт, меньшие файлы Windows просто отказывается загружать.

Раз для «Hello, World!» предел возможного ужатия уже достигнут, то мне стало интересно, до какой степени удастся ужать программу, делающую хоть что-нибудь более интересное.

Сначала похвастаюсь результатом: моя программа всего на 46 байт больше теоретического минимума!

Недавно закончился конкурс обратной разработки ZeroNight2015, проводимый «Лабораторией Касперского». Сама организация конкурса, с моей точки зрения, хромала, но статья не об этом. На конкурсе была представлена интересная задача под названием «Смартфон», разбору которой и будет посвящена данная серия статей. Эта статья будет посвящена описанию условия задачи и поиску защитного механизма. Вторая статья затронет оптимизацию скорости работы взламываемой программы посредством внедрения X-кода. В третьей статье будет описан процесс поиска ошибок во внедренном коде с использованием юнит-тестирования.

Я хотел бы рассказать о том, как я писал реализацию «Hello, World!» на C. Для подогрева сразу покажу код. Кого интересует как до этого доходил я, добро пожаловать под кат.

#include <stdio.h>
const void *ptrprintf = printf;
#pragma section(".exre", execute, read)
__declspec(allocate(".exre")) int main[] =
{
    0x646C6890, 0x20680021, 0x68726F57,
    0x2C6F6C6C, 0x48000068, 0x24448D65,
    0x15FF5002, &ptrprintf, 0xC314C483
};

Сегодня я расскажу, как можно динамически подменять обработчики прерываний в процессорах ARM на примере микроконтроллеров STM32. Описанный мною способ работает в процессорах ARM Cortex M3 и выше.

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

MIPSfpga — это пакет, который содержит процессорное ядро в исходниках на Verilog, которое можно менять, добавлять новые инструкции, строить многопроцессорные системы, менять одновременно софтвер и хардвер, симулировать на симуляторе верилога, синтезировать для ПЛИС/FPGA и т.д. Его можно в целях эксперимента например запускать с частотой 1 такт в секунду и выводить наружу информацию о состоянии кэша, конвейера, и любых структур внутри процессора. При этом ядро MIPS microAptiv UP внутри MIPSfpga — это то же ядро которое например используется в платформе IoT Samsung Artik 1 и Microchip PIC32MZ, т.е. студенты получают возможность работать с тем же кодом, с которым работают инженеры в Samsung и Microchip.

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

Вновь приветствую читателей «Хабра»!

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

Доброго времени суток, %username%! Сегодня мы отправимся изучать бесчисленные возможности фреймворка для реверсера — radare2. В виде подопытного я взял первую попавшую бомбу, она оказалась с сайта Университета Карнеги Меллон.

Мы решили поздравить всех читателей блога с наступившим Новым годом и подвести итоги прошедшего. Конец 2015 года ознаменовался круглыми числами — 6000-й билд в SVN и 5000-й участник группы https://vk.com/kolibri_os социальной сети ВКонтакте.

После прочтения статьи Самая опасная функция в мире С/С++ я счёл полезным углубиться во зло, таящееся в тёмном погребе memset, и написать дополнение, чтобы шире раскрыть суть проблемы.

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

Автор назвал эту технику “loops fracking” по аналогии с, например, “loops unrolling” или “loops nesting”. Тем более, что термин отражает смысл и не занят.

Прошлое

Повествование можно начать с 1962 г., когда в Кембриджском университете началась работа над CPL («Cambridge Programming Language») — «усовершенствованным вариантом» ALGOL-60. К работе над языком подключился аспирант Мартин Ричардс; главной сложностью в реализации нового ЯП ему показалась необходимость ручного портирования компилятора для разных компьютерных платформ. В частности, когда кембриджский EDSAC-2 заменили на Atlas-2, разработчики CPL потратили много времени на портирование своего компилятора для новой платформы.

Диссертация Мартина была посвящена «само-компилирующемуся» CPL: разработанный Мартином компилятор был написан на сильно упрощённом варианте CPL, компилятор которого несложно было написать на тогдашнем макроассемблере. Перенос CPL на новую платформу теперь можно было выполнить в два шага:

1. Вручную пишем компилятор «упрощённого CPL»;
2. Компилируем им компилятор «полного CPL».

На этом Мартин не остановился, и разработал BCPL — систему для разработки переносимых компиляторов. Компилятор BCPL генерировал псевдокод, названный Мартином «OCODE».
— а отдельная программа, кодогенератор, превращала файл с таким псевдокодом в исполнимую программу для конечного процессора. OCODE сохранялся в виде текстового файла из десятичных чисел, разделённых пробелами и переводами строк: в то время, когда OCODE разрабатывался, привязка формата файла к конкретному размеру байта ограничивала бы переносимость такого файла.

Компилятор BCPL⁽¹⁾ поставлялся в виде OCODE, и чтобы перенести его на новую платформу, нужно было:

1. Вручную написать интерпретатор псевдокода⁽²⁾ (на любом языке, хоть на Бейсике);
2. Адаптировать кодогенератор,⁽³⁾ написанный на BCPL, для своей платформы;
3. Запустить под интерпретатором (2) компилятор BCPL (1), скормить ему кодогенератор (3), и получить на выходе исполнимый файл кодогенератора⁽⁴⁾;
   • Интерпретатор (2) нам с этого момента больше не нужен.
4. Прогнать через кодогенератор (4) псевдокод компилятора (1), и получить на выходе исполнимый файл компилятора.

Такой подход означал, что для переноса компилятора на новую платформу требуется лишь самый минимум низкоуровневого программирования; и действительно, реализация BCPL была завершена к 1967 г. — раньше, чем была завершена реализация CPL, начатая на несколько лет раньше!

Достоинства BCPL применительно к системному программированию вдохновили Кена Томпсона на создание языка Би, а тот — коллегу Кена, Денниса Ритчи, на создание Си. Именно из BCPL пошла традиция обозначать {фигурными скобками} блоки программы, и именно на BCPL была написана первая программа «Hello, World!».

GET "libhdr"

LET start() = VALOF
{ writef("Hello*n")
  RESULTIS 0
}

Более важная нам причина, по которой BCPL вошёл в историю: OCODE — первая универсальная «архитектура набора команд» (ISA), т.е. «виртуальная машина», не привязанная ни к какой конкретной аппаратной платформе с её особенностями. BCPL, таким образом — первый язык программирования, соответствующий парадигме «Write once, run anywhere» (WORA): программу на BCPL можно распространять в скомпилированном виде, и её можно будет запустить на любой платформе, для которой существует OCODE-кодогенератор.

Я планировал написать данную статью уже давно, но в последние месяцы никак не мог выкроить достаточно времени. Пока я размышлял над статьёй, делал примеры и проверял свои догадки, на Хабре уже обсудили константность — ^[1][2].

Ради забавы попробуем проделать подобную экономию не со сферическим проектом в вакууме, а с самым что ни на есть живым и грандиозным проектом — с ядром Линукс!

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