← Шестая часть

В предыдущем посте мы спроектировали CPU. Я определился с набором команд, написал ассемблер, проверил каждый опкод и создал процессор, работающий в кремнии (или, точнее, в FPGA Altera Cyclone II EP2C5T144C8, что тоже довольно близко). Но у нас пока нет осмысленного ПО (микрокода калькулятора) для запуска на «железе».

В этой части проекта оправдали себя все эксперименты с прототипами на C++, описанные в частях 2 и 3.

Когда я начал писать addsub.asm (самую первую команду, которую я портировал), то не смотрел на пустую страницу, задаваясь вопросом, как работает BCD-сложение. У меня уже имелась эталонная реализация на C++ (addsub.cpp в проекте Proto), верифицированная на тысячах тестовых векторов. Алгоритм был известен, пограничные случаи найдены и охарактеризованы. Я проработал поведение защитного разряда и бита фиксации. Оставалось лишь транслировать это всё на язык ассемблера; задача всё равно сложная, но совершенно иного уровня сложности, нежели изобретение алгоритма в процессе его написания.

Я хотел бы сделать упор на этот двухэтапный процесс, потому что может показаться, что без него можно обойтись. Написание кода прототипа на C++ с последующей ручной трансляцией на язык ассемблера кажется избыточной и долгой работой. Однако она перестанет казаться избыточной к моменту, когда вы будете отлаживать неочевидный пограничный случай округления в 16-ниббловом BCD-вычитании. Наличие золотого эталона, с которым можно выполнять сравнения, не избыточно: это единственное, что стоит между вами и неделями кропотливого труда или даже провалом проекта.

Рассказав недавно историю про «Парк юрского периода», я захотел пересмотреть этот фильм снова. Наверно, я уже видел его раз десять. На этот раз я решил изучить все компьютеры и ПО из этого фильма.

Цифровая идентификация и её значение для веба в последние годы стали темой горячих обсуждений. Они привнесли с собой множество спорных моментов: законы о проверке возраста и их влияние на онлайн-анонимность; Википедия потенциально будет вынуждена верифицировать в Великобритании личность пользователей; привязка к официальным операционным системам iOS и Android стала обязательным форм-фактором для кошельков цифровой идентификации; кроме того, стоит упомянуть ситуацию, когда американские цифровые аккаунты были закрыты потому, что их пользователь был судьёй Международного уголовного суда.

В своей истории я расскажу о швейцарской правительственной системе идентификации AGOV. Этот развёрнутый в 2024 году сервис сегодня насчитывает 1,6 миллиона аккаунтов и становится всё более необходимым: через него можно получать пособие по безработице, предоставлять налоговую декларацию (а это обязательное действие!) и выполнять множество других операций. В кантоне Цюрих это единственная возможность подачи заявления на гражданство.

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

90-е стали десятилетием существенного прогресса в мире видеоигровых консолей^[1]. Каждая новая модель привносила повышение вычислительных мощностей и улучшение графики.

Однако выпадающим из общей картины фактом стало появление в середине 90-х приводов CD-ROM. Хотя диск на 640 МиБ был в 320 раз больше объёма картриджей^[2], скорость доступа (800 мс^[3]) и пропускная способность (150 КиБ/с в случае односкоростных приводов) были, соответственно в 4 миллиона раз и в 35 раз ниже.

Mega-CD стала проектом компании Sega по добавлению CD-ROM к её консоли Genesis. Для этой платформы выпустили почти двести^[4] игр. Среди них были и потрясающие Sonic CD, Snatcher, Final Fight CD, а также несколько RPG. Однако бесконечный конвейер игр, в которых активно использовалось Full Motion Video (FMV) (Night Trap, Prize Fighter, Slam City, Corpse Killer, Supreme Warrior, WireHead и A/X-101), создал плохую репутацию этой приставке Sega .

Среди этого мусора появилась Silpheed. Превосходный художественный вкус наряду с движком, способным выдавать великолепные анимации, свели прессу с ума^[5][6]. Игроки гадали, было ли это 3D в реальном времени или же всё вычислялось заранее^[7]. Игра заслужила похвалы, которой она достойна и сегодня^[8][9].

