Assembler *

Отобрал для вас несколько крайне интересных, но малоизвестных проектов, реализующих работу с XML и JSON. Кроссплатформенных и без зависимостей. На чистом С и ассемблере.

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

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

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

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

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

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

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

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

В этой статье я расскажу о микроконтроллерах Sunplus с ядром 6502 которые использовались в популярных в 90-е «тетрисах» Apollo, а также об их эмуляции. Отдельно опишу способ запуска своего кода на этих играх и в частности проигрыватель «Bad Apple!!», крупнопиксельный кадр из которого показан на КПДВ.

Волей случая мне в руки попал ноутбук с гибридным процессором i7-13850HX, у которого есть производительные "Р" и эффективные "Е" ядра, и захотелось разобраться чуть поглубже, процессор довольно любопытный. Под катом мы сделаем несколько несложных замеров производительности.

Привет Хабр! В этой статье я хотел поговорить о теме вечных конфликтов разработчиков на C++ и Rust. Стоит ли того система управления памятью в Rust или все-же это бестолковый механизм стремящийся составить конкуренцию родному методу?

Систему управления памятью я разберу, а вот выводы остаются уже за вами.

Когда в 19-летнем возрасте я покупал свой первый компьютер, то я очень сильно хотел купить БК-0010-01. Однако обстоятельства сложились так, что к моменту, когда у меня появилась необходимая сумма, в магазинах БК‑шек не осталось, и вообще ничего не осталось. На полке в «Электронике» лежало только невзрачное нечто с нарисованной клавиатурой и названием «ЛИК».

Здравствуйте, уважаемые читатели Хабра и любители вирусного анализа!

Сегодня хочу поделиться своим дебютным(на Хабре) разбором простенького семпла шелла под Linux.

Начнём.

Откроем в файл в DIE. Семпл для 32-битной UNIX системы, не упакован.

Когда я решил написать программу для простой цифровой фотосъёмки на Apple II, то думал использовать камеры Quicktake. Выбор казался очевидным, потому что это были камеры Apple, способный подключаться к компьютеру через последовательный порт.

Объём задачи немного расширился, когда мне удалось декодировать фотографии Quicktake 100: захотелось научиться декодировать фотографии Quicktake 150 и Quicktake 200. Из-за этого пришлось погрузиться в тему обработки изображений глубже, чем мне хотелось изначально. В этой статье я расскажу о том, как мне удалось заставить работать декодер Quicktake 150 с достаточно приемлемой скоростью на процессоре 6502 с частотой 1 МГц.

Формат Quicktake 150 проприетарный и не имеет документации, однако в проекте dcraw существуют свободные программные декодеры. Они стали моим фундаментом для создания первого декодера на Apple II. К сожалению, они написаны на C, крайне плохо задокументированы и чрезвычайно непонятны (для меня). Сжатие выполняется при помощи кода Хаффмана с переменной длиной (то есть используется битовый сдвиг), а для воссоздания изображения требуется большой объём 16-битных вычислений. Со всем этим 6502 справляется плохо.

Но для начала мне нужно было переписать исходный алгоритм так, чтобы он работал с полосами по 20 пикселей (из-за ограничений памяти). Я написал функциональный декодер, и он работал идеально, но... для декодирования одной фотографии требовалось семьдесят минут.

Этот небольшой этюд служит как бы продолжением статьи "Проценты использования процессора — это ложная метрика". Мы попытаемся копнуть чуть поглубже и более детально разобраться как работает гиперпоточность (или гипертрединг, как его иногда называют).

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

AsmX G3 v29-rev1.0 меняет игру: компилятор, который не только генерирует код, но и пакует его в .deb для Debian/Ubuntu и живёт в AUR с asmx-g3-git, asmx-stable, asmx-official. Проект даёт разработчикам контроль над низкоуровневым кодом и упрощает дистрибуцию приложений. Мощный TAPI и стабильность — всё, чтобы ваш код стал приложением быстрее, чем вы скажете yay -S или paru -S!

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

Вторая часть рассказа об ассемблере под Windows. Здесь я расскажу про 64-разрядные приложения в Windows, чем отличается MASM 64 от MASM 32, про макросы из MASM 64 SDK, как работать с Юникодом на примере простого консольного REPL'а, а ещё как обойтись без Visual Studio и пользоваться masm просто из командной строки.

Первая часть — Assembler для Windows в Visual Studio.

Пишем один код - собираем на разные 8 бит МК!

https://vm5277.ru- это универсальное решение для embedded-разработки, которое позволяет сократить время создания прошивки для 8 бит микроконтроллеров в разы.

Как это работает:

Пишешь код на Java подобном языке (чистое ООП, без головной боли с указателями и не читабельным кодом)

Компилятор автоматически генерирует оптимизированный ассемблерный код под выбранную платформу

Код работает поверх легковесной RTOS, написанной на ассемблере для максимальной производительности

Ассемблер-сборщик финализирует проект в бинарный файл прошивки

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

1. Математика — чистая математика
2. Haskell — язык для функционального программирования
3. C — язык для императивного программирования
4. Ассемблер — сравнительно удобочитаемое представление машинного кода
5. Машинный код для архитектуры x86-64 — вот это уже интересно

Если вам интересно, какие отличия бывают между языковыми стилями или любопытно, как ваш код может выглядеть после компиляции — добро пожаловать под кат!

Что на самом деле происходит, когда вы запускаете программу? Мы привыкли воспринимать это как данность, но за кадром скрывается целая вселенная — от регистров процессора и системных вызовов Linux до формата ELF и модели памяти процесса. Присоединяйтесь к погружению, где мы прольём свет на каждый байт программы «Hello, World!» и поймём, каким образом ОС её выполняет.

Практически сразу, в PC-DOS, вместе с .COM файлами,
появились .EXE файлы (полн. "EXEcutable" или "исполняемые"). Сегодня речь пойдет именно об этом.
Поскольку история происходит снова в Microsoft, запутаться можно очень легко, в любом месте.

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

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

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