Ненормальное программирование *

В 90-х и 2000-х студия Impressions Games выпускала отличные исторические градостроительные симуляторы. Я играл во все игры этой серии от незабываемого Caesar 3, который вообще был первой моей компьютерной игрой на отцовском компуктере, до Императора про древний Китай. Но египетский Pharaoh и греческий Zeus запомнились намного четче, но вот почему я сказать не берусь.

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

Формат "Новых исполняемых" файлов называют сегментным. Даже в официальной документации Microsoft её заголовок это "Сегментный Новый Исполняемый формат" (ориг. "Segmented NEW Executable Format").

Этот сегментный формат программ поддерживал

Сегментную модель памяти;

Защищенный режим Intel 286+

Динамичкую компановку (Dynamic Linking);

Управление ресурсами;

Возможность экспорта и импорта определенных процедур.

Формат "Новых исполняемых" файлов называют сегментным. Даже в официальной документации Microsoft её заголовок это "Сегментный Новый Исполняемый формат" (ориг. "Segmented NEW Executable Format").

Этот сегментный формат программ поддерживал

Сегментную модель памяти;

Защищенный режим Intel 286+

Динамичкую компановку (Dynamic Linking);

Управление ресурсами;

Возможность экспорта и импорта определенных процедур.

В 1980х в США активно развивалось увлечение садовыми железными дорогами. Поезда работали на электричестве вместо пара, были доступны аккумуляторы, появилась компактная электроника, чтобы можно было «прикрутить» радиоуправление. И многие любители делали не только модели настоящего подвижного состава, но и ставили на рельсы игрушки марки Stomper.

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

Как следует отображать на экране результат деления 3.0 на 10.0 ? Сколько цифр следует вывести, если пользователь не указал точность?

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

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

Это вторая статья из цикла «Санпросвет о плавающей точке»:

1. Компьютеры и числа

2. Вывод чисел с плавающей точкой на экран <- вы тут

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

Оказалось, что форумы кишат людьми, которые не до конца понимают, как компьютеры манипулируют числами. Например, мемасик с КПДВ я стянул с реддита (перечеркнул его я). Кто-то настолько был напуган страшными ошибками округления чисел с плавающей точкой, что даже смешную картинку смастерил. Только вот проблема в том, что 0.5 + 0.5 в точности равно 1.0.

Таким образом, я решил засучить рукава, и изобрести велосипед. То есть, написать самую неоптимизированную C++ библиотеку для эмуляции IEEE754 32-битных чисел с плавающей точкой при помощи исключительно 32-битной целочисленной арифметики. Библиотека уложится в несколько сотен строк кода, и в ней не будет никакого битхакинга. Задача написать понятный код, а не быстрый. А заодно хорошенько его документировать серией статей.

Итак, этим полукреслом мастер Гамбс начинает новую партию мебели, или статья первая: поговорим о числах и компьютерах.

Хочу поделиться своим опытом разработки крупных игровых проектов на C++, где производительность и стабильность — это не просто приятные бонусы, а абсолютно естественные требования к разработке. За годы работы над движками и играми я понял, что подход к управлению памятью очень сильно влияет на весь проект. В отличие от многих приложений - игры, особенно большие, часто работают часами без прерываний и должны поддерживать стабильный фреймрейт и отзывчивость. Когда проседание fps или фриз происходит на глазах у сотен тысяч игроков, вам уже никто не поможет — ущерб уже нанесен, а в steam полетели отзывы о кривизне рук разработчиков.

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

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

Хотел написать классическую статью, ни разу не писал, ради интереса попросил ChatGPT и она все написала, стало скучно до жути, эта «классическая » статья будет под спойлером, она реально по теме, написана с двух запросов, а далее будет кратенько и технически что и зачем, со ссылками на примеры. Для технической части нужны знания python, llm, cuda и что такое OpenAI API.