В июле 2023 года 25-летний мужчина по имени Джагдиш Уиттен из Сан-Франциско вышел на пробежку. Когда он перебегал оживлённую дорогу, его сбила машина; по его словам, он сделал «лёгкий кувырок» над автомобилем, приземлился на проезжую часть, после чего ползком добрался до обочины. Свидетели происшествия вызвали для него скорую помощь. Однако Уиттен отказался от помощи и позвонил другу, который сам отвёз его в ближайшую больницу: «я знал, что скорые дорогие, и понимал, что не умру».

По обоим пунктам Уиттен был прав. В больнице врачи определили, что у него небольшое сотрясение, сломан палец на ноге и есть несколько ушибов, то есть ничего особо серьёзного. Но из-за того, что он был травмирован, врачи обязаны были отправить его в Центральную поликлинику Сан-Франциско, в котором расположен единственный травматологический центр города. На этот раз у него не было выбора. Его погрузили в скорую и отвезли за десять километров в поликлинику, где оценили состояние, не потребовавшее вмешательства, и в тот же вечер отправили домой.

Через несколько недель Уиттен получил счета от обеих больниц. Всё было приблизительно так, как он и ожидал, и все расходы покрывались его страховкой. Но спустя несколько месяцев Уиттен получил ещё один счёт, на этот раз от American Medical Response — поставщика услуг скорой помощи, перевозившей его между больницами. Из счёта он узнал, что поездка на скорой будет стоить ему $12873: $737 за пройденный километраж, $314 за мониторинг его сердца в поездке, $151 за инфекционный контроль и $11670 «базовой ставки».

Уиттен перенаправил счёт своей страховой, которая сначала отказала ему в возмещении затрат, мотивируя это тем, что услуги AMR ею не покрываются и что перевозка не была одобрена заранее. (Разумеется, Уиттен не выбирал скорую и остальные тонкости поездки.) После подачи апелляции страховая компания согласилась покрыть $9967 от запрошенной суммы, но мужчине всё равно оставалось погасить самостоятельно примерно $3000. После множества неудачных попыток опротестовать счёт в AMR, не желая, чтобы коллекторы снизили его кредитный рейтинг, он выплатил примерно $2900. Короткая поездка на скорой из одной больницы в другую стоила ему гораздо больше, чем все остальные части процесса лечения.

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

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

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

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

Это само по себе печально, но я бы хотел поговорить кое о чём ещё более прискорбном: назовём это теорией мёртвой экономики.

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

Я не любитель кликбейтных заголовков, но понимаю, почему редакторам они так нравятся. Заголовок статьи, строго говоря, совершенно правдив, но, наверно, не в том смысле, в котором вы бы ожидали. Обфусцированный код на самом деле оказался пасхалкой, он распространяется в магазинах Uniqlo в рамках кампании Peace for All на замечательных футболках, дизайн которых разработала Akamai.

Сэнди Петерсен, геймдизайнер и дизайнер уровней Doom и Quake:

«В связи с 30-летней годовщиной выпуска сейчас многие с теплотой вспоминают Quake, и это вполне оправдано. Quake — потрясающий проект, сочетающий в себе искусство, программирование и дизайн. Я работал над ним, и все мы выложились почти идеально. Мы создали безумный экшен с большой долей свободы, захватывающий воображение игроков. Вся команда проделала замечательную работу и качественно выполнила все задачи. Но расплата за это была печальной: мы трудились долго и упорно, и мне кажется, эта игра сломала нас морально...»

← Четвёртая и пятая части

Это самый длинный пост всей серии, потому что он посвящён главной части этого проекта — всё вращается вокруг CPU.

Почему бы просто не взять готовый CPU?

Кто-то может заявить: зачем заморачиваться проектированием собственного CPU? Есть куча маленьких хорошо задокументированных процессоров и дешёвых микроконтроллеров, способных исполнять прошивку калькулятора. Zilog Z80 не так сложно реализовать на FPGA, и я в этом уже убедился (проект A-Z80, находящийся у меня на GitHub). Подойдёт и 6502. Маленький встраиваемый RISC тоже прекрасно справится с этой работой.

Отвечу честно: это было бы не так интересно, потому что подобное уже много раз делали. Но есть и другие (более удобные для меня) причины.

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

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

