Всем привет!

Возникла потребность написать быстрое вычисление Sin и Cos. За основу для вычислений взял разложение по ряду Тейлора. Использую в 3D-системах (OpenGL и графическая библиотека своей разработки). К сожалению свести ряд «идеально» для Double не получается, но это компенсируется хорошим ускорением. Код написан на встроенном в Delphi XE6 ассемблере. Используется SSE2.

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

В итоге:

1. Достигнутая точность результата равна: 10.e-13
2. Максимальное расхождение с CPU — 0.000000000000045.
3. Скорость увеличена в сравнении с CPU в 4.75 раза.
4. Скорость увеличена в сравнении с Math.Sin и Math.Cos в 2.6 раза.

Для теста использовал процессор Intel Core-i7 6950X Extreme 3.0 ГГц.
Исходный текст на Delphi встроен в комментарии к ассемблеру.

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

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

Итак, представляю драйвер-фреймворк для kernel-хакинга, написанный на C++17, и призванный, по возможности, снять барьеры между ядром и юзермодом или максимально сгладить их присутствие. А также, набор юзермодных и ядерных API и обёрток для быстрой и удобной разработки в Ring0 как для новичков, так и для продвинутых программистов.

Основные возможности:

• Доступ к портам ввода-вывода, а также проброс инструкций in, out, cli и sti в юзермод через IOPL
• Обёртки над системной пищалкой
• Доступ к MSR (Model-Specific Registers)
• Набор функций для доступа к юзермодной памяти других процессов и к памяти ядра
• Работа с физической памятью, DMI/SMBIOS
• Создание юзермодных и ядерных потоков, доставка APC
• Юзермодные Ob*** и Ps***-каллбэки и фильтры файловой системы
• Загрузка неподписанных драйверов и ядерных библиотек

… и многое другое.

От загрузчика к ядру

Если вы читали предыдущие статьи, то знаете о моём новом увлечении низкоуровневым программированием. Я написал несколько статей о программировании на ассемблере для x86_64 Linux и в то же время начал погружаться в исходный код ядра Linux.

Мне очень интересно разобраться, как работают низкоуровневые штуки: как программы запускаются на моём компьютере, как они расположены в памяти, как ядро управляет процессами и памятью, как работает сетевой стек на низком уровне и многое другое. Итак, я решил написать еще одну серию статей о ядре Linux для архитектуры x86_64.

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

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

Дисклеймер

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

Весь код, кроющийся за высокоуровневым, представлен для режима отладки, именно он показывают концептуальную основу. Также все изложенное рассмотрено для 32 битной платформы. JIT оптимизации — это отдельная и большая тема, которая здесь рассматриваться не будет.

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

Начинаем с теории

Любой код в конечном итоге становится набором машинных комманд. Наиболее понятно их представление в виде инструкций языка Ассемблера, прямо соответсвующих одной (или нескольким) машинным инструкциям.

Софту мы не доверяем уже давно, и поэтому осуществляем его аудит, проводим обратную инженерию, прогоняем в пошаговом режиме, запускаем в песочнице. Что же насчёт процессора, на котором выполняется наш софт? – Мы слепо и беззаветно доверяем этому маленькому кусочку кремния. Однако современное железо имеет те же самые проблемы, что и софт: секретную недокументированную функциональность, ошибки, уязвимости, малварь, трояны, руткиты, бэкдоры.

ISA (Instruction Set Architecture) x86 – одна из самых долгих непрерывно изменяющихся «архитектур набора команд» в истории. Начиная с дизайна 8086, разработанного в 1976 году, ISA претерпевает постоянные изменения и обновления; сохраняя при этом обратную совместимость и поддержку исходной спецификации. За 40 лет своего взросления, архитектура ISA обросла и продолжает обрастать множеством новых режимов и наборов инструкций, каждый из которых добавляет к предшествующему дизайну, и без того перегруженному, новый слой. Из-за политики полной обратной совместимости, в современных процессорах x86 присутствуют даже те инструкции и режимы, которые на сегодняшний день уже преданы полному забвению. В результате мы имеем архитектуру процессора, которая представляет собой сложно переплетающийся лабиринт новых и антикварных технологий. Такая чрезвычайно сложная среда – порождает множество проблем с кибербезопасностью процессора. Поэтому процессоры x86 не могут претендовать на роль доверенного корня критической киберинфраструктуры.

Я часто слышал, что для понимания работы компьютера люди предлагают изучать C. Это хорошая мысль? Вы уверены? Сразу изложу выводы статьи, просто для абсолютной ясности:

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

