Assembler *

Разработка виртуальных машин может быть не только интересным занятием на вечер, но также и полезным приложением при обучении студентов языку ассемблера на предметах ОАиП (основы алгоритмизации и программирования) и ААС (архитектура аппаратных средств). Целью данной статьи станет создание простой стековой виртуальной машины с собственным языком ассемблера, способным выполнять операции условного и безусловного переходов, инкрементирования и декрементирования чисел, загрузки и выгрузки значений в стек. Машина получится минималистичной и будет обладать лишь 10-ью инструкциями, на основе которых можно будет далее вполне корректно создать собственный высокоуровневый язык программирования.

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

Ассемблерные вставки, используемые компиляторами GCC и Clang, опосредуют взаимодействие высокоуровневых и низкоуровневых языков программирования. Это тонкая и коварная штука. Многие попадают в расставленные здесь капканы, зачастую совершенно неожиданно для себя. В сущности, ключевое слово asm можно перевести на C и C++ как unsafe. Почти в любых руководствах по встроенному ассемблеру, в том числе, и на ужасной странице ibilio, которая десятилетиями попадает в самый верх поисковой выдачи, неисправимо фигурируют фундаментальные серьёзные ошибки, а примеры в большинстве своём некорректны. Наиболее опасно, что эти примеры обычно приводят к ожидаемым результатам! Ситуация плачевная. Эта статья — не руководство, а подборка элементарных правил, которые помогут вам избежать самых распространённых ошибок либо отловить их при ревью кода.

Здесь мы сосредоточимся сугубо на расширенном, а не на базовом ассемблере, а правила в этих версиях отличаются. На первом пишут любые инструкции, относящиеся к встроенному ассемблеру, с ограничениями или затираемыми. То есть, имеем токен : в обрамлении asm. Базовый ассемблер — тупой инструмент, который используется сравнительно нечасто, в основном в самом верху файла с кодом или в “голых” функциях. Поэтому злоупотребления базовым ассемблером на практике маловероятны.

Нашего клиента донимали отчёты о вылетах, показывавшие, что его программа ломается на самой первой команде.

Я открыл один из дампов вылета, он оказался настолько странным, что отладчик даже не мог понять, что пошло не так.

Почему я это написал, и как читать статью

Недавно получил от друга такое сообщение:

Знаешь, какая статья была бы реально интересна? Если бы в ней было показано, что именно происходит с твоим кодом в результате оптимизаций.

Я сразу же подумал: «Ну конечно, я знаю тысячу статей и видеороликов на эту тему», но вскоре осознал, что практически во всех таких источниках от читателя требуется знать компьютерный жаргон, внутреннее устройство, промежуточные представления, т.д. Вот какая проблема здесь возникает: те, кто пользуется компиляторами (как, например, мой друг), всем этим не заморачиваются. Их не волнует, каково именно промежуточное представление LLVM, или что такое φ-узел, или какой проход и почему называется «ротацией циклов». Нет, их интересуют (в порядке убывания приоритета) ответы на вопросы: (1) что, (2) почему, (3) как.

Продолжаем цикла статей по работе с расширенным экраном компьютера "Profi". Второй практикум.

В предыдущих статьях была описана структура расширенного экрана компьютера "Profi", работа с файлами в OS CP/M, а так же загрузка и вывод картинки из файла на экран. Теперь давайте рассмотрим методы работы с расширенным экраном и попробуем проскроллировать его.

Статья была опубликована в 2023 году в 44 номере журнала по "Downgrade".

Статья написана в соавторстве с Вадимом Чертковым.

Уважаемые дамы и господа, сегодня я представлю вам еще одно решение одного из челленджей с соревнования по кибербезопасности 1337UP LIVE CTF 2024. Данное задание кардинально отличается от того, что я описывал в предыдущей статье. Сложность в этом случае довольно таки высокая. Но не будем откладывать дела на потом. Идем на страницу с челленджем и приступаем.

Всё вроде должно быть просто

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

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

А задумывались ли Вы, что можно сделать на ЭВМ «Берёста-4» с объемом памяти ПЗУ 256 байт? Многие из Вас скажут, что можно всего лишь поморгать светодиодом, а я скажу Вам, что можно сделать ЧПУ станок.

Недавно я закончил создание пасьянса для Nintendo E-Reader. Мне удалось уместить его на одной карте, и это практически полнофункциональная версия игры. Я очень доволен тем, что получилось.

Что такое E-Reader?

E-Reader — это периферийное устройство для Game Boy Advance, выпущенное компанией Nintendo в 2002 году. Сканируя карты, где есть полоска с кодом из точек, можно загружать мини-игры, дополнительные уровни, анимации и так далее.

Друзья, сегодня я представляю вашему вниманию решение одного из челленджей, который был представлен на 1337UP LIVE. Решение далось довольно легко, но я все же считаю, что это достойно хабровской публикации. Что же, давайте не тянуть яйца за кота и посмотрим, с чем мы имеем дело.

