LINUX.ORG.RU

Энтузиасты дизассемблировали микрокод i386 и создали открытый CPU z386

 , , , z386,

Энтузиасты дизассемблировали микрокод i386 и создали открытый CPU z386

6

6

Энтузиасты смогли успешно извлечь и дизассемблировать микрокод процессора Intel 80386, который из-за отсутствия документации считался «чёрным ящиком». Бинарный образ микрокода был воссоздан с привлечением AI по фотографиям кристалла в высоком разрешении, а логика работы разобрана через трассировку соединений на кристалле. Постепенно были определены структура микрокоманд (μ-ops), поля, порядок исполнения и маркеры конца инструкций. Наработки проекта опубликованы на GitHub как общественное достояние.

Выявлено, что в CPU 80386 каждая инструкция полностью исполняется через микрокод, в то время как в 8086 и современных процессорах часть инструкций обрабатывается напрямую. Кроме того, в отличие от процессоров 8086, в 80386 микрокод не реализует алгоритмы напрямую, а в основном настраивает аппаратные ускорители (умножитель, делитель, быстрый сдвиг, PTU (Protection Test Unit)).

В ходе исследования также была обнаружена возможная проблема с безопасностью при обработке битовой карты прав доступа к вводу/выводу (IO permission bitmap): при 4-байтовом обращении к портам проверялись биты прав доступа только для первых 3 байтов, а доступ к 4-му байту не проверялся, что теоретически допускало обращение к аппаратным регистрам, доступ к которым должен был быть запрещён.

На основе опубликованного микрокода разработан открытый CPU z386, реализованный на языке SystemVerilog и работающий с использованием FPGA. Вместо реализации каждой инструкции в форме отдельного RTL (wikipedia.org) (Register-transfer level) в z386 реализованы аппаратные структуры, которыми управляет оригинальный микрокод. Производительность подготовленной реализации соответствует быстрому 386 ПК (~70MHz). Под управлением z386 удалось успешно запустить DOS 6/7, DOS/4GW, DOS/32A и игры, такие как Doom и Cannon Fodder.

>>> Подробности на opennet