Я планирую написать ещё две статьи с более подробным объяснением выводов, но этого уже достаточно. Добавлю сюда ссылки, когда статьи выйдут.

Что я узнал об аркадном автомате Bomb Jack в процессе создания его эмулятора

Недавно я написал небольшой эмулятор автомата Bomb Jack, в основном для того, чтобы разобраться, чем эти первые 8-битные аркадные автоматы отличались по конструкции от 8-битных домашних компьютеров.

Как я узнал намного позже, встреча на летней ярмарке в моём родном городе с аркадными автоматами наподобие Bomb Jack стала одним из тех моментов, которые переменили мою судьбу. Обычным летним днём, потратив весь свой запас монет на аркадные автоматы, я возвращался домой, и голова моя была заполнена цветами и звуковыми эффектами. Я пытался понять, как работали эти игры. А затем до конца года я тратил всё своё время после школы на создание довольно блеклых копий этих аркадных игр на домашнем компьютере. Я походил на поклонника карго-культа с островов Тихого океана, желавшего создать американскую военную радиостанцию из палок.

Сначала я думал над идеей создания эмулятора Pengo, потому что мой подростковый мозг эта игра впечатлила гораздо сильнее, чем Bomb Jack (кстати, вот моя карго-культовая версия Pengo). Но аркадное оборудование Pengo потребовало бы создания эмуляторов новых чипов для звука и видео, а для Bomb Jack оказалось достаточно уже имевшихся у меня частей (Z80 в качестве ЦП и AY-3-8910 для звука), поэтому первым я взялся за Bomb Jack.

Эта статья о трансляторе эзотерического языка на TurboAssembler'e (TASM).
P′′ — низкоуровневый язык программирования, созданный в 1964 году Коррадо Бёмом.
Этот язык разрабатывался для реализации циклов без использования оператора GOTO.
В данной статье демонстрируется создание некого транслятора на низком уровне, в котором обработка текста программы (строки) производится посредством условных и безусловных переходов, т.е. низкоуровневых эквивалентов оператора GOTO.

Вот здесь лежит форк визуализатора(visualizer), позволяющего выполнить отладку bf-программ в пошаговом режиме

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

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

Пусть массив data_arr представляет память данных (ленту Тьюринга), пусть строка str_arr содержит команды.

Напишем программу, выводящую символ, ascii-код которого соответствует количеству + (поэтому нам нужны будут только команды + и .)

var
 data_arr:array[1..10] of integer;    // массив данных
 str_arr: string;                     // команды  
 i, j: integer;                       // индексы строки и массива
begin
 j:=1;                  // нумерация элементов массива начинается с единицы
 readln(str_arr);       //считываем строку

 for i:=1 to length(str_arr) do begin    // в цикле обрабатываем строку
  if (str_arr[i]='+') then data_arr[j]:= data_arr[j]+1;
  if (str_arr[i]='.') then write(chr(data_arr[j]));
 end;
end.

bf-код +++++++++++++++++++++++++++++++++. выдаст ! (ascii-код символа ! равен 33 ).

Программу можно проверить в online ide ideone.com

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

Привет всем,

Спустя довольно-таки продолжительное время с момента написания первой статьи я всё-таки решил, пусть и по чуть-чуть, но писать статьи на тему модификации/улучшения IDA Pro.

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

Скриншот интерфейса дизассемблера IDA Pro

IDA Pro — знаменитый дизассемблер, который уже много лет используют исследователи информационной безопасности во всем мире. Мы в Positive Technologies также применяем этот инструмент. Более того, нам удалось разработать собственный процессорный модуль дизассемблера для микропроцессорной архитектуры NIOS II, который повышает скорость и удобство анализа кода.

Сегодня я расскажу об истории этого проекта и покажу, что получилось в итоге.

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

В этой статье мы напишем с нуля калькулятор обратной польской записи (RPN) на чистом ассемблере x86. Когда закончим, то сможем использовать его так:

$ ./calc "32+6*" # "(3+2)*6" в инфиксной нотации
30

Весь код для статьи здесь. Он обильно закомментирован и может служить учебным материалом для тех, кто уже знает ассемблер.

Начнём с написания базовой программы Hello world! для проверки настроек среды. Затем перейдём к системным вызовам, стеку вызовов, стековым кадрам и соглашению о вызовах x86. Потом для практики напишем некоторые базовые функции на ассемблере x86 — и начнём писать калькулятор RPN.

