Assembler *

Эта статья является частью серии «Начальная загрузка» , в которой я начинаю с 512-байтного начального источника и пытаюсь загрузить реальную систему.

Эта статья является частью серии «Начальная загрузка» , в которой я начинаю с 512-байтного начального источника и пытаюсь загрузить реальную систему.

Многие оптимизации в компиляторе выглядят естественными. Но IndVarSimplification, предмет этой статьи, сильно выделяется среди них. Это та оптимизация, которая сначала кажется темной магией, но за маской на самом деле скрывается математика.

В этой статье я постарался разобраться, как работает IndVarSimplification. Будет немного кода на Rust, чтение ассемблера и копание в коде LLVM.

Демогруппы CRTC и Hornet, выпустившие нашумевшее в 2015 году демо 8088 MPH (публикация на Хабре), меняющее представление о возможностях PC XT и CGA, собрались с силами и выпустили своё свежайшее творение на ту же тему - Area 5150. Оно выставлялось на демопати Evoke 2022 и заняло там первое место в категории демо для альтернативных платформ (куда свалено в кучу всё, что не современный PC), обойдя даже весьма креативную работу 420 Years Of Teletext.

Как обычно пишут сервер, если не особо заботиться производительности? Программа запускается, затем начинает принимать входящие соединения от клиентов и для каждого клиента запускает новый поток, который занимается обслуживанием этого клиента. Если вы используете какой-нибудь, прости господи, Spring или Flask или там Poco, то он что-такое внутри себя и делает - разве что потоки можно переиспользовать, то есть брать из некого пула. Это всё довольно удобно, но не слишком эффективно. Скорее всего, ваши потоки, обслуживающие клиентов, живут недолго и большую часть времени ожидают либо получения данных от клиента, либо отправки их клиенту - то есть ждут возвращения системных вызовов. Создание потока ОС - довольно дорогая операция, как и переключение контекста между потоками ОС. Если вы хотите уметь обслуживать много клиентов эффективно, надо придумать что-то другое. Например, коллбеки. Но это довольно неудобно.

Исследование возможностей оптимизации ПО на примере хеш-таблицы.

Цель настоящей статьи - изучить лямбда функции: чем они отличаются от обычных функций и изучить, как они реализованы в С++, Python 3 и Java.

На протяжении этой статьи я буду использовать godbolt.org, чтобы компилировать код и изучать машинный код или байт код. Я думаю, что при чтении статьи может быть удобнее смотреть не на приведённый машинный код в статье, а на этом сайте.

Вот уже 10 лет прошло, как я переводил свои средства программирования в среду x86-64 для Windows 7. А как будто вчера было! Поскольку тогда многие особенности этой среды были для меня внове, они вызывали недоумение. Вот типичный пример.

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

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

Мне понадобился простой программируемый таймер, он же реле времени. Простая штуковина, которая в указанное время замыкает контакты. Одним словом, ничего сложного.

Вот только с началом санкций даже такое простое лабораторное оборудование купить стало невозможно. Вот хороший пример: http://www.optimum-lab.ru/product/tajmer-laboratornyj/. Отличное лабораторное устройство, но как почти прямо пишет продавец - купить его сейчас не так и просто. Другой случай: https://www.chipdip.ru/product/at8n-24-240v-ac-dc. Не такая удобная и привлекательная разработка как предыдущий вариант, зато в наличии. Но стоит почему-то непотребно много, когда для такой задачи достаточно обычного реле и таймера. А этот вариант: https://www.chipdip.ru/product0/8002563209 совмещает нездоровую цену и нездоровые сроки поставки.

Какой компьютер без демосцены? Обратимся к классике от @Manwe_SandS@frog:

До моего визита на Assembly'99 я каждый pаз удивлялся pезультатам голосования на заpубежных demo party. Мне было непонятно, как столько людей могут отдавать голоса за pаботы состоящие из тупой (я пpошу пpощения, но это именно так) последовательности эффектов - плазмы, туннеля, огня, вpащающегося куба (тоpа) и пpочих подобных вещей, не объединенных никаким сюжетом, не несущими никакой идеи.

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

Скомпилированное приложение является «чёрным ящиком». Чтобы туда заглянуть, восстановить алгоритм работы применяется реверс‑инжиниринг. Это непростой навык с высоким порогом входа. В статье мы попробуем взять дизассемблер, несложную задачку и пойдём в бой. Материал будет полезен тем, кому хочется с чего-то начать и погрузиться в тему реверса.

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

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

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

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

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

История о том, как я свой язык начал создавать.

Некоторое время я был занят написанием простенького редактора для языка ассемблер под ARM Cortex семейства микроконтроллеров (подробности в моих статьях), и вот сейчас, поднакопив некоторый опыт как в части самого ассемблера так и способов написания программ в них решился на написание нового редактора.

Плюс еще подоспел интерес к RISC‑V архитектуре и было принято решением делать редактор который смог бы редактировать программы на ассемблере для различных архитектур (в том числе может быть и с лагеря AVR кто нить захочет присоединиться).

В общем подумалось: а что если попытаться создать asm‑base'д язык программирования который при выборе архитектуры просто бы транслировался автоматически в асм инструкции выбранной платформы?

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

Игры не использующие мапперы в NES ограничены, 16 кб PRG ROM (хранилище программного кода) и 8 кб CHR ROM (хранилище графики). С развитием разработки игр на NES, встал вопрос, а как увеличить данные ограничения и на помощь пришли микросхемы мапперы. Что же такое мапперы мы и разберем сегодня и как их использовать в своем коде.