Проверено: dataman ()
Последнее исправление: dataman (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Нет, в интеловских процах по сей день сегментная модель есть и работает.

только если ты застрял в 32 битах под своим дос-екстендером
в 64 битах этой канители нет

madcore ★★★★★
()
Ответ на: комментарий от madcore

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Наоборот, он чудовищно медленный. Хуже чем всё на 3-4 поколения назад.

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

madcore ★★★★★
()
Ответ на: комментарий от kirill_rrr

Технологии украдут

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

madcore ★★★★★
()
Ответ на: комментарий от kirill_rrr

Разве? В х86 ядра только жирнеют. Да и тепловые пакеты в киловатт+ это новинка а не то от чего хотят отказаться. Как и чиплы размером с 2 ладони и больше.

x86 не является лидером или каким-бы то ни было показателем, но даже x86 в любой реализации, Интел с E-cores или АМД с их 256-ядерной Венецией больше смотрят на int8, fp16, 16x16 mmx, то есть то, что нам с вами нафиг не нужно. Да и запустить чип размером с ладонь так, чтобы он целиком проработал хотя бы минуту мы не можем. Вон Cerebras, что далеко ходить, сделали большой чип, фотки, сказки все дела, как его использовать целиком? Только по частям, как конвейер. Оно в датацентре надо, такой геморрой?

VIT ★★
()
Ответ на: комментарий от kirill_rrr

Налепили химеру отовсюду понемногу, получилось что то примерно равное Зен+.

А вроде китайцы у AMD как-то лицензировали ryzen (zen+)

One ★★★★★
()
Ответ на: комментарий от One

AMD уже огребла за этот саботаж, а китайцы выпускают 128-ядерные чипы под маркой Sugon.

VIT ★★
()
Ответ на: комментарий от kirill_rrr

С другой стороны, кто нибудь оценивал как на практике могла бы выглядеть 16-ядерная версия i386 на 12нм при частоте 3-4Ггц?

Да, мы делали это, только для 1.5-1.8GHz, с плав. запятой, но и ещё пару вещей по мелочи, типа векторные расширения, серьёзный префетчер, серьёзная доработка atomics. Для 2009-2010 года показатели были отличные.

VIT ★★
()
Ответ на: комментарий от kirill_rrr

Их лучше переизобрести, что уже сейчас и делают.

aiqu6Ait ★★★★★
()
Ответ на: комментарий от devl547

В этом зоопарке хотя бы нет intel me / amd psp.
Так что мочить интол и арм, «жизнь ворам» (с) и risc-v!

Hertz ★★★★★
()
Ответ на: комментарий от One

смогут ли китайцы выпускать при этом x86 совместимые процессоры

Смогут. Kaixian - это Centaur/VIA.

devl547 ★★★★★
()
Ответ на: комментарий от kirill_rrr

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

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Но где это используется существующими ОС и софтом?

«Для ARM64 (PAC / BTI): Например, в Debian и Ubuntu флаг -mbranch-protection=standard включен на уровне дистрибутива по умолчанию.»
«Для x86_64 (Intel CET / AMD Shadow Stack): Поддержка в ядре Linux появилась в ветке 6.6+, а в glibc — начиная с версии 2.39. Большинство современных дистрибутивов (Fedora, Arch, Ubuntu) уже компилируют пакеты с флагом -fcf-protection.»

GAMer ★★★★★
()
Ответ на: комментарий от madcore

если ты застрял в 32 битах

Вам часто нужны сегменты размером больше чем 4 гига? Специально подчеркну что это ограничение на один сегмент, а не на всё адресное пространство процесса.

в 64 битах этой канители нет

Там вообще с механизмами защиты памяти всё слишком примитивно.

watchcat382 ★★
()
Ответ на: комментарий от madcore

современных техпроцессов

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

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Интел вон уже доигрался в миниатюризацию

Причина проблем Интел не в этом. TSMC тоже играет в миниатюризацию, но ни Nvidia ни AMD ей это не предъявляют.

VIT ★★
()
Ответ на: комментарий от GAMer

уже компилируют пакеты с флагом -fcf-protection.»

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

watchcat382 ★★
()
Ответ на: комментарий от VIT

После четырех десятков лет процессоростроения выкатить в продажу процы ХУЖЕ по надежности чем предидущие - это конечно выдающееся «достижение» и достойный результат «развития». Причем ладно бы это касалось каких-то там дико дорогих самых топовых процов. Так ведь нет - и вполне обычные кривыми получились.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Не так много людей знает реальную проблему, с которой столкнулась Интел при разработке 10нм. Именно в тот момент, когда нужно было принимать взвешенное и обдуманное решение, Интел столкнулась с эффективным менеджером, упрямым и тупым. Дурак ушёл, 18А задвигался, но цена - время и деньги - это, конечно, не вернуть.

VIT ★★
()
Ответ на: комментарий от VIT

Всё это так. Но главный вопрос - а нужно ли вообще 10нм для изготовления «офисно-бытовых» процов? Что для топовых нужен - понятно. А вот обычных? Да, эффективные менеджеры внушают нам что надо. Но правы ли они? Тем более учитывая вполне реальную перспективу что ИИ научится оптимизировать софт на уровне исходников и разгребет накопившеся завалы мегабайтов легаси.

watchcat382 ★★
()
Ответ на: комментарий от watchcat382

Не знаю, но если всё сделать правильно, то по сравнению с 14нм 10нм уменьшает и размер и мощность при прочих равных. Кто хотел лаптоп потоньше или телефон на 3 дня без зарядки?

VIT ★★
()
Последнее исправление: VIT (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Во-первых, так получится обьявить не более 8192 массивов (ограничение размера дескрипторной таблицы).

Во-вторых, на каждое создание или изменение размера такого массива придётся дёргать ядро ОС, потому что непривелегированный код не может редактировать дескрипторы. А это очень медленно, особенно в те времена когда не было syscall, а только через прерывания дёргать ядро. Хотя и сейчас системные вызовы дорогущие.

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

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

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

так получится обьявить не более 8192 массивов

Думаю что не обязательно вот прямо каждый-каждый массив пихать в отдельный сегмент в тех программах где массивов много. Можно же объявить сегмент, содержащий сразу несколько/много массивов. Для каких-нибудь буферов в самый раз будет - в крайнем случае будет попорчен только соседний буфер, но не получится испортить что-то еще(код, стек) или передать управление в записанные в массив данные, выполнив их как код.

на каждое создание или изменение размера такого массива придётся дёргать ядро ОС, потому что непривелегированный код не может редактировать дескрипторы. А это очень медленно

Я застал времена когда и КИЛОбайты на дисках экономили. Потом диски стали большие и перестали. Также и с производительностью - прошли времена когда обычному юзеру могло процессора не хватать в его задачах. А в тех редких задачах где действительно может не хватать - никто не заставляет использовать сегменты по максимуму.

А вот надежности в современном софте не хватает регулярно по сей день. И средства аппаратного контроля ошибок точно не будут лишними. Потому что программно проверять те же границы массивов - еще медленнее. Вон компилятор Ады gnat это вполне умеет. А компилятор Meridian ADA под дос-экстендером таки умел использовать аппаратные возможности проца. Аж почти 35 лет назад.

если с сегментом работает несколько потоков, то нет возможности обновить сегмент сразу для всех

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

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

Ничего, кроме блока информации о текущем процессе/потоке туда не засунули даже на винде.

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

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

А еще, безотносительно обсуждения сегментов, но по теме начального сообщения замечу, что реверс-инжиниринг интеловских процов это хорошо и в том смысле что возможно со временем появится возможность создавать под них полностью свои системные платы. Без использования навязываемого дизайна с «чипсетом», в котором находится в том числе и реализация Intel ME. Да и архитектура этого «чипсета» тянет за собой немало легаси и сейчас не является технически оптимальной. Тут кстати на ЛОРе не так давно была ссылка на кого-то, сделавшего самодельный ноутбук. И вот там в видео было упоминание что в открытом доступе недостаточно технической информации чтобы запустить интеловский проц на плате полностью собственной разработки. В итоге сделали на каком-то из китайских ARM SoC, для которого такая информация доступна.

watchcat382 ★★
()
Ответ на: комментарий от kirill_rrr

Казалось бы, ещё в 2005-08 стало понятно что нужно распаралеливать вычисления и наращивать каналы памяти.

То, что надо распараллеливать вычисления, знали и 40 лет назад, а может и 50.

То, что надо наращивать каналы памяти - это твоя выдумка.

Лет 10-15 назад придумали микросервисы

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

firkax ★★★★★
()

Что-то подбило меня вчера найти и забрать книжку Г.В.Орловский «Введение в архитектуру микропроцессора 80386» :-D

hatred ★★★★
()
Ответ на: комментарий от madcore

Атом чисто теоретически мог исполнять 2 инструкции на такт, но механизм порезали настолько сильно что по факту было 1,1 в среднем. Причём с регулярными блокировками и ожиданиями, короче он не просто так в производительности на 1600Мгц конкурировал с 200Мгц коре2, уступая UVL-версии в производительности на ватт. Не помню что там было с переупорядочиванием инструкций, но по факту ядро большую часть времени стояло и ждало. Ну и исполнение по несколько тактов, причём сильно больше чем у взрослых ядер.

kirill_rrr ★★★★★
()
Ответ на: комментарий от madcore

А чисто китайский 12нм это чьё производство? Хотя не важно, литографы уже стоят и убрать их можно только бомбардировкой. Вдогонку разрабатываются свои, так что важно чтобы хотя бы один производитель был через 3-5 лет.

kirill_rrr ★★★★★
()
Ответ на: комментарий от VIT

Амперы и Cerebras были не слишком то удачные. Гравитон5 выглядит не так монструзоно, но он как бы в 2,2 раза больше по транзистоорам чем 96-ядерный амд эпик. Как раз должен быть размером с ладонь, хотя информации нету. И самое главное - они используются полностью. Или в куче небольших задач, или под ИИ. Соответственно у конкурентов нет выбора - нужны такие же огромные монстры.

kirill_rrr ★★★★★
()
Ответ на: комментарий от One

Там сложнее. Они купили VIA с правом создавать х86 процессоры и во время сотрудничества с амд надёргали из зен+ каких то кусочков и решений. Вроде бы как сотрудничество и патенты заморожены, но технологии утекли. Производительность ядра они догнали, но там какие то компоненты всё ещё уровня бульдозеров.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Конечно нужен! Ноутбуки и мобилки должны жить от батареи неделями не выключаясь. Тут бы выделять маленький энергоэффективный кластер на самом топовом техпроцессе, а вот игровую производительность от розетки добивать «как получится». А пока что наоборот, soc и iod на отстающем техпроцессе.

kirill_rrr ★★★★★
()
Ответ на: комментарий от firkax

То, что надо наращивать каналы памяти - это твоя выдумка.

12 канальные серверы и 4-канальные десктопные интелы и амд - моя выдумка? Польщён...

kirill_rrr ★★★★★
()
Ответ на: комментарий от watchcat382

Вам часто нужны сегменты размером больше чем 4 гига?

long mode отличается не только разрядностью указателей(которые, кстати, тоже могут быть 32 бита)
в два раза больше рон, кроме того, что они сами в два раза больше
подчищенный и оптимизированный набор инструкций

Там вообще с механизмами защиты памяти всё слишком примитивно.

т.е., ты об этом ничего не знаешь

madcore ★★★★★
()
Ответ на: комментарий от watchcat382

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

т.е., вся эта концепция нерабочая

madcore ★★★★★
()
Ответ на: комментарий от watchcat382

А у 386 есть то, чего нет ни у risc ни у loongarch, ни у arm - сегментный механизм защиты памяти. Помещаем массив в отдельный сегмент и каждое обращение к нему будет аппаратно проверяться на соответствие границам.

У Эльбруса (e2k) лучше. Там каждый массив контролируется, включая те, что на стеке.

monk ★★★★★
()
Ответ на: комментарий от kirill_rrr

Это под многопоточку, даже 4 ядра не прокачают два канала. Поэтому, например Wildcat Lake, вообще одноканальный.

GAMer ★★★★★
()
Ответ на: комментарий от monk

У Эльбруса лучше, кто ж спорит. Но под это дело нужна правильно собранная ОС и отдельная сборка программы. Плюс производительность таки проседает заметно.

GAMer ★★★★★
()
Ответ на: комментарий от watchcat382

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

windprop2
()
Ответ на: комментарий от windprop2

без освоения западных наномикронов

или дальневосточных

vM ★★★
()
Ответ на: комментарий от GAMer

В качестве ОС линукс на Эльбрусе уже есть. Отдельная сборка программы и для 386 нужна, чтобы сегменты использовать, и использование сегментов просадит производительность сильнее, чем РБВ Эльбруса.

monk ★★★★★
()
Ответ на: комментарий от kirill_rrr

И самое главное - они используются полностью.

Вот интересно, как вы это определили. Вот прямо все 192 ядра используются на полную? Не верю. Честно, ни на грамм не верю.

VIT ★★
()
Ответ на: комментарий от monk

В качестве ОС линукс на Эльбрусе уже есть.

Их, АФАИК, всё-таки несколько даже от МЦСТ. Режим защищенного исполнения с тегами и общий режим.

GAMer ★★★★★
()

Увидел в описание ссылку на ядро для Mister FPGA. Ух! Теперь там можно запустить DOOM максимально нативно. 🤣

Radjah ★★★★★
()
Ответ на: комментарий от kirill_rrr

Атом чисто теоретически мог исполнять 2 инструкции на такт, но механизм порезали настолько сильно что по факту было 1,1 в среднем.

Никто ничего не резал. Просто не всякие две инструкции можно было совместить в один такт, была сложная система определения, как правильно выбрать инструкции, а окно выборки - всего 48 микро опс. Этого было недостаточно. Это первая проблема. Поскольку делать это сложно, чуваки, ответственные за LLVM, Xinmin и его группа, всё сделали по традициям Интел - тяп-ляп и так сойдёт. Это вторая проблема.

VIT ★★
()
Ответ на: комментарий от kirill_rrr

То, что надо наращивать каналы памяти - это твоя выдумка.

12 канальные серверы и 4-канальные десктопные интелы и амд - моя выдумка? Польщён…

Справедливости ради надо сказать, что наращивать надо было объём и степень параллелизма доступа к памяти, а добавление каналов есть побочный от этого эффект. Те, кто реально заморочился пропускной способностью, сразу перешёл на HBM и получил, пусть дорого, свои 3TB/s, а все эти прыжки с 12 каналами DRAM так и остались на уровне полутерабайта плюс минус копейки.

VIT ★★
()
Ответ на: комментарий от saufesma

Ты деньги с китайцев берешь за рекламу их продукции?

Просто он не очень внимательно слушал слова господина Си «мы не союзники, мы партнёры». Вот как «партнёру» станет не выгодно, посмотрим, что он будет тогда говорить.

VIT ★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.