Я работаю с программными моделями центральных процессоров в составе полноплатформенного симулятора. Занятие это, конечно же, очень интересное — приходится иметь дело с технологиями интерпретации, двоичной трансляции, виртуализации (об этом я уже писал здесь). Однажды моё внимание привлёк тот факт, что значительную часть времени я вожусь над единственной, казалось бы, не самой вычислительно интенсивной инструкцией. Причина в том, что типов процессоров существует много, и все они во многом похожи; однако при этом критически важно очень точно представлять различия между ними.
В этой статье я описываю, зачем и как процессоры умеют сообщать о своих возможностях, и как к этому вопросу подошли разные производители. В её продолжении я расскажу об эволюции и особенностях инструкции CPUID для Intel IA-32, например, почему её описание занимает в Intel SDM [1] около 40 страниц.

Даже самые серьезные разработчики, пишущие на ассемблере и знающие наизусть все клавиатурные шоткарты, не смогут оспорить то, что все больше устройств и их пользователей поддерживают сенсорный ввод (touch screen), поэтому обработка сенсорных методов взаимодействия в приложениях становится все более важной. Стандартные элементы управления и шаблоны Windows 8 хорошо работают с сенсорным вводом — если вы пользуетесь только ими, вам нет необходимости разбираться в технических подробностях. Если же вы имеете дело с классическими приложениями или хотите разработать собственные элементы управления (например, для игры), то должны знать, как правильно обрабатывать сенсорный ввод.

На хабре было несколько статей по преобразованию Фурье и о всяких красивостях типа Цифровой Обработки Сигналов (ЦОС), но неискушённому пользователю совершенно не понятно, зачем всё это нужно и где, а главное как это применить.


АЧХ шума.

Лично мне после прочтения этих статей (например, этой ) не стало понятно, что это и зачем оно нужно в реальной жизни, хотя было интересно и красиво.
Хочется не просто поглядеть красивые картинки, а так сказать, ощутить нутром, что и как работает. И я приведу конкретный пример с генерацией и обработкой звуковых файлов. Можно будет и послушать звук, и поглядеть его спектр, и понять, почему это так.
Статья не будет интересна тем, кто владеет теорией функций комплексной переменной, ЦОС и прочими страшными темами. Она скорее для любопытствующих, школьников, студентов и им сочувствующих :).

Многие пробовали играть во Flappy Bird. Редко кому удается пролететь за 50 труб, очень немногие долетают до сотни-двух. Некоторые пробовали создать бота, в том числе на хабре. Удивительно, но даже у самого успешного бота, которого можно найти на просторах интернета, результаты не очень-то впечатляют – что-то около 160 очков. Возникает вопрос, а можно ли вообще играть во Flappy Bird бесконечно долго? Или всегда с некоторой, пусть и небольшой, вероятностью может встретиться последовательность препятствий, которую даже опытный игрок/идеальный бот не сможет преодолеть?

И тут на помощь приходит математика. Давайте найдем выигрышную стратегию для Flappy Bird.

С момента появления сенсора Kinect for Windows я питал тихую страсть к программированию такого рода устройств – ведь это волшебное чувство, когда написанная тобой программа отзывается на движения человека на расстоянии! Сегодня я расскажу вам про программирование ещё одного похожего устройства – Leap Motion.



По сути дела, Leap Motion – это небольшой Kinect, который может распознавать положение кистей рук. По замыслу создателей (хорошо отраженных в этом видео), его можно использовать для управления компьютером во множестве различных сценариев. В этом посте мы рассмотрим, как программируется Leap Motion (на платформе .NET), и как можно на его основе создать простой музыкальный инструмент – терменвокс. Вот такой:

Делюсь своим опытом, полученным при изучении задачи вынесенной в заголовок. В статье рассматриваются два варианта работы, которые можно использовать в Python-программах, обращающихся к портами GPIO Raspberry Pi.

Порты GPIO Raspberry Pi выглядят следующим образом:

Для чего эта статья?

Все эмбеддеры, рано или поздно, сталкиваются с проблемой нехватки ПЗУ микроконтроллера для своих проектов. Ну банально, Вам нужно разработать систему управления простеньким ЧПУ станком, где управляющая программа хранится на самом девайсе или систему сбора данных, скажем, от датчиков какого-нибудь эксперимента – очевидно, что микроконтроллер изначально не предназначался для хранения таких массивов информации.