Ещё статья про ассемблер для тех кто с ним не знаком. В предыдущей про 5 ассемблеров последний примерчик вызвал критику за "упрощенизм". А давайте посмотрим вместе как его улучшить и немножко нарастить - в качестве "продолжения знакомства".

Заодно полюбуемся на несовместимость Linux и BSD, а также на различие 32 и 64-битной версии обеих ОС - и подумаем как с этим бороться.

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

Встретил на Хабре очередную статью об написании «простой операционной системы с нуля» и решил поделится своими потугами на эту тему.

Немного предыстории

В далеком уже 2011 мне в руки каким‑то чудом попала книга «Ассемблер. Экспресс курс» за авторством Александра Панова. После Паскаля,изучаемого в школе, ассемблер показался мне языком неограниченных возможностей. После того как я вдоволь наигрался со всякими огоньками и прочими бегущими символами мне захотелось создать что‑то крутое. А что может быть круче чем собственная ОС? Так в 2012.

Патрик спустя минуту вернулся с небольшой пыльной коробкой в руках. Мы с Дейвом смотрели, как Патрик ее открывает и достает сетевой свитч — такой староватый из тех времен, когда им еще делали железные корпуса. Он воткнул блок питания в розетку и аккуратно выпрямил шнур CAT-5, чтобы подключить этот свитч к нашей сети. Хотелось наорать на него за всю излишнюю осторожность в такой момент. А Дейв сидел рядом со мной, нехарактерно тихо.

Пока у Патрика не получалось попасть шнуром в нужный порт, я замер, глядя на передние огоньки — Дейв, наверное, тоже. Глаза намокли. Патрик наконец впихнул шнур. Сразу же свитч загорелся — огоньки быстро замигали. Я почувствовал, как мое лицо и руки покраснели, а краем глаза увидел, как Дейв встал и открыл рот, будто пытаясь что-то сказать. Затем он нырнул лицом в сложенные руки — затем его вырвало.

В статье мы познакомимся с языком ассемблера для Apple Silicon (ARM64). Рассмотрим основные регистры, запись данных из регистров в память и обратно. Затронем также и базовые навыки работы с LLDB.

Совершать невозможное и раздавать пинки здравому смыслу — в этом и состоит жизнь членов Гуррен-Дана! (C) Камина

Эта статья вступает в техническую полемику со статьей 2015 года за авторством Atakua, подходы из которой я и атакую. Atakua исследует 7 видов интерпретаторов байткода, но делает это без уважения - быстрейшей оказывается двоичная трансляция, которая, по сути, уже не интерпретатор байткода, а форма Ahead-Of-Time компилятора. Эта двоичная трансляция транслирует байткод в машинный код, представляющий собой цепочку вызовов скомпилированных сервисных процедур. Тех самых, что в интерпретаторе байткода отвечают за выполнение каждого опкода.

Но Atakua не выжал из интерпретаторов байткода всю скорость которая возможна. Так что эта статья - туториал: как написать интерпретатор байткода, который может обгонять JIT/AOT-компиляцию по скорости. Интересно? Читайте дальше!

Бенчмарк прилагается. Будет немного хардкора и ни одной сгенерированной нейросетью картинки!

Оказалось, что тема суммирования целых чисел в кодировке ASCII в Haswell со скоростью memcpy гораздо популярнее, чем я мог ожидать. Именно поэтому я решил поучаствовать и в другом челлендже в жанре HighLoad: подсчёт uint8. В настоящее время я занимаю всего лишь 13 место в списке лидеров, проигрываю первому месту около 7%, но уже узнал немало интересного. В этом посте я полностью опишу моё решение, в том числе, удивительный паттерн считывания из памяти. Используя его, можно примерно до 30% (по сравнению с обычным последовательным доступом) повысить скорость передачи в контексте одноядерных рабочих нагрузок, ограниченных размером кэша. По-видимому, этот метод малоизвестен.

Как и в других постах автора, программа настроена для следующих входных характеристик высоконагруженной системы: Intel Xeon E3-1271 v3 @ 3,60 ГГц, ОЗУ 512 МБ, Ubuntu 20.04. В ней используется только AVX2, а AVX512 не используется.

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

Статья для тех кто не знаком с ассемблерами - но хочет взглянуть "одним глазком". Мы не сделаем вас гуру разработки на ассемблере за 15 минут - но покажем ассемблеры для нескольких популярных архитектур микроконтроллеров (ARM32, AVR, MSP430, 8051) - и для настольных наших компьютеров (x86 под Linux и DOS) - чтобы увидеть их различия и сходства - и не бояться погрузиться глубже, если что-то из этого может быть вам полезно.

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

Бонусом - для любопытных - ассемблер для Intel-4004 - 4-разрядного процессора которому уже больше 50 лет. К нему будет также небольшой "интерактивчик".

На выходных я наткнулся на статью от комментатора, в которой был представлен  Обзор языка программирования AsmX. После прочтения этой статьи я решил поискать в Telegram диалоги создателя языка, к которым мы вернемся позже. Цитирую список пунктов от обзорщика Василия, с которыми я полностью согласен: