Assembler *

Можно ли добавить в микропроцессор инструкции (команды)? Если вы используете микросхемы ПЛИС / 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].

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

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

Недавно мне показали эмуляторы ассемблера для Intel-4004 и я на некоторое время «зависла». Это «дедушка» нынешних процессоров — если верить статье википедии — первый коммерчески распространённый микропроцессор.

Вряд ли его сейчас можно использовать для каких-то серьёзных целей. А вот просто поломать голову (вместо brainf**k) — ну, это то чем я занялась. Главное он 4-разрядный и набор команд довольно небольшой (до того я знала только немножко x86-й, по мучительному институтскому курсу).

Ниже идет вольный перевод-пересказ вот этой инструкции по ассемблеру для Intel-4004 — и краткие замечания о моих попытках написать что-нибудь на нём.

Очень долго мелкие растровые шрифты были бичем KolibriOS. Но относительно недавно к проекту присоединился еще один разработчик — Pathoswithin. Быстро сориентировавшись в проекте, он взялся за решение данной проблемы. Результаты его работы вы можете наблюдать в последних ночных сборках. Ну а данная статья является повествованием о работе над шрифтами, написанная самим Pathoswithin.

От переводчика. Представляю вашему вниманию перевод поста Майкла Штейла (Michael Steil) http://www.pagetable.com/?p=308. В нём затрагиваются вопросы сомнительной практики именования сущностей в спецификациях вычислительных архитектур.
Эта заметка очень хорошо отражает ситуацию с именами, возникающую в процессе длительной эволюции документации, и моё собственное недоумение, когда я впервые встретился с этими понятиями.
Комментарии к тексту размещены во всплывающих подсказках.

Эта статья представляет из себя рассказ о том как устроены исполняемые файлы (в точку! Это именно те штуки, которые получаются после компиляции приложений с расширением .exe). После того, как написан код, подключены библиотеки, подгружены к проекту ресурсы (иконки для окон, какие-либо текстовые файлы, картинки и прочее) всё это компонуется в один единственный исполняемый файл, преимущественно с расширением .exe. Вот именно в этот омут мы и погрузимся.
*Статья находится под эгидой «для начинающих» поэтому будет изобиловать схемами и описанием важных элементов загрузки.