Мне со школьных времен был интересен алгоритм вывода аналитических производных и упрощения выражений. Данная задача была актуальна впоследствии и в вузе. Тогда-то я реализовал ее, только получилось все не так, как хотелось: вместо кода IL у меня просто генерировался C# код в текстовом виде, сборки не выгружались, ну и к тому же не было возможности вывода производных в аналитическом виде. Однако потом я решил все-таки реализовать такую библиотеку, так как интерес остался. Стоит отметить, что таких библиотек в интернете большое количество, но нигде я не нашел именно этапа компиляции выражений в IL код, т.е. по сути везде выполняется интерпретация, которая не столь эффективна, в отличие от компиляции. Ну и к тому же я это разрабатывал чисто для себя, для изучения новых технологий, особо не надеясь, что результат моих трудов может где-нибудь потребоваться. Для нетерпеливых: исходники, программа.

Используемые программы и библиотеки

1. GOLD Parsing System — IDE для написания грамматик и генерации кода лексеров и парсеров под различные языки (C, C#, Java, JavaScript, Objective-C, Perl, Python, Ruby и др.). Основана на LALR парсинге.
2. Visual Studio 2010
3. GOLD.Engine — сборка под .NET, подключаемая для взаимодействия со сгенерированными таблицами.
4. NUnit — Открытая среда юнит-тестирования приложений для .NET.
5. ILSpy — OpenSource дизассемблер под .NET.

Этапы, на которые я разбил весь процесс:

1. Построение дерева выражения
2. Вычисление аналитической производной
3. Упрощение (симплификация) выражения
4. Обработка рациональных дробей
5. Компиляция выражения

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

В предыдущих трех частях мы создали лексер, парсер и AST для нашего игрушечного языка IMP. Мы даже написали нашу собственную библиотеку парсеров комбинаторов. В этой, финальной статье мы напишем последний компонент интерпретатора — исполнитель.


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

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

В чем подвох?

На первый взгляд задача кажется тривиальной: скачиваем keil, создаем проект… Но все не так просто. Все среды программирования(keil, IAR, Atolic) поддерживают максимум ARM9.У нас же ARM11. Это связано с негласным правилом, что на голом железе пишут до ARM9, а после на Линуксе. Но все-таки есть одна лазейка: arm-none-eabi-gcc поддерживает любой ARM.
Вторая проблема заключается в том, что под данный процессор(BCM2835) нет никаких конфигурационных файлов, header'ов и т.д. Здесь нам на помощь придет загрузчик Raspberry Pi. И ничего, что он пропритетарный. Он выполняет две функции: инициализирует процессор и его периферию, а также передает управление ядру kernel.img. Мы просто замаскируем свою программу под ядро и загрузчик её запустит.

Пожалуй, самый частый вопрос, который разработчики KolibriOS слышат в свой адрес: "Когда вы собираетесь портировать Колибри на ARM?" Мы всегда отвечаем, что это невозможно, KolibriOS написана на ассемблере FASM с использованием инструкций x86, и портирование её на ARM будет означать практически полное переписывание с нуля. Но главная причина в том, что на рынке есть достаточно компьютеров на x86-совместимых процессорах, размером как Raspberry Pi и стоимостью всего на $5-$35 дороже, а это делает портирование не только невозможным, но также и бесполезным занятием. Чтобы читатели не говорили, что x86-совместимый компьютер за $40 — это «сферический конь в вакууме», я решил написать обзорный цикл из 3 статей о нескольких таких компьютерах. Сразу оговорюсь, что статьи не спонсируются — всё это железо я покупал на свои деньги, и на части него я практически каждую неделю тестирую Колибри — не стала ли она, случаем, слишком медленной? Кому интересно — прошу под кат.

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

В 2ГИС сервис пробок появился в сентябре 2011 года и сегодня работает в пяти городах (Новосибирск, Санкт-Петербург, Красноярск, Уфа, Казань). В планах на ближайшее будущее — запустить пробки во всех городах-миллионниках.

Под катом история про то, с какими проблемами мы столкнулись и как их решили.

Однажды, совсем недавно, на планшетах с Windows Microsoft потеряла миллионы долларов. Ну а мы сегодня просто будем писать под них на ассемблере.



Нам понадобятся следующие вещи.

• Установленная Microsoft Visual Studio с поддержкой ARM ассемблера, например 2012.
• Jailbreak'нутый планшет с установленной Windows RT, например Microsoft Surface RT.

Для начала создадим отдельную папку для проекта, в которой создадим файл arm.asm, содержимое которого под катом.

В этой лекции на примере Яндекса будут рассмотрены базовые компоненты, необходимые для организации интернет-поисковика. Мы поговорим о том, как эти компоненты взаимодействуют и какими особенностями обладают. Вы узнаете также, что такое ранжирование документов и как измеряется качество поиска.

Лекция рассчитана на старшеклассников – студентов Малого ШАДа, но и взрослые могут узнать из нее много нового об устройстве поисковых машин.





Первый компонент нашей поисковой машины – это Паук. Он ходит по интернету и пытается выкачать как можно больше информации. Робот обрабатывает документы таким образом, чтобы по ним было проще искать. По простым html-файлам искать не очень удобно. Они очень большие, там много лишнего. Робот отсекает все лишнее и делает так, чтобы по документам было удобно искать. Ну и непосредственно поиск, который получает запросы и выдает ответы.

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

Задумывались ли вы над тем, как именно используется память, доступная вашей программе, да и вообще, что именно размещается в этих двух-трех гигабайтах виртуальной памяти, с которыми работает ваше ПО?

Спросите, зачем?
Ну как же, для 32-битного приложения 2-3 гигабайта – это ваш лимит за пределы которого без использования AWE вы выбраться не сможете, а контролировать собственные ресурсы все же желательно. Но даже и без этого просто с целью разобраться…

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

Давайте посмотрим, как именно программист работает с памятью при отладке (особенно при отладке стороннего приложения, проще говоря, при реверсе):

1. Как правило, самой частой операцией будет поиск значения в памяти приложения и, к сожалению, данный функционал почему-то не предоставлен в отладчике Delphi (собственно, как и в MS VC++).
2. Модификация системных структур (PEB/TEB/SEHChain/Unwind/директорий PE-файлов etc...) будет происходить гораздо проще, когда поля структур размаплены на занимаемые ими адреса и представлены в читабельном виде.
3. Отслеживание изменений в памяти процесса (практически никем не предоставляемый функционал, реализованный в виде плагинов к популярным отладчикам). Действительно, зачем трассировать до посинения, когда достаточно сравнить два снимка карты памяти, чтобы понять, тут ли происходит нужная нам модификация данных или нет?

Да, собственно, вариантов использования много.

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

Компанией Intel в 2008 г. были предложены новые команды для x86 архитектуры, которые добавили поддержку на аппаратном уровне симметричного алгоритма шифрование AES(Advanced Encryption Standard). На данный момент AES — один из самых популярных алгоритмов блочного шифрования. Поэтому аппаратная реализация должна привести к повышению производительности программ использующих этот алгоритм шифрования(OpenSSL, The Bat, TrueCrypt ...). Новое расширение команд получило название AES-NI. Оно содержит в себе следующие инструкции:

• AESENC — Выполнить один раунд шифрования AES,
• AESENCLAST- Выполнить последний раунд шифрования AES,
• AESDEC — Выполнить один раунд расшифрования AES,
• AESDECLAST — Выполнить последний раунд расшифрования AES,
• AESKEYGENASSIST — Поспособствовать в генерации раундового ключа AES,
• AESIMC — Обратный Mix Columns.

Так как про сам алгоритм шифрования AES было уже было сказано многое, то в этом посте рассмотрим, как можно воспользоваться этими инструкциями.

Сегодня я хочу рассказать вам о префиксах в системе команд Intel IA-32 в 32- и 64-битных вариантах (также именуемых как x86 и x86_64). Но для начала напомню вкратце общую структуру IA-32 инструкции:

• Префиксы. Могут отсутствовать. Может присутствовать сразу несколько.
• Опкод. Может состоять из одного, двух или трех байтов.
• Mod_R/M байт. Используется для адресации операндов. Может отсутствовать в кодировке, если инструкция не имеет явных операндов.
• SIB (Scale Index Base) байт. Второй байт, использующийся для адресации операндов в памяти. Может отсутствовать.
• Байт смещения адреса (англ. displacement). 1, 2, 4 или ни одного байта.
• Константа (англ. immediate). 1, 2, 4 или ни одного байта.

Введение

С недавнего времени я увлекся микроконтроллерами. Сначала AVR, затем ARM. Для программирования микроконтроллеров существует два основных варианта: ассемблер и С. Однако, я фанат языка программирования Форт и занялся портированием его на эти микроконтроллеры. Конечно, существуют и готовые решения, но ни в одном из них не было того, что я хотел: отладки с помощью gdb. И я задался целью заполнить этот пробел (пока только для ARM). В моем распоряжении была плата stm32vldiscovery с 32-битным процессором ARM Cortex-M3, 128кБ flash и 8 кБ RAM, поэтому я и начал с нее.
Писал я кросс-транслятор Форта конечно на Форте, и кода в статье не будет, так как этот язык считается экзотическим. Ограничусь достаточно подробными рекомендациями. Документации и примеров в сети по предмету почти нет, некоторые параметры подбирались мной путем проб и ошибок, некоторые — путем анализа выходных файлов компилятора gcc. Кроме того, я использовал только необходимый минимум отладочной информации, не касаясь, например, relocation-ов и множества других вещей. Тема очень обширна и, признаюсь, разобрался я с ней только процентов на 30, что оказалось для меня достаточным.