«Finally, we come to the instruction we've all been waiting for – SEX!»
/ из статьи про микропроцессор CDP1802 /

В начале 1970-х в США были весьма популярны простые электронные игры типа Pong (в СССР их аналоги появились в продаже через 5-10 лет). Как правило, такие игры не имели микропроцессора и памяти в современном понимании этих слов, а строились на жёсткой логике. Соответственно, сменные картриджи не имели особого смысла, а там где они были — представляли собой просто набор перемычек, включающих нужную игру.

В 1977 году были почти одновременно выпущены две консоли: Fairchild Channel F и RCA Studio II. Это были первые игровые приставки в виде полноценных компьютеров — с микропроцессором и программами на сменных картриджах.
Приставка RCA Studio II, о которой пойдёт речь, является разработкой не столько фирмы RCA, сколько конкретного человека — Joseph A. Weisbecker (как и вся архитектура COSMAC).

Хотел сделать демку с тех самых пор, как познакомился с этим явлением компьютерной субкультуры на классическом примере польской Lyra II. Также регулярно хотел выставить что-нибудь на крупнейшем российском демопати, Chaos Constructions, но каждый раз не доходили руки. Наконец-то удалось удовлетворить обе потребности сразу, в стиле Ван Дамма (двойной удар, с вертушки) — сделать и выставить AONDEMO. В конкурсе ZX Spectrum 640K Demo.


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

Изначально я не планировал делать демо на Chaos Constrictions 2018, однако за 2-3 недели до cc понял, что с пустыми руками идти на демопати никак нельзя, и решил написать небольшую демонстрацию для 386/EGA/DOS.

Скомпилировав в Turbo-C под DOS свою либу AnotherGraphicsLibrary, которая идеально ложиться в битплановую структуру EGA режима, я разочаровался, от тормозов, прежде всего тормозов EGA. Демо в том виде, в котором я хотел бы его видеть, за этот весьма ограниченный срок, сделать было невозможно.

Однако сдаваться и не делать что-либо, я уже не мог. И тут я вспомнил, что давно хотел принять участие в ZX-Spectrum конкурсах демо. А так, как за последний год у меня появилось целых два 48k реала, я мог получить определенное удовольствие от создания демо. К слову — для меня самое главное в написании демо это именно тестирование на реале, эмульгаторы не дают такого наслаждения от процесса, уж очень это замечательное чувство, когда после очередного изменения в коде ты закачиваешь демо на реал, и видишь как настоящая железка тасует байтики в памяти, отрисовывая эффект.

Поскольку из реалов у меня только 48k, то и демо я решил сделать для 48k. А из-за ограниченности сроков и отсутствия каких-либо наработок, выбор пал на создание 1k intro(демо объёмом всего 1 килобайт, или 1024 байта).

Добрый день! Сегодня я хочу рассказать вам как написать минимальную программу, которая запустится на ARM Cortex-M3 и при этом напечатает “Hello, World!”. Постараемся разобрать по шагам необходимый минимум, который нам для этого потребуется. Запускать будем на эмуляторе QEMU. Поэтому любой желающий может воспроизвести, даже если у него нет под рукой железки.

Итак, поехали!

… или как выстрелить себе в ногу на Arduino

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

Сейчас в нём установлена плата Arduino Mega с процессором ATmega2560, в котором целых 256 килобайт флеш-памяти. Предполагалось, что этого хватит очень надолго, ведь игры получаются простые (экран-то всего лишь 64x64 пикселя). В реальности мы столкнулись с некоторыми проблемами уже по достижении прошивкой размера примерно 128 килобайт.

Части первая, вторая, третья.

Остальная часть автомата

Написанный нами код для эмуляции процессора 8080 достаточно общий и может быть с лёгкостью адаптирован для запуска на любой машине с компилятором C. Но чтобы поиграть в саму игру, нам нужно сделать большее. Придётся эмулировать оборудование всего аркадного автомата и написать код, приклеивающий специфические особенности нашей вычислительной среды к эмулятору.

(Вам может быть интересно посмотреть на принципиальную схему автомата.)

В 1974 году Texas Instruments выпускает первые 4-битные микроконтроллеры семейства TMS1000, а Intel в 1976 начинает производство 8-битных микроконтроллеров своей известной серии MCS-48. И тут началось.

Части первая и вторая.

Эмулятор процессора 8080

Оболочка эмулятора

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

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

Для начала я создам структуру памяти, которая будет содержать поля для всего, что показалось мне необходимым при написании дизассемблера. Также там будет место для буфера памяти, который будет представлять собой ОЗУ.