Наш сетевой драйвер терял пакеты. Не время от времени, а постоянно. На пропускной способности линии с 64-байтными пакетами мы теряли 31% всего трафика.

В качестве оборудования использовался Ethernet-контроллер на 1 Гбит/с на SoC RISC-V. В спецификациях говорилось, что он может справляться со скоростью проводного трафика. Движок DMA работал корректно. Обработчик прерываний срабатывал вовремя. Тем не менее, пакеты исчезали.

Я начал с очевидного подозреваемого: очереди получения. Реализация выглядела вполне логично — простой связанный список с указателями на голову и хвост. Под нагрузкой (64-байтные пакеты на пропускной способности линии) драйвер терял 31% пакетов! При профилировании обнаружилась причина проблемы: производительность убивали связанный список и спин-блокировки.

Я переписал драйвер, использовав кольцевой буфер без блокировок. Результаты: потеря 31% пакетов превратилась в 0,12% — улучшение в 258 раз!

В этой главе мы поговорим о структуре очередей для драйверов устройств.

Наш загрузчик оказался слишком медленным. Требование было чётким: загружаться менее чем за 500 миллисекунд. Показатели оставались не менее чёткими: 720 миллисекунд. Мы отставали от нужного значения на 44%.

Это требование не было «мягким». Загрузчик должен был работать в промышленном контроллере, обязанном реагировать вскоре после включения питания. Каждая секунда времени загрузки — это потерянная продуктивность. В спецификации к изделию был указан максимум в 500 мс. Мы обязаны были их обеспечить.

Задача загрузчика была простой:

1. Инициализировать оборудование (UART, SPI, DDR-контроллер)

2. Загрузить ядро из флэш-памяти

3. Спарсить дерево устройств

4. Перейти ко точке входа ядра

Реализация казалась логичной: стандартные структуры данных из библиотеки C. Проблема выявилась при профилировании: 45% времени загрузки тратилось на malloc/free! В загрузчике всего с 64 КБ ОЗУ динамическое распределение роняло производительность.

Наш веб-краулер потреблял 128 МБ ОЗУ только на отслеживание посещённых URL. На встраиваемом устройстве с 256 МБ это была половина всей памяти.

Задача краулера была простой: отслеживать посещённые URL, чтобы не краулить одну и ту же страницу дважды. После обработки 1 миллиона URL (средняя длина 80 байт) хэш-таблица, в которой хранились эти URL, разрослась до 96 МБ плюс оверхед.

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

Этот вопрос изменил всё. На самом деле, идеальная точность не требуется. Если мы случайно обработаем одну страницу дважды, то впустую потратим часть пропускной способности, но ничего не поломаем. Главным ограничением была память.

В 1994 году у меня появился первый компьютер: Intel i486 DX2-66 с 4 МБ ОЗУ и жёстким диском на 512 МБ. На нём были установлены IBM OS/2 и Microsoft Windows 3.11. Следующие четыре года я апгрейдил эту машину каждые несколько месяцев, добавляя больше ОЗУ (до 16 МБ), привод CD-ROM и карту SoundBlaster. Так я научился апгрейдить эту машину, устанавливать новое ПО, а потом и писать ПО на BASIC. Но я ни разу не касался процесса запуска и тонкостей MS-DOS.

В 2026 году, 32 года спустя, я узнал из скриншотов DDX3216, что в Behringer использовался настоящий процессор 386. В моём мозгу сразу же активировались какие-то нейроны и я начал размышлять о том, можно ли запускать на этом устройстве ПО или даже полнофункциональную операционную систему. Для этого мне нужно было разобраться, как запускается система x86, когда управление перехватывает DOS и что необходимо для попадания в оболочку.

Я приступил к основанию своей второй компании в Германии в конце января. Сейчас конец июня.

За это время государство, два суда, нотариус, юридическая фирма, налоговая фирма и производители ПО нашли способ взять с меня деньги. Каждому из них это удалось вовремя.

Для создания компании я потратил более 9600 евро: чуть больше 7600 на сборы и счета плюс 2000 евро уставного капитала заморожено на счету, трогать который я не имею права. И спустя пять месяцев я могу сказать о компании только одно:

У меня так и не появилось возможности отправить собственный счёт на оплату клиенту.