Что действительно делает программу великой? Скорость работы, поражающая воображение? Лаконичность и изящество кода, восхищающие коллег? Или, быть может, Архитектура, обещающая вечную гибкость? Тысячи лет все эти империи рушились перед лицом коварной Ошибки. Пришло время провозгласить манифест иной истины: высшая ценность программы — её Достоверность, и цель разработки — доказать, что программа безупречно воплощает замысел своего создателя. В данной статье мы рассмотрим инструменты и методы, которые превращают намерение программиста в неопровержимую теорему. Через формальную верификацию тривиального, но коварного ФиззБазза средствами Idris 2 мы покажем, как строить программы, чья правильность не вера, но математический факт. Зависимые типы — наш меч. Добро пожаловать в мир, где код не просто работает — он доказан.

Надоело каждый раз подставлять TOTP на сайтах и у вас есть yubikey? Тогда добро пожаловать под кат. Поделюсь самописным расширением, которое позволяет автоматизировать эту рутину.

Недавно я набрёл на шедевр Патрика — клон DOOM, основанный на DuckDB-WASM и работающий в браузере. Прочитав о нём, я решил  довести  эту великолепную идею до логического завершения: написать многопользовательский DOOM-подобный шутер целиком на SQL. При этом всю тяжёлую работу хотел сделать через базу данных CedarDB. Отлучившись с работы в месячный отпуск по уходу за ребёнком (бессонных ночей хватало), я попытался сделать именно это.

Вот вам тизер DOOMQL:

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

Азазель предложил идею, которая кажется логичной и полезной:

Привет, меня зовут Саша и я Android-разработчик :)

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

Часто источниками данных являются: человек, сервер и устройство (User, Server, Platform).

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

Подобно тому как вызовы функций вкладываются друг в друга:

Снова показываю как можно вести разработку «голыми руками» — без IDE, документации и даже интернета. На этот раз с помощью «пользовательской» Ubuntu Linux и OpenJDK.

В процессе разработки некоторого количества достаточно сложных текстовых квестов, пришло понимание связанных с этим сложностей. Работа в графическом редакторе увлекательна, но крайне неудобна, по целому ряду причин. В ответ на эти проблемы, родилась идея текстового языка разметки, а уже в процессе его разработки появилась возможность сделать кое что неожиданное. Мне требовался вычислительный блок, для выполнения нетривиальных вычислений и система команд МК-61 показалась неплохим выбором. Ну а чтобы убедиться что всё работает, пришлось воссоздать “Лунолёт”. Внутри текстового квеста…

Язык программирования, даже общего назначения, - это инструмент. Каждый язык хорош в решении задач своей сферы: C++ позволяет писать эффективные программы, Haskell - писать элегантный параллельный и математический код, C# - создавать программы на гибкой масштабируемой архитектуре. Современные языки заставляют нас мириться с их недостатками: отсутствие нужной системы типов, нехватка синтаксического сахара, отсутствие парадигмы X. Все хоть раз мечтали о языке, который удобен для решения любой задачи.

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

Привет, Хабр !

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

В данной статье будет представлен пример контроля напряжения, над блоком питания - внутри которого (никель-металлгидридная аккумуляторная сборка NiMH 14.4В/12 банок по 1.2В(1.4В- при полной зарядке)), с помощью микроконтроллера STM32.

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

• Работа с кнопкой;

• Работа со светодиодом;

• Работа с пъезоэлектрическим излучателем(звуковая индикация);

• Контроль заряда/разряда аккумулятора(дает звуковой сигнал при напряжении менее 9 вольт и более 14).

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

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

Как повернуть время вспять и выиграть Assembly с DOS-демкой в 2025-м году.
Разбираем олдскульные эффекты на примере демки "Demoded".

Секреты, хитрости и откровенное жульничество российского демомэйкинга.
История в картинках.

В игре CoreWars участники писали программы, которые сами клонировались в памяти и пытались затереть друг друга. Работало это в виртуальной машине с хитроумными инструкциями, которые позволяли создавать очень короткий код. Простейшая само-копирующаяся программа, "самобеглый MOV", выглядела вот так:

MOV 0, 1

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

Мне неизвестны реальные процессоры в которых были бы подобные "удобные" инструкции. И вот любопытно - насколько короткой можно сделать (а можно ли?) подобную "самобеглую" программу для какой-нибудь настоящей архитектуры. Ну хотя бы для 8086. Тем более что там сегменты обозримого размера - 64 килобайта.

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