Фотали кого из вас в детстве во время игры? Или может быть были фото с подаренной на новый год сегой? Я вот заехал на днях к маме, покопался в фотоальбомах и нашел несколько таких фотографий.
Раньше с пленочными фотками все подряд не фотографировали, кадры денег стоили, поэтому никаких ваших дурацких игрушек в кадре. Только по стойке смирно стоять на фоне красивого фона.
Это самое старое фото, где я играю, год 1999 примерно. Сижу за вторым пеньком. Кто угадает игру?!
Тут уже новогодняя ночь, наверное, 2002-2003. Я играю в PS2, скорее всего Tekken 4 или GTA 3.
Здесь я уже постарше, приблизительно 2004 год, так же играю в PS2, но уже с другим геймпадом, прозрачным зеленым. Он, кстати, до сих пор жив.
На этом фото без PS2, но есть другой игровой элемент, по которому легко определить время съемки вплоть до месяца. Олды назовут когда это было? Рядом сидит брат за новым компом, Radeon 9600 и все игры летали на нем.
Ну а тут сам комп немного попал в кадр, хотя фотали, естественно не его)
Надеялся, что будут еще фото с PS1 и GBA, с последним вообще никогда не расставался, но увы. А что у вас есть в фотоархивах?
Недавно мне подарили настоящую легенду — STB 3dfx Voodoo 3 с двумя TMU, 16'ю мегабайтами видеопамяти и 2D-ускорителем. Как настоящий гик и любитель покопаться в ретро-железе, я сразу же нашел даташит и начал изучать внутреннюю архитектуру этого игрового монстра. И поверьте, здесь есть на что посмотреть!
В сегодняшней статье мы во всех деталях изучим архитектуру оригинальной 3dfx Voodoo, узнаем почему Nvidia выиграла в гонке видеокарт и почему игры с API Glide выглядели гораздо красивее, чем с D3D/OpenGL! Если любите настоящие технарские статьи без нейрослопа и рерайта — жду вас под катом!
❯ Предыстория
Думаю многие мои читатели знают, что 3dfx стала одним из пионеров 3D-графики на ПК для геймеров. Их видеокарты не отличались поддержкой «шейдеров», как Rendition Verite, долгое время толком не поддерживали OpenGL, а первые модели для работы требовали отдельную 2D-видеокарту. Однако их успех был обусловлен двумя главными факторами: масштабируемость и производительность.
Rendition Verite V2200. Фото моё
Первая 3dfx Voodoo появилась в 1996 году и несмотря на высокую цену в ~300$, почти сразу стала хитом. Во первых, из конкурентов у Voodoo был разве что NVidia NV1, Rendition Verite и PowerVR Midas. NV1 сразу провалился из-за использования растеризатором квадов вместо привычных разработчикам треугольников, PowerVR был достойным конкурентом, но его TBDR-растеризатор сильно терял филлрейт и подтормаживал при отрисовке полупрозрачных поверхностей типа заборов и решеток (чего в играх всегда хватало), и только Verite был реальным конкурентом. Однако Verite не поддерживал ни OpenGL, ни D3D (который тогда был в зачаточном состоянии) и требовал освоения весьма сложного графического API — SSpeedy3D.
3dfx Voodoo 1 с одним TMU. Фото с TechPowerUp
Дело в том, что в те годы каждый производитель видеокарт предлагал своё графическое API для взаимодействия с видеокартой. У S3 это был Metal, у ATi — CIF, а у 3dfx — Glide. И в отличии от других API, Glide был максимально близок к стандартному и простому OpenGL, только с изначальным упором на игры. В те годы, разработчики игр были вынуждены адаптировать свой движок для каждой видеокарты отдельно и благодаря своей простоте и продуманности, Glide стал неким стандартом — любой уважающий себя движок вплоть до 2000-го года обязательно поддерживал видеокарты 3dfx.
Carmageddon — одна из BRender-игр с поддержкой Glide. Скриншот с форума CWABoard
Однако в 1997 году, у 3dfx уже появились серьезные конкуренты в лице ATi и Nvidia. 3dfx Voodoo мало того что сама стоила ~200-250$, так ещё и для работы требовала дополнительную внешнюю 2D-видеокарту, которая стоила еще баксов 50. За ~150$, Nvidia предлагала новенькую Riva 128 с 4МБ видеопамяти, встроенным 2D-ускорителем, а также аппаратным декодером DVD-видео. ATi Rage Pro стоила примерно столько-же, по тестам была чуток медленнее, чем Nvidia, но также предлагала ноутбучные версии с поддержкой LVDS. Так что ноутбуки с чипами ATi с натяжкой можно было назвать игровыми.
ATI Rage LT Pro в Compaq Armada M300. Фото моё
3dfx решила проблему необходимости 2D-видеокарты весьма интересным костылем: компания выпустила Voodoo Rush — связку из 2D-видеочипа от Alliance Semiconductor и обычной Voodoo 1. Ирония была в том, что на видеокарты ставили как 2D-чипы AT25, так и 3D-чипы AT3D — и получалось что в системе было аж два видеочипа с поддержкой 3D-ускорения (и AT3D был не так уж и плох).
3dfx Voodoo Rush с видеочипом AT25. Фото с сайта vintage3d
Ещё через год, в 1998 году, 3dfx выпустила Voodoo 2, которая стала ещё круче за счёт масштабируемости. Во первых, к GPU стало возможным подключить второй текстурный юнит, благодаря чему стало возможным наносить сразу две текстуры за один проход. А во вторых, теперь можно было объединить сразу две видеокарты с помощью технологии SLI, благодаря чему общая производительность теоретически увеличивалась в два раза. Причём SLI был реализован просто и гениально: первая видеокарта рисовала четные сканлайны, вторая — нечетные, и всё это делалось асинхронно, благодаря чему увеличивался общий филлрейт.
3dfx Voodoo 2 в исполнении Diamond Multimedia. Фото из Википедии
Однако Voodoo 2 всё ещё требовала внешнюю 2D-видеокарту и на момент 1998 года это было уже ни в какие ворота. S3 Savage, ATi Rage 128, NVidia Riva TNT, Matrox G200, Trident 3DImage, Rendition Verite V2200, Intel i740, SiS 6326 — абсолютно все эти видеокарты имели в себе приличный 2D-ускоритель. Причем Riva TNT также поддерживала мультитекстурирование, вплотную подбиралась к Voodoo 2 в бенчмарках и, в отличии от видеокарты от 3dfx, поддерживала рендеринг в 24х-битном формате. Это был главный конкурент Voodoo 2, который местами его заметно превосходил.
S3 ViRGE. Фото моё
В 1999 году появилась 3dfx Voodoo 3, в которой наконец-то появилось 2D-ядро, а благодаря переходу на более продвинутый техпроцесс удалось засунуть сам GPU и два текстурных юнита в один чип. Кроме того, инженерам 3dfx удалось повысить частоту работы видеоядра с 90МГц до 130+. Наконец, благодаря интеграции всех компонентов в один кристалл, стало возможным сделать бюджетную видеокарту — Velocity 100, которая представляла из себя Voodoo 3 с уменьшенным объёмом видеопамяти с 16МБ до 8, а также одним отключенным текстурным юнитом (который включается обратно твиком в реестре :)). Эта версия стоила ~80$ и стала первой доступной Voodoo «для всех».
STB Velocity 100. Фото моё
Но... было уже поздно. 3dfx Voodoo 3 была популярной за счёт остаточной славы и поддержки играми Glide, но с точки зрения функционала, видеокарты от Nvidia и ATi их давно уже уделывали вчистую. В 1999 году, у Nvidia в GeForce 256 уже появился T&L, кубмапы (возможность реализации полноценных отражений), бамп-маппинг и некоторые другие продвинутые техники. Voodoo 4, вышедшая в 2000 году перед банкротством компании, не смогла спасти ситуацию — она хоть и поддерживала 24х-битный цвет, но отсутствие T&L сильно било по производительности в играх с заметно возросшей полигональностью. По итогу, 3dfx обанкротилась и была выкуплена мелким зеленым стартапом — Nvidia :)
❯ Аппаратная архитектура
Как я уже говорил ранее, видеокарты 3dfx не имели каких-то архитектурных особенностей типа возможности загрузки микрокода в GPU или тайлового рендеринга. На практике это были простейшие Fixed-Function сканлайн-растеризаторы, где внешний вид каждого треугольника задавался набором регистров, и кроме отрисовки примитивов GPU больше ничего не умел. Почти во всех остальных картах того периода архитектура была точно такой-же и функционально Voodoo не так сильно отличался от условного S3 ViRGE или Intel i740, просто инженерам 3dfx удалось выжать максимальную производительность.
Однако на аппаратном уровне, видеокарты 3dfx заметно отличались от современников за счет того, что состояли как минимум из трех чипов:
TMU — тот самый текстурный юнит, о котором я говорил в вводной части статьи. В его задачи входит сэмплинг текстур, при этом он занимается не просто выборкой пикселей из видеопамяти, но и мип-маппингом, фильтрацией, а также перспективной коррекцией. В Voodoo 2 на одной видеокарте может быть сразу 3 TMU — что позволяет рисовать геометрию аж с 3-мя текстурами одновременно за один проход. Чисто технически, TMU тоже является полноценным растеризатором, так что его можно считать «мини-GPU».
Если игра рисует примитив с мультитекстурированием (например стенку с наложенной текстурой кирпича и пыли) — рендеринг работает параллельно: сначала первый TMU нарисует стенку с кирпичом, затем второй нарисует с пылью — в конце FBI смешает их и получится пыльная кирпичная стена! Без мультитекстурирования, игре пришлось бы сначала нарисовать кирпичную стенку, затем включить дорогой альфа-блендинг в режиме умножения ((SRCCOLOR * DESTCOLOR) + (DESTCOLOR * 0)) и нарисовать эту же стенку с текстурой пыли ещё раз.
Кроме того, TMU умел в проективные текстуры и всякие трюки с UV-координатами, благодаря чему можно было реализовать проективные попиксельные тени в реальном времени, металлические поверхности за счёт сферических карт отражений (помните отражающиеся машинки в NFS HP?) и некоторые другие фишки.
FBI — сам GPU, выполняющий роль растеризатора и управляющий текстурными юнитами, а также линейным доступом к видеопамяти. Даже у FBI образца 1996 года был весьма богатый функционал: и освещение по Гуро, и попиксельный туман, и дизеринг, и Z-буфер/стенсил-буфер, и даже полноэкранное сглаживание! В общем, было всё необходимое для игр, разве что линии с антиальясингом не поддерживались.
Но были и минусы — FBI первых версий не поддерживал float'ы и оперировал исключительно целыми числами и fixed-point арифметикой, а ещё у него не было понятия Clip-Space — всё рисовалось исключительно в абсолютных экранных координатах. Но об этом чуть позже.
RAMDAC — чип, выводивший фреймбуфер из видеопамяти на экран. Работало это весьма забавно: когда пользователь использует 2D-окружение — RAMDAC в 3dfx Voodoo отключается и VGA-сигнал с 2D-видеокарты коммутируется напрямую на VGA-разъём в Voodoo. Когда пользователь запускает 3D-игру (а в первых 3dfx Voodoo 3D-режим был эксклюзивным) — FBI переключал линии на свой RAMDAC. Получается что в ПК работало сразу два RAMDAC'а одновременно :)
Не менее интересной была и организация памяти. Дело в том, что все 4/8/16 мегабайт видеопамяти были отдельно поделены между TMU и FBI. Каждому TMU отдельно отводилось по 2-16 мегабайт VRAM, которые использовались только для хранения текстурных данных. У FBI была своя память объёмом в 2-4МБ, которая использовалась для фреймбуфера, Z-буфера и Stencil-буфера. От объёма VRAM для TMU зависело сколько текстур и какого разрешения можно загрузить на текущем уровне в игре, а от объёма памяти для FBI зависело максимальное разрешение изображения и возможность использования техник типа Stencil-зеркал или теней.
Схема из даташита 3dfx Voodoo 2
Главной проблемой 3dfx Voodoo был примитивный конвейер, который по большей части ложился на процессор. Для отрисовки каждого треугольника, процессору приходилось:
Посчитать степень освещенности каждого треугольника по алгоритму Гуро и Фонгу. То есть как минимум N ⋅ L.
Перемножить каждую вершину модели на матрицу модели-вида-проекции, чтобы получить позицию треугольника в пространстве экрана — так называемом Clip-Space. Каждую координату нужно было вручную поделить на W-компоненту вершины.
Затем ему нужно было произвести так называемый процесс клиппинга — разбиения наполовину-видимых треугольников, которые пересекают ближнюю плоскость отсечения (или «нос» игрока, если говорить простыми словами). Самый простой пример — это оружие в Quake: если клиппинг не делать, то задняя (невидимая нам) часть пушки просто инвертирует свои координаты и будет отображаться «перевернутой» уходя вдаль, хотя она должна просто скрыться из виду. Это самый тяжелый алгоритм, поскольку требует поиска точки пересечения треугольника с границей экрана и разбиения его на два новых.
Далее ему нужно было преобразовать Clip-Space координаты с плавающей точкой в абсолютные координаты ((((x * 0.5) + 0.5) * width) + (width / 2)). 3dfx Voodoo 2 наконец-то научился в floating-point координаты в Clip-Space, но для совместимости всё равно лучше было использовать «старый» подход.
И только затем пинать его в видеокарту, вручную записывая параметры каждого треугольника в регистры FBI по одному. Помните glBegin/glEnd? Вот это как раз оттуда :)
Для сравнения, в GeForce 256 ни один из этих этапов вообще не нужен был. Геометрию можно загрузить в специальную область в видеопамяти и отправить команду на отрисовку, после чего видеокарта сама всё сделает. Именно поэтому 3dfx Voodoo хорошо себя показывал в старых играх, где сцены были 4000-10000 треугольников, но вот когда игры пошли 30-40 тысяч полигонов... тут уже нагрузка на процессор была слишком высокой.
Между слов...
От схожей проблемы страдали и GPU от Intel. Тот же GMA900 был отнюдь не самым слабым видеочипом, но отсутствие аппаратного вершинного конвейера и установка в бюджетные ноутбуки с слабыми процессорами сделало своё дело...
Аппаратный конвейер в Intel'ах появился только начиная с GMA 500 — и то это на самом деле был PowerVR SGX535 :)
Интересно и то, что в 3dfx Voodoo 2 уже были зачатки 2D-движка в виде аппаратного блиттера, причем с возможностью блиттить как из оперативной памяти ПК, так и видеопамяти, но API для него в Glide я не нашел. Судя по всему, 3dfx просто не успела доделать полноценный VGA-совместимый контроллер в 1998 году, оставив в видеочипе только блиттер.
Схема из даташита 3dfx Voodoo 2.
На самом низком уровне, управление 3dfx Voodoo происходило в основном с помощью замаппленых в память регистров. Драйвер искал PCI-устройство, выделял ему Base Address Register и затем конфигурировал FBI относительно текущего видеорежима. Когда игра хотела нарисовать следующий треугольник, драйвер записывал параметры вершин в соответствующие регистры FBI и TMU (да, регистры, связанные с вершинами у них дублировались) и отправлял команду TRIANGLECMD.
Вот он, D3D11_INPUT_ELEMENT_DESC! Скриншот из даташита 3dfx Voodoo 2
Да, всё было настолько просто. Как я уже говорил, так было не только у 3dfx, но и у S3 (о ViRGE я писал отдельную статью), Intel, SiS, ATi и Nvidia до GeForce 256. Отличался только Rendition Verite, но о нём мы с вами поговорим как-нибудь в другой раз.
❯ Программная архитектура
С точки зрения софта, у 3dfx Voodoo тоже всё было не так однозначно. Конечно основным графическим API был Glide, однако в 1997-1998 году стандартизацию и влияние OpenGL и Direct3D отрицать было глупо. Всё больше и больше игр использовали D3D, поддержку которого 3dfx поспешно добавила в 1997 году. Тут важно отметить то, что в те годы каждая версия Direct3D очень сильно друг от друга отличалась. Direct3D 5 оперировал командными буферами на манер современных видеокарт (Microsoft глядели в воду!), Direct3D7 уже был больше похож на OpenGL/D3D9, и обратной совместимости, как в случае с D3D11/D3D10/D3D9 у них не было — 3dfx приходилось писать новый драйвер под новые версии DirectX.
Ещё про командные буферы
Назывались они Execute-буферами и имели тот же функционал, что и списки в OpenGL. Microsoft надеялась что рано или поздно Execute-буферы можно будет выполнять напрямую на GPU - и угадала примерно к 1999-2000 году.
Самое забавное что сама концепция не прижилась и вплоть до D3D11 в видеокартах не было нормальных буферов команд.
Не путайте командные буферы с стейтблоками - это разные вещи.
Лого 3dfx. Взято с ныне почившего сайта компании
С OpenGL тоже было всё не так гладко, поскольку в 1996 году его перспективы в играх всё ещё были туманны из-за ориентира на профессиональные рабочие станции. В конце-концов, кому в играх нужен был рендеринг на сервере? Однако игра поколения, Quake, использовала именно это графическое API и 3dfx пришлось сделать небольшой костыль вместо полноценного драйвера — MiniGL.
MiniGL работал поверх нативного графического API (т.е Glide) и предоставлял игре минимально-необходимый для работы набор функций — то есть рисование треугольников/квадов, работу с текстурами, матрицы и... ну, по сути все. Другие игры также могли использовать MiniGL, но у них не было доступа ни к функциям работы с туманом, ни к освещению в реальном времени, ни к мультитекстурированию, ни к Stencil-буферу. Немного позже другие производители видеокарт тоже начали реализовывать свои драйверы MiniGL и это стало своеобразным MiniAPI внутри Quake.
Полноценный нативный ICD-драйвер (так в те годы называли полноценные драйвера OpenGL) для OpenGL вышел только в 1998 году в виде бета-версии... и по сравнению с MiniGL, он был нереально тормозным и глючным! Часть функционала была забагованной, производительность была не ахти и даже в Quake на ICD видеокарта показывала себя хуже, чем с MiniGL. Но в целом, 3dfx за это винить не стоит — в те годы нормальные драйвера для OpenGL были только у Nvidia, S3 и Intel (иронично). Даже у ATi с OpenGL всё было очень плохо...
Поэтому главным секретом успеха 3dfx стало API Glide. Как я и говорил ранее, оно как две капли воды было похоже на упрощенный OpenGL, но отличалось отсутствием математической библиотеки, клиппера геометрии (да, программист был вынужден писать его сам, в отличии от D3D и GL) и... аллокатора текстур! Да, вы все правильно поняли — предполагалось что именно программист будет вручную управлять видеопамятью каждого текстурного юнита и ручками писать логику выделения/освобождения памяти.
С игровой точки зрения, Glide был функционально богаче D3D и OpenGL, и обгонял их на несколько лет вперед. Уже в 1998 году, в Glide была поддержка мультитекстурирования и комбайнеров, хромакея вместо альфа-теста (который требовал дополнительный цветовой компонент и занимал драгоценную видеопамять) и прямого доступа к фреймбуферу. Зато не поддерживались текстуры с разрешением выше 256x256 и соотношением сторон, отличающимся от 1:1 и 2:1...
В остальном, Glide был практически прямым интерфейсом к видеокарте, благодаря чему работал быстро. Но к 2000 году, Glide окончательно устарел концептуально, вместе с архитектурой оригинального 3dfx Voodoo, из-за чего компания и разорилась. ATi и Nvidia оказались шустрее...
❯ Заключение
Вот такой была 3dfx: сначала компания влетела на рынок игровых видеокарт с двух ног, успела стать стандартом ПК-гейминга, но всего через 3 года её архитектура устарела настолько быстро, что в 2000 году её поглотил какой-то там стартап с зеленым логотипом... Увы и ах, остается только надеяться, что инженеры 3dfx приложили руку к таким легендарным видеокартам, как GeForce 3 и GeForce 4! Хотя кто знает, может кто-то из них сейчас разрабатывает RTX 6xxx? :)
Ну а я надеюсь, что вам было интересно. Подписывайтесь на блог, чтобы не пропускать новые статьи каждую неделю! А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.
А если вы хотите что-нибудь подарить из железа и увидеть о нём статью — пишите мне в Telegram. Меня очень интересуют самые разные гаджеты: начиная от игровых консолей и любых связанных с геймингом устройств, телефонов, смартфонов, КПК, заканчивая ретро-компьютерами и ноутбуками. Кто знает, может героем следующейподобной статьи окажется ноутбук из 90-х? :)
Особенно сильно я люблю ковыряться в ноутбуках из начала 90-х. Источник
После обзоров устройства не продаются, а остаются в моей коллекции. Когда-нибудь я хочу сделать музей, где к каждому устройству можно будет приложить QR и почитать мою статью. Кто знает, вдруг на следующей неделе я также подробно расскажу про девайс из вашей юности? :)
Кстати, у меня есть GameBoy Advance SP, под который я очень хочу написать игру. Однако мой экземпляр был залит водой и кофе. Может у кого-то есть донор с дохлой платой, откуда я смог бы взять контроллер питания? У меня AGS-101.
22 марта 1993 года Intel выпустила первые Pentium 60 и Pentium 66 — процессоры, с которых началась одна из самых известных линеек в истории персональных компьютеров. Именно Pentium стал первым суперскалярным процессором Intel и открыл новую эпоху производительности для массовых ПК. По данным Tom’s Hardware, первые чипы Pentium содержали 3,1 млн транзисторов, выпускались по 800-нм техпроцессу и стали важнейшим шагом вперёд по сравнению с Intel 486.
Секрет успеха Pentium был не только в росте частоты. Архитектура P5 позволяла выполнять несколько инструкций за один такт, использовала встроенный кэш, 64-битную внешнюю шину, динамическое предсказание ветвлений и заметно более быстрый блок вычислений с плавающей точкой. Всё это сделало Pentium символом настоящего технологического рывка и одним из самых узнаваемых брендов в истории CPU.
Но история Pentium — это не только триумф. В 1994 году линейка оказалась в центре громкого скандала из-за ошибки FDIV в блоке вычислений с плавающей запятой. Проблема привела к первому массовому отзыву процессоров Intel и стоила компании около 475 миллионов долларов, серьёзно ударив по репутации бренда. Тем не менее Pentium не просто выжил, а стал основой для целого поколения домашних и офисных компьютеров.
Думаю, при упоминании знаменитого бага в процессоре Intel Pentium на ум сразу приходит ошибка деления. Но, как оказывается, она была не единственным косяком этих чипов.
Первые «пеньки» имели ещё одну интересную особенность: существовали «роковые» четыре байта, выполнение которых заставляло компьютер зависнуть намертво. Что же это была за ошибка, как она проявлялась и как её воспроизвести? Сейчас и узнаем.
❯ Суть такова
Наверное, многие кучу раз уже слышали про то, что в некоторых процессорах Intel Pentium существовал дефект, заставляющий их считать неправильно.
Этот косяк стал очень знаменитым и ныне встречается абсолютно в каждой статье в духе «10 самых разрушительных багов тысячелетия».
Но ошибка деления была не единственным багом в данном процессоре. Чуть менее знаменитым, но не менее впечатляющим стал F0 0F, о котором сегодня и пойдёт речь.
❯ Что же это вообще такое?
Немного поговорим о том, что же это вообще за дефект. Итак, некоторые процессоры Pentium (все с архитектурой P5) имели аппаратную ошибку: выполнение одной некорректной инструкции вместо исключения приводило к тому, что процессор переставал работать до полной перезагрузки. Сама эта команда (в самом популярном для демонстрации варианте) выглядела так:
lock cmpxchg8b eax
Объяснить с
Сама по себе эта инструкция использовалась для сравнения значения данных в регистре с 8 байтами в памяти, а при неправильном её использовании процессор просто бы выдал исключение. Но в сочетании с префиксом lock пенёк блокировал шину памяти и ждал записи, которая так никогда и не происходила. В результате этого он переставал отвечать на любые запросы, в том числе на прерывания, обработчик которых тоже не работал. Команда эта кодировалась байтами F0 0F C7 C8, которые и послужили названием данного дефекта.
Данная ошибка не причиняла никакого вреда компьютеру, а после перезагрузки работоспособность восстанавливалась. Тем не менее, особых привилегий для выполнения «роковых» байт не требовалось, отчего любая программа могла заставить компьютер зависнуть, приведя к потере несохранённых данных или отказу в обслуживании (если инструкция была выполнена на сервере).
В дальнейшем проблема была решена. Сначала программно, путём создания различных патчей для ОС, не дававших выполнить эту инструкцию и повесить ПК, а после и аппаратно — в степпинге B2 баг был ликвидирован. Как удалось найти, дефектные процессоры тоже отзывались и бесплатно менялись, хотя и не в таких количествах, как в случае с ошибкой деления.
❯ Обзор оборудования
Ну что же, перейдём к тестированию.
Для этого нам понадобится компьютер. В качестве него взял уже ранее показанный пень.
Внутри него стоит вот такой камень, как и многочисленные его собратья, подверженный этому багу.
А вот другой пенёк. К нему всё, что будет упомянуто далее, тоже применимо.
Поиск по sSpec это подтверждает: процессор имеет степпинг B1.
❯ Ставим софт
Теперь очередь того, чем мы будем собирать тестовый экзешник. В качестве этого софта взял Microsoft Visual C++ 5.00. Так что включаем компьютер, загружаем Windows 98 и ставим всё необходимое.
Попытки поставить 6.0 или наоборот более ранние версии провалились: одна требовала вставить некий «Disk 1» и в упор не видела установочные файлы, другая требовала наличия лицензионного CD в приводе. То ли мне попался неполный дистрибутив, то ли его обязательно надо было ставить с диска, то ли что, но разбираться с этим я не стал, просто скачал тот архив, где таких проблем не было. Им и оказалась версия 5.00.
Открываем установщик и в открывшемся меню выбираем самый первый пункт. Далее при установке вводим CD-key из одних единиц, а все остальные параметры оставляем по умолчанию.
Спустя минут пятнадцать софт устанавливается.
Всё готово к работе.
Далее создаём проект и пишем какую-нибудь пробную программу, дабы убедиться, что все нужные компоненты встали правильно.
Всё отлично работает. Можно приступать к проверке.
❯ Роковые четыре байта
Итак, удаляем всё, что было, и пишем следующий код:
#include <stdlib.h>
char main[] = {0xF0, 0x0F, 0xC7, 0xC8};
Объяснить с
После этого собираем проект.
Ну что, момент истины?
Запускаем собранный экзешник. Чёрное окно, один раз мигнувший курсор, и… компьютер зависает наглухо.
Не работает даже переключение светодиодов на клавиатуре. Единственная возможность выйти из этого состояния — жмякнуть кнопку Reset.
❯ А что там на других системах?
Перезагрузим машину и попробуем загрузиться в Windows 2000.
Здесь эта проблема больше не проявляется. То же самое приложение при запуске просто вылетает. Компьютер при этом остаётся работоспособным.
На современном ПК всё ещё проще: пустое окно консоли, закрывающееся через пару секунд.
❯ Что же в итоге?
Как можно видеть, вскоре после того, как ошибка была обнаружена, её уже исправили. В ядре Linux патч для неё появился уже через неделю. Вскоре исправление вышло и для Windows — им стало обновление KB163852. Как мы сами сегодня убедились, поздние версии ОС уже не позволяют так просто заставить ПК зависнуть.
Позже так стали называть и другие схожие по проявлению баги. В частности, некоторые модели процессоров Cyrix тоже могли зависать при выполнении некоторых инструкций.
В Pentium Pro и более поздних процессорах этот баг был исправлен окончательно, на этот раз на аппаратном уровне.