Работа ведётся. Клиенты реальны. Единственное, для чего нужно государство — позволять мне без проблем брать с них оплату — это единственное, что мне по-прежнему недоступно.

Не так давно я читал о протоколе Wayland и мне врезалась в память эта фраза:

Заявленная цель Wayland — «каждый кадр идеален».

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

Эмпирическое правило таково:

Если сделать скриншот приложения в любой момент времени, должно быть понятно, что на нём происходит

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

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

В течение двух десятков лет в компании Meta* существовал уникальный высокопроизводительный отдел разработки; всё закончилось в апреле этого года. На протяжении первых двух десятков лет работы компании в ней исповедовалась культура «двигайся быстро и ломай ненужное», в начале 2020-х сменившаяся на «двигайся быстро со стабильной инфраструктурой». Знакомые мне разработчики из этой компании говорили мне, что им представляли всё необходимое для качественной работы с упором на приносимую пользу, а интересы бизнеса находили баланс с надёжной разработкой.

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

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

В 1935 году Эрвин Шрёдингер решил, что с него хватит.

За десять лет до этого смелый венский физик своим «волновым уравнением» преобразовал новую теорию квантовой механики, описав в нём то, как квантовые частицы способны вести себя подобно волнам. После этого он стал свидетелем того, как некоторые исследователи выдумывали то, что он считал смехотворной интерпретацией квантовой теории, отрицавшей реальность таких квантовых объектов, как атомы и субатомные частицы, до наблюдения за ними.

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

Приведя пример квантового поведения, влияющего на объекты, которые мы можем увидеть (и даже погладить), Шрёдингер хотел показать абсурдность того, что наблюдения способны определять реальность.

Почти сотню лет его мысленный эксперимент порождал споры о том, что же именно подразумевается под измерением или наблюдением в квантовой теории. Это бросило вызов экспериментальной физике: насколько большими мы можем делать объекты, сохраняющие любопытные квантовые свойства (не находящиеся ни в том, ни в другом состоянии)? Можно ли создать если не для кота, то хотя бы для существенного объёма неживой материи (который некоторый называют котятами Шрёдингера) такие странные квантовые «суперпозиции»?

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

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

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

Система довольно проста: моя домашняя машина с Debian. У меня работает Postgres 17 в Docker с shared_buffers = 16MB, track_io_timing = on. В качестве накопителя используется локальный SSD NVMe с ext4. Я намеренно создал таблицу такого размера, чтобы она не умещалась в кэш.

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

Мы рассмотрим множество пограничных случаев, споткнёмся об маленькие препятствия и обнаружим, что некоторые технически корректные детали не всегда поддерживаются даже в больших системах наподобие Gmail (и, честно говоря, на то есть веские причины).

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

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

Nintendo DSi

В большинстве случаев браузер был включён в пакет системного ПО DSi (2008 год), в противном случае его можно было бесплатно установить из DSi Shop. Для браузера не требовался Memory Expansion Pak благодаря тому, что в DSi имела встроенные 16 МБ ОЗУ. Браузер сильно улучшили по сравнению с версией для DS, это урезанная версия Opera 9.50¹.

Важным аспектом стало добавление поддержки HTML canvas: на различных сайтах наподобие DSiPaint, DSiCade, DSiPlaza и Social Neko, написанных специально под браузер DSi, использовалась эта поддержка и другие веб-технологии, упрощающие интерактивные действия. Браузер поддерживал только один шрифт и три его размера, а контент преобразовывался в соответствии с этим ограничением.

Авторы обзоров того времени критиковали отсутствие поддержки Adobe Flash и воспроизведения видео, а также достаточно частые сообщения о заканчивающейся памяти, но всё равно считали браузер серьёзным шагом вперёд по сравнению с ПО для DS. Он получил единственное обновление до версии 1.4 (август 2009 года), которое немного уменьшило занимаемый в памяти размер.

Несмотря на увеличившийся размер ОЗУ, DSi не была совместима с браузером DS из-за обязательной проверки на наличие Memory Expansion Pak, который невозможно было установить DSi из-за отсутствия Slot-2.

^{1. Несмотря на некоторые утверждения, браузер работал в самой DSi, не используя прокси рендеринга Opera Mini.}