Комментарии 217
Из первых абзацев складывается впечатление, что речь пойдёт о чём-то новом, появившемся в 80486. Но почти всё, что описывается далее, появилось раньше не только 80486, но зачастую раньше 8086. Многопроцессорные системы, виртуальная память, кэши, TLB, внеочередное выполнение команд, SIMD -- всё это было известно ещё в 1960-70-е...
Вентиляторы на процессоре? ;-)
Ну, интегрированное в один чип, такого не было, были отдельные элементы, включая микрухи с кэшем на материнке. Сопроцессор тоже отдельной микросхемой был, хотя вот уже не помню, кажется 486SX без сопроцессора, надо было отдельно к нему ставить 487, а вот 486DX уже с сопроцессором внутри.
Математические сопроцессоры были с Intel 8088/8086 https://en.wikipedia.org/wiki/X87
Интегрированных в центральный процессор не было, были отдельными микросхемами 8087. Интергированные варианты кажется пошли с линейки dx, толи 386dx, толи 486dx
486DX. Для 386DX был 387.
Это для 386SX был 387. 386DX в сопроцессоре не нуждался.
Точно не было встроенного сопроцессора, ни в 386DX, ни в SX :)
процессоры i486 впервые обзавелись такими компонентами, как кэш-память, конвейер, встроенный сопроцессор и коэффициент умножения (множитель)
https://www.ferra.ru/review/computers/processor-evolution-part-3.htm
Да, правда Ваша. Что-то память начала мне изменять. До Вашего комментария был готов поклясться, что только 386SX был нужен сопроцессор. Был неправ.
Хорошая была эпоха... Весёлая.
Тем временем, 486SX действительно нуждается в сопроцессоре.
Эту ступень я перепрыгнул - сразу после 386DX40 у меня был 486DX4-100. Так что не сильно в курсе.
Хороший такой буст...
По тем временам вполне обычный. Денег не было на новый комп (386 покупался в 1991-1992 с мегабайтом памяти, а 486 уже в 1996-1997), да и произодительность устраивала. Турбо Паскаль, С - были, игрушки (LHX, DeathTrack, Commander Keen, Kings Bounty, какая-то прикольная игруля про древнюю Англию - надо было всех завоевать) - тоже были. Клиппер был (база данных тех времён). Волков коммандер был. CD-ROM, модем, голдед - всё как у всех.
486 продержался года полтора и был заменён Атлоном в 1999-2000.
А вот самый крутой буст был когда я сменил Искру-226 на Искру-1030.11. Вот это был буст так буст! Сразу с 8" дискеток на винчестер (целых10 Мб!) и 5" дискетки. Принтер матричный (СМ 6337)! Плюс электричество не вырубалось, когда его включали в холодные дни.
С четверки на Атлон тоже должен быть неплохим прыжком: GUI, 3D-ускоритель, 3D-звук, сеть, CD/DVD…
CD у меня стоял уже на 386. CD по тем временам было большим достижением, как интернет сейчас. Можно было купить сборники типа "BBS #1" и далее по возрастанию номеров.
Звук, возможность проигрывать видюшники (тогда, помню, "Матрица" вышла, смотрел и в кино и на компе, с лагами, конечно, но смотреть было можно), сменить ДОС на винду - это пришло только с Атлоном. Этот Атлон с XP до сих пор стоит, правда не включается. Нет, он работает, но уже не интересен.
Да, сети на 386 у меня не было. Цены на интернет кусались. Но почту уже в 1991-1992 году можно было качать. По UUCP. Оплачивалась покилобайтно!
Ну вообще-то не совсем. 386 впервые обзавёлся 16 байтами кэша.
Нашлись подробности на Хабре:
Процессор не содержал блока операций с плавающей точкой, для этого использовался отдельный сопроцессор 80387, выпущенный несколько позднее, из-за чего тот самый первый Compaq имел гнездо для сопроцессора предыдущего поколения, 80287, работавшего асинхронно на более низкой частоте и имевшего более низкую производительность на такт.
все так, я помню ток линейки 386 и 486 с DX, были бодрые машины того времени)) у меня первый новый комп появился как раз 486DX-100. с кнопкой Turbo конечно :) на первый пенек P-75 у родителей денег не хватало
Интегрированное -- возможно, но дело-то в том, что это никаких принципиально новых возможностей не открывает и является обычным эволюционным улучшением уже хорошо известного, а не чем-то революционным. Польза несомненна, но не более того.
просто сильно раньше процессор и был на рассыпухе. и собственно процессором был шкаф-стойка или даже несколько. да и процессоров могло быть несколько и некоторые специализированные. на какой-нибудь СМ-4 сидишь себе в терминале со своим процессором 580вм80 и памятью и редактируешь текст, а потом на компиляцию- выполнение на центральный процессор отправляешь... тут главное что нового появилось в теории процессоростроения, а не в реализациях.
Если говорить об СМ-4 и иже с ней (PDP-11, в общем), то и редактирование шло не на терминале, а на самой машине: каждое нажатие клавиши посылало тот или иной код в машину (через UART -- COM-порт, выражаясь более знакомым для многих языком, хотя там и были нюансы: например, в качестве физического интерфейса чаще использовалась токовая петля 20 мА, а не RS-232), и запущенный там текстовый редактор его обрабатывал. Автономный режим иногда был, но для работы он не использовался: штатное ПО было рассчитано именно на посимвольный приём любого ввода и посимвольную же выдачу отображаемого и команд управления (позиционирование курсора и т.п.). Соответственно, если с машиной одновременно работали несколько человек и кто-то запускал, скажем, компиляцию чего-то тяжёлого, текстовые редакторы у остальных начинали подтормаживать.
Вот на ЕС ЭВМ (IBM System/360 и продолжения) терминал (ЕС-7927, главным образом) действительно работал автономно, пока не нажималась одна из клавиш, дёргавшая машину (ввод и функциональные).
я вот честно смутно это помню :) я еще школьником на них сидел в 90 году в МЭИ. помню зачетные команды kill и suspend... если всему классу терминалов все отрубить, то потом только с админского в отдельной комнатушке оживиться можно было... терминалы там импортные были какие-то и потом когда попилил машину 580 микрухи и другие запчасти продавали в магазинчике в М корпусе. с ЕС ЭВМ у меня только маман дело имела и то в молодости. и потом на XT довольно быстро перешла. а вот куда всякие книжки девать по этим машинам я не придумал. выкидывать жалко...
На хабре была недавно публикация, в которой упоминалась Группа по популяризации ЕС ЭВМ https://t.me/+MtYmrFE9VYo1NGJi
собирают литературу и прочие материалы.
забукмаркил.
Интересно, эти популяризаторы хотя бы одну ЕС ЭВМ смогли восстановить и запустить ?
Их в 1990-е массово сдали на металлолом -- банально нечего восстанавливать. Может, у вояк что и осталось, но оттуда не уволочёшь.
Хорошо если у вояк действительно что-то осталось, тогда есть еще надежда что-то получить "для музея". Включать эти машины все равно уже некому, людей способных набивать код загрузчика тумблерами с консоли совсем не осталось.
Ну, я без проблем набью. Более того, будь в моём распоряжении рабочий процессор от ЕСки, я бы запустил таки всю машину, сделав эмулятор периферии (дисков, лент, терминалов и т.п.).
Снимаю шляпу, мое вам уважение. С интересом читал ваш цикл про ЕС-ки (https://habr.com/ru/users/SIISII/publications/articles/)
Я бы постоял рядом.
Интересно, на сколько реально восстановить процессор по схемам ? Деталей в магазинах сейчас в избытке, платы заказывать в Китае стоит копейки. Вот с софтом что делать - не понятно. Ленты есть в музеях, но читать их не на чем. Да и считаются ли ?
Софт как раз есть на ПК -- не всё, но довольно многое. А вот схем, по большей части, нет вообще. Из найденного наиболее полный набор оказался на проц от ЕС-1020: примерно 3/4 функциональных схем и около половины принципиальных, плюс все технические описания "верхнего уровня", часть "нижнего" и полный текст микропрограмм, так что мою серию статеек по этой машине можно очень сильно расширить (когда-нибудь в будущем). На остальные ЕСки нет почти ничего подробного.
Ну почему, мой препод в университете (1993 год, он был аспирантом) умел в это. Сейчас ему слегка за полтос.
Если человек долго не занимается каким-то делом, то знания и навыки выветриваются очень быстро. Особенно в современном мире где требуется постоянно изучать что-то новое. Ресурс головного мозга ограничен.
Я работать начал в 91-м в качестве оператора, эдакий юнга на вычислительном центре - принеси-подай отмонтируй-примонтируй. Неоднократно наблюдал как загружают ЕС-1066. Но смогу ли я запустить такую машину сейчас дай мне в руки все инструкции ? Скорее всего я даже питание ей подать не смогу, не говоря о том, чтобы диагностировать проблему со сбоящим накопителем или контроллером каналов, или памятью - что очень часто случалось с этими динозаврами.
Ваш тезис абсолютно понятен и имеет право на существование, но в свою очередь отмечу, что все же существует и существенная разница между "юнгой принеси-подай", "неоднократно наблюдал" и "работал самостоятельно, в том числе абсолютно самостоятельно в ночные смены", "перезапускал после сбоев" и "диагностировал проблемы с накопителями, контроллером каналов и памятью".
Ну, я, хотя и был, с одной стороны, "юнгой" (в 17 лет устроился на ЕСку), с другой, быстро стал де-факто программистом, а отчасти и электронщком (по процессору). Понятно, что интимные подробности за давностью лет забылись, но восстановятся быстро, если вдруг нужда возникнет. Ну а если б сохранился не только проц, но и основная дока на него -- вообще никаких проблем.
У вояк тоже ничего не осталось, они ж не дураки - золото хранить. И им тоже компы нормальные нужны были еще лет 30 назад, а денег нет. Вот и. Реальных рабочих машин не осталось и у них.
Но при наличии денег и документации можно воссоздать с нуля. Почему бы нет? Дорого и долго. Но реально.
Сейчас вопрос в сторону эмуляции. Считывании программ с сохранившихся лент. И сохранении литературы.
Почему только на закрытом телеграм канале, а не на открытом форуме. Как уже задрали эти телеграммщики!
Форум стоит денег.
Миллионы, наверное...
Зато в закрытом канале фиг чего найдешь потом. Да и сейчас. С точки зрения сохранения информации - это наименее удобный вариант.
Совершенно верно. Все эти каналы в чатах убивают поиск и ограничивают распространение информации.
Вот я типичный "мимо крокодил", дай думаю загляну на огонек, посмотрю чем люди занимаюся и хрен-то там.
Вообще, есть близкотематический форум
http://www.s390soft.ru/forum
И на форуме "Полигон Призраков" есть профильная тема.
А вышеупомянутая группа исторически появилась как тематическое ответвление телеграмм-группы по БЭСМ-6, поэтому тоже в телеграмме. Плюс телеграмма во встроенном хранилище файлов. Речь идёт не о долговременности или надёжности, а именно простом процессе выкладки. Литература, кстати, понемногу сканируется и выкладывается на общедоступные сайты. Фотографии же... пока жива телега, живы и фото. На многих форумах ныне тексты есть, а ссылки на фото давно умерли.
Телега умрет и утянет с собой абсолютно всю накопленную информацию. Либо её ограничать по скорости так же как Ютуб, до полного нуля. Нужен Git репозиторий.
В настоящее время "обработанные" книги-журналы хранятся тут http://oldpc.su/pc (раздел Библиотека)
Спасибо. Там в библиотеке есть файлик с номенклатурой ЕС ЭВМ, в нём указано сколько машин (изделий) данной номенклатуры было выпущено. Если просуммировать, то получаются гигантские цифры. Куда всё делось ? Вопрос риторический конечно же.
Утилизировали большую часть и до сих пор утилизируют. Периодически на Авито всплывают части машин из-под ножа. Что не уничтожили до сих пор в консервации, видел много фото в стиле "оборудование в пыльном углу". Когда у владельца доходят руки, уходит на утилизацию (или в музей, как щас происходит с одной из ЭВМ), иногда "подъедаются" своими же сотрудниками. А какие-то машины стоят ухоженные (но не факт, что рабочие и эксплуатируемые). Взять тот же НИИИТ в Твери
Умерли ссылки на фото, которые пользователи зачем-то загружали не на форум, а в файлопомойки, действительно они сдохли. Но те, что загружены локально обычно "в порядке".
Правильно, но для этого нужна "культура загрузки" или автоматические загружающие системы, а главное - место на сервере, а часто и сам сервер. У каждого решения есть плюсы и минусы. Мне лично форумы нравятся больше, в первую очередь из-за возможности индексации, но исторически группа родилась в телеграмме, как "филиал" группы по БЭСМ-6, для разделения обсуждений (почему "родитель" был в телеграмме я не знаю, я не его создатель) и никогда не стремилась стать массовой. Специально, однако, тоже не прятались. Возможно, людей смущает в названии словосочетание "по популяризации", но это тоже пришло от родителя БЭСМ-6.
Есть ряд профильных форумов по электронике (Electronix, Радиокот и т.д.), почему бы там не создать отдельный раздел ? Там уже много людей грамотных, даже есть те кто видео ЕС ЭВМ.
Мне еще нравится Github где в issues часто обсуждают проблемы со ссылкой на конкретный номер строки в файле. Это очень удобно. Сделали бы общий репозиторий с материалами по теме на Gitflic или Github и там же вели обсуждение. Но нет, мы спрячемся в телеграм канальчик, чтобы нас никто не видел.
Ну, на гитхабе нельзя по политическим причинам: мало ли, обрубят нахрен интернет (ну или МС решит позакрывать -- тем более, что могут иметь место формальные нарушения авторских прав и т.п.). Но вообще, правильно было бы, конечно, иметь нормальный форум или нечто в этом роде. Но решать не мне :)
Есть же российский Gitflic.
Github хорош тем, что любой желающий может держать у себя на локалной машине полное зеркало репозитория, работать с ним локально и синхранизировать с публичным. А в случае опасности быстро поднять Gitea и развернуть новое публичное зеркало. Складывать информацию в Git репозиторий это великое достижение Человечества. Очень плохо, что большинство электронщиков привыкли к виндузне и неприемлят коммандную строку, и отношение к Git у них соответствующее.
Есть бесплатные форумы. Достаточно погуглить. Например, mybb.ru
580-я использовалась, в частности, в польских терминалах СМ-7209 -- как по мне, лучшие СМовские терминалы были.
Ну а команды -- это от используемой ОС зависит; достаточно широко использовались, как минимум, RSX-11M, RT-11 и Уних -- как в оригинальном виде, так и клонированные и переименованные.
У них - "УНИХ", а у нас - "РАФОС"! ©
это да. помню меняли там ОС с како-то нашей на оригинальную. А нас на них учили оригинальному Паскалю... но на финишной стадии обучения мы грязно хакнули процесс- получив, кто у родителей на работе, а кто и дома доступ к Borland Turbo Pascalна 86 или 286 машинах. там всякие задания с массивами и строками гораздо проще делать было...
Эх, сопрягали когда-то СМ1420 с Корветами и СМ-1800. Можно было работать терминалом, можно "эмулируя терминал" отправлять готовые тексты туда-сюда...
Там довольно интересная история. 486SX из первых партий - по сути "нормальный" 486DX, но с бракованным сопроцессором. Просто, чтобы не отправлять в recycle bin ещё могущие как-то поработать кристаллы, их корпусировали как 486SX, где сопроцессор задействован не был. С 487DX ещё интереснее, по сути это не сопроцессор, а полноценный камень, при втыкании которого штатный SX отключался.
Вы еще скажите что аппаратную поддержку виртуализации придумали не Intel c AMD для x64 а IBM (еще до того как Intel вообще создала процессор хоть для чего то) :)
Ну дык IBM и придумала, коммерческие поставки VM/370 -- с 1971-го. Ну а виртуализация на ПК -- до сих пор жалкое подобие левой руки (с), в первую очередь, из-за фантастически кривой архитектуры что 8086/IA-32/AMD64, что ПК в целом.
А можно привести пример не кривых архитектур, для несведущих? Или ссылку на статью для ознакомления. Чисто из любопытства.
Совершенно прямых в природе не существует и вряд ли существовать может (из-за противоречивости требований). Но намного более прямые, конечно, имеются -- в частности, та же Система 360 и последовавшая за ней Система 370, про виртуализацию на которой здесь говорилось. DECовские PDP-11 (как по мне, лучшая 16-разрядная архитектура в истории), VAX-11 (вероятно, лучшая 32-разрядная система команд -- но системная архитектура, в общем и целом, хуже IBMовских мэйнфреймов), микропроцессорные -- Z8000, 68000, классический ARM... Везде есть свои странности и ограничения, но в целом все они -- весьма стройные архитектуры без серьёзного количества костылей и тем более откровенных уродств. Ну а 8086 -- прямая противоположность; кажется, Интел смогла в нём собрать все грабли, какие только возможно, а потом ещё добавила новых в 80286 и расширила их в 80386.
Интел смогла в нём собрать все грабли, какие только возможно
И в итоге захватила мир и обанкротила почти всех конкурентов. При том что первый SPARC был создан умнейшими гуру, которые нам сейчас впаривают RISC-V, и в тестах показывал производительность раз в 10 быстрее своего "однокашника" 80386 на той же частоте.
Может, в Интел работали всё-таки не идиоты, а ровно наоборот? И то, что вы считаете граблями, были бизнес-преимуществами? Ну там, совместимость с предыдущими изделиями и вот это всё?
Одно другому не мешает. Техническое совершенство побеждает очень редко, поскольку пользователю, вообще говоря, плевать, что там под капотом.
А архитекторы в Интел -- именно что идиоты. Полные и абсолютные. Совместимость, кстати, придумали не они. Первыми пообещали совместимость в IBM -- в 1964 году, и своё обещание блюдут до сих пор. Можете взять прикладную программу, написанную в середине 1960-х для мэйнфрейма Системы 360, и благополучно запустить её на современном мэйнфрейме z/Architecture.
DEC тоже порядка 20 лет блюла совместимость в своей линейке PDP-11, и погубила её не красивая архитектура (настолько удачная, что к концу 1970-х она стала, пожалуй, самой распространённой архитектурой в мире), а полные и абсолютные идиоты в руководстве компании. Вместо того, чтобы превратить чрезвычайно удачную мини-машину в хорошую персоналку, для чего в 1980-е уже были технические возможности (даже мы в начале 1980-х смогли запустить в производство свои собственные микропроцессоры с этой системой команд -- сначала К1801ВМ1, потом ВМ2 и ВМ3), по всем статьям превосходящую ублюдскую IBM PC, они сделали машину, совместимую по системе команд, но специально совершенно несовместимую по периферии, чем исключили возможность использования штатных ОС и всей кучи ПО, уже наработанного за 1970-е и начало 1980-х, да ещё заломили за это поделие деньги как за самолёт. Естественно, с таким подходом оно провалилось. Минимашины продолжали производиться и продаваться ещё какое-то время, но, очевидно, рынку была нужна именно персоналка (ну или мэйнфрейм, но там уже безраздельно доминировала IBM)
"Взять современный мэйнфрейм z/Architecture" я не могу, немножко денег не хватает. На интел хватает, на IBM нет:)
Ну, и раз уж у вас все кругом идиоты, то почему вы такой бедный?:)
Виртуалки на z/Arch покупаются точно так же как любой облачный ресурс, хотя, конечно, по распространению до x86 не дотягивают в K тысяч раз ;/
А кто бедный - не знаю, IBM вполне себе процветает на потоке денег с линий Z и I и за счёт наработанного реноме. Вот работать с ними (включая и писать) это, да, особый скилл, там всё заметно иначе.
"вместо того чтобы превратить ... в персоналку..."
DEC работала на профессиональный рынок, в том числе рабочие станции, это в общем другие требования, и другой уровень цен, как ее погубили это отдельная тема, совет директоров сменил Ken Olsen, т.к. он был против увольнений людей, его знали и уважали как инженера, но поставили послушного, короче бухгалтера взяли верх совершенно не понимая, что лучшие работники просто уйдут, персоналки лепить из дешевых деталей не будут, когда это началось остановить было трудно,
заметим инженеры DEC, особенно работавшие с Ken Olsen, не очень похожи на инженеров IBM, другой стиль работы, и совершенно другой стиль руководства
Может, в Интел работали всё-таки не идиоты, а ровно наоборот?
Intel выжила за счёт процессора для IBM PC - в первый раз когда совсем уже падали в пропасть, за счёт госконтракта на ASCI Red - во второй. IBM PC - как открытая архитектура (IBM в итоге получила имя, но не доходы от неё). Это единственное, что их спасло. Microsoft пришла опять же на открытую архитектуру. Intel пытался самоликвидироваться много раз: iAPX432, Rambus, NetBurst, Itanium, попытка потом сделать ещё одну 64-битную ISA поверх x86... - но им всё время не давали. Продажники обеспечивали имя, а кто-то в руководстве оказывался достаточно умным, чтобы остановиться уже скользая в пропасть. Мне интересно, кто был в руководстве (вероятно, из основной троицы) таким кретином, пытавшимся голой рукой схватить звезду с неба - но это откроется, наверно, ещё лет через 20.
А подавляющее большинство их конкретных технических решений - ноль собственной разработки и всё максимально через зад. Именно за это и плач.
И таки да, где-то были не идиоты. Иначе бы Intel давно уже сдох. Но, таки, не в технической части.
Жду мемуаров...
DECовские PDP-11 (как по мне, лучшая 16-разрядная архитектура в истории),
Спорно, спорно. Почитал я про его ассемблер осенью - по мне, так 8086 бодрее.
Во-первых, надо не читать, надо писать :)
А во-вторых, сравните кодирование команд в PDP-11 и в 8086.
PDP-11, конечно, красиво - для человека. Но неэффективно. В недавнем треде с вашим же участием я об этом писал. Называть его "лучшей (16-разрядной) архитектурой в истории" очень поспешно.
Но для машины с первым годом выпуска 1970, пачкой революционных решений, выживших после и расползшихся на всю индустрию (как MMIO и NZVC флаги), это было грандиозно.
8086 был хорош для его условий (попытка сделать за три месяца быструю замену негодному iAPX432). Плохо то, что аж два момента возможности расширения - переход к 32 и 64 битам - Intel пролюбил с максимальной эффективностью пролюбления, имея все ресурсы для грамотного рассмотрения, что делать. Вот это уже однозначно вопрос качества их R&D и вообще технического руководства.
Вполне себе эффективно и красиво, и не только для человека. Компилятору тоже намного проще иметь дело с одинаковыми регистрами, а не с целой кучей, ни один из которых ни разу "общего назначения", как в 8086. Ну а что недостатки есть... Везде они есть, и среди 16-разрядных PDP-11 если и не лучшая, то одна из лучших -- а 8086 худшая вообще из всех, кажется.
Кстати говоря, не со всеми Вашими утверждениями в том посте я согласен. Например, что MOV меняет флаги, мне как раз нравилось, и я нередко этим пользовался. Хотя, конечно, 32-разрядный ARM в этом плане больше свободы даёт: там половина команд может изменять флаги, а может не изменять в зависимости от одного битика в коде команды.
Вот насчёт ADC/SBC спорить глупо -- но им банально не хватало разрядности команды, как не хватило и на полноценную адресацию для XOR.
А вот тамошний MMU вполне себе эффективен и очень прост в железе -- тоже немаловажная деталь. Не удивлюсь, если деление адресного пространства на 8 страниц по 8 Кбайт пошло из технических соображений: уже были быстрые статические ОЗУ организацией 16*4 бита, а соответственно, в четырёх микросхемах можно было реализовать 16 16-разрядных регистров -- по 8 для режимов пользователя и ядра (режим супервизора впендюрили уже позже и непонятно зачем). Делать "полноценную" систему с таблицами переадресации в памяти, как, например, в Системе 370 -- по-моему, для 16-разрядной машины это уже архитектурное излишество, и выбранное решение было вполне эффективным, пусть и не совсем безупречным.
Ну а 8086 как замена iAPX432... Лишний раз доказывает, что руководство Интел -- идиоты. Во-первых, нельзя складывать все яйца в одну корзину. Во-вторых, нельзя делать "процессор для Ады", когда сама Ада ещё только разрабатывается, и стандарта на неё нет. А в-третьих, не надо обладать послезнанием, чтобы понимать: основными "кормильцами" на рынке являются достаточно простые микропроцессоры, пользующие массовым спросом (тот же 8080, при всех его уродствах, оказался очень популярен). То, что в короткий срок смогли что-то слепить, делает часть инженерам, непосредственно разрабатывавшим схемы, но отнюдь не архитекторам этого уродства и, тем более, не руководству компании.
Кстати говоря, не со всеми Вашими утверждениями в том посте я согласен. Например, что MOV меняет флаги, мне как раз нравилось, и я нередко этим пользовался. Хотя, конечно, 32-разрядный ARM в этом плане больше свободы даёт: там половина команд может изменять флаги, а может не изменять в зависимости от одного битика в коде команды.
Пользоваться-то можно, но на практике оказывается, что мешает - поэтому в 8086 как раз MOV не меняет флаги. Если надо менять, то на это есть TEST. А в S/360 тоже не меняет, хотите менять - есть LTR :)
ARM, да, ещё дальше тут продвинулся. Не зря Intel в обещанном APX его тут косплеит.
Вот насчёт ADC/SBC спорить глупо -- но им банально не хватало разрядности команды, как не хватило и на полноценную адресацию для XOR.
Могли сделать и на двух регистрах в стиле 0065ds. Всё равно лучше, чем костыль, что сделали.
А вот тамошний MMU вполне себе эффективен и очень прост в железе -- тоже немаловажная деталь. Не удивлюсь, если деление адресного пространства на 8 страниц по 8 Кбайт пошло из технических соображений
Да вот на PDP-11 страницы слишком крупные, а на VAX слишком мелкие. Баланса нет.
Про iAPX432 тут бы, конечно, устроить каким-то образом честные интервью у руководства. Но Гроув уже ушёл на поля вечной охоты, а остальные вряд ли расскажут...
X86 ISA, конечно, ужас, но это минимально связано с виртуализацией. Фактически, для полноценной виртуализации без Intel VT-d или AMD SMX не хватало правильной обработки нескольких команд - это можно было и залечить (сделать новый флажок где-то в управляющих регистрах).
Но это уже было неадекватно. Виртуализация эффективного типа требует или комбинации двухэтапной трансляции адресов и теневых регистров - что сделано в обеих x86 реализациях, в AArch64, в RISC-V и так далее - или паравиртуализации с заметной поддержкой со стороны гостевой ОС - а это уже путь 370-с-потомками. (Паравиртуализация может быть и при современном аппаратном движке, но потребность в ней уже заметно меньше, в основном для I/O). Тут больше вопрос, почему оба основных производителя x86 так тормозили с тем, что могло быть сделано лет на 10-15 раньше... но AMD был слаб, а Intel занимался глупостями, видимо, поэтому и не сделали.
Сейчас же имеем раздельные комплекты управляющих регистров для хозяина и гостя и два уровня трансляции - и этого достаточно, чтобы получалось что-то действительно неплохое по эффективности. И то - вон в AArch64 начиная с 8.3 добавили nested virtualization support.
Ну, речь-то о том, что ИБМ всё сразу сделала принципиально правильно на уровне архитектуры, чем и дала возможность создания СВМ без какой-либо специальной аппаратной поддержки.
Кстати говоря, думаю, что тогда -- в 1970-х -- такая поддержка и не очень-то требовалась. Без неё будут временами сильно тормозить гостевые ОС с виртуальной памятью, но не стоит забывать, что множество пользователей мэйнфреймов IBM тогда ещё сидело либо на OS/360 MVT/MFT, либо вообще на DOS/360, и виртуализация позволяла им перенести на один мощный мэйнфрейм работу, которая раньше выполнялась на нескольких ранних слабых моделях. Ну а поскольку эти системы не имели своей виртуальной памяти, дополнительных накладных расходов их перенос в СВМ не создавал.
Про гостевые MFT/MVT согласен. В доке VM/370 явно сказано "если вижу систему с base control (максимум один CR0 трогается), то всё просто, иначе включаем тяжёлую артиллерию". Для обстановки на x86 такое не годилось, все виртуализуемые системы уже сами были с пейджингом.
А вот правильно или нет и сейчас оставаться без двухэтапной трансляции - вот тут основной вопрос. Мне кажется, она бы таки многое облегчила. Но тут уже вопрос больше психологический и коммерческий. Какая-нибудь Microsoft виртуализацией Windows не очень довольна, потому что фиг его знает как лицензию трекать. А игра, особенно с защитой, тем более. А в мире SystemZ, если знаешь, что даже верхний уровень наверняка виртуализирован за счёт LPAR manager, бечь некуда, надо сотрудничать.
PDP-11, VAX, Alpha AXP
Увы.
PDP-11: сумма тут. Плюс к тому виртуальная память системы "взгляд из подводной лодки через перископ" (в пространство в до 64 раз шире).
VAX: чудовищное количество сверхусложнённых команд со сложной логикой, которые старались минимально использовать - их нельзя было сделать быстрыми. (Соответственно, эпоху трансляции для out-of-order оно не могло пережить.) Тупой размер страницы (512 байт) и при этом плоский каталог, которым было неудобно управлять (или даже невозможно, если не находилось связного куска нужного размера).
Alpha: в погоне за RISC частично убили даже control flow dependency, надо было руками ставить барьеры. Чрезмерная зависимость от PALcode, медленного, там, где наоборот можно было загнать в железо. Тупейший подход к побайтовому и невыровненному доступу (даже в MIPS сделали лучше). Вообще такое впечатление, что Alpha сделали по принципу "посмотри на VAX и сделай наоборот".
X86 при всех странных решениях как-то сумел проскочить посредине между особо дебильными решениями (которые уходили во всякие Itanium, где и гибли).
Ну дык IBM и придумала
Как аппаратно сделать – наверное, да, IBM. Но концепция что они использовали – заимствована.
Program and Addressing Structure in a Time-Sharing Environment, https://dl.acm.org/doi/pdf/10.1145/321312.321313, University of Michigan, 1965
многопроцессорные да, а многоядерные?
Многоядерность и хардварные декодеры для видео, аудио, шифрования - те же самые MMX, Quick Sync Video, и др., про это в статье забыли упомянуть.
Про расширение адресации памяти я тут не совсем соглашусь - 486 уже был шагом вперед после 8-битной архитектуры и 16-битной архитектуры, то есть переход на 64-битную был ожидаем, а не чем-то суперновым.
Новое для x86 в процессорах 80486dx, несколько помню:
Интегрированный кеш первого уровня.
Умножение частоты системной шины/памяти для получения частоты ядра (DX2, DX4).
Встроенная поддержка вычислений с плавающей точкой.
Так, начнём вот с чего. 486 был моим первым процессором. Это было мажорство, но я не возражал. 100 мегагерц было достаточно всему. Игры шли вообще без каких либо тормозов. Тогда вообще мало что тормозило.
А теперь, реальные вещи, которые 486 нам принёс:
CMPXCHG - теперь сравнивать и перемещать данные между регистрами можно было атомарно, не надо было писать отдельные инструкции.
Встроенный математический сопроцессор. Больше не нужно было бояться операций с плавающей точкой.
Процессор работал быстрее скорости шины. Можно было получить ответ от АЛУ за один такт, там где 386 занимал два такта.
Была ещё кнопочка, которая переводила процессор из режима 66 мегагерц в режим 100 мегагерц. Это было необходимо, чтобы усмирить горячего парня, ибо некоторые ДОС программы выполнялись слишком быстро. А в GTA можно было играть чуть медленней, и игра шла приятнее, не так дёргано.
Короче, учился программировать на этой штуке. Мой первый компьютер. Шеффс кисс.
Кнопочка turbo повышающая частоту была на всех, начиная с 8088/8086, как раз потом, может быть даже и с пентиумов, от нее отказались.
Вообще-то кнопка Turbo была не для повышения частоты, а для переключения со стандартной частоты (это и был режим Turbo) на пониженную (без Turbo).
А зачем пониженная? Проходимость лучше?)
Например чтобы старый софт не вываливался в деление на ноль.
Стандартный модуль CRT используется во многих программах на Turbo Pascal. Но при запуске этих программ на современных компьютерах, оснащённых быстрыми процессорами, возникает ошибка "Деление на нуль"
...На процессорах, частота которых 200 MHz и выше, DX:AX, делённое на 55 оказывается больше 65535 и, поэтому, результат не может поместиться в AX. Происходит так называемое переполнение при делении.
https://jkfs.petrsu.ru/~yura/pyldin/yura/u_crt.htm
Программ было много, у которых были проблемы из-за намного быстрого процессора, чем в момент создания программы. Что-то времен 8086 наверняка могло некорректно работать, например игра идет намного быстрее чем следует.
Чтобы человечек в играх не бегал по экрану как бешеный (независимость от framerate'а на тот момент ещё не изобрели)
некоторые программы (в т.ч. игрушки) были завязаны на стандартную частоту XT.
Кнопка Turbo впервые появилась на клонах IBM XT 8088. BIOS у клонов был в значительной степени тянутый и содержал проверку на тактовую частоту из оригинала. Запуск производился на базовой частоте (вроде 4 МГц). После инициализации/загрузки BIOS нажималась кнопка Turbo.
Вы не читаете ветки, на которые отвечаете? Или вас сбила с толку ошибка в первом комменте?
из режима 66 мегагерц в режим 100 мегагерц
"TURBO key" (eng) = "Кнопка МЕДЛЕННО"(рус) ©
Тут нужно различать сам режим работы (с его индикацией светодиодом на корпусе) и кнопку.
Режим Turbo — это работа в полной скорости. Этот режим является режимом по умолчанию. Так его описывает какой-нибудь даташит того же 486:
Конкретная реализация кнопки могла различаться от корпуса и материнской платы. Иногда это был замыкающий контакт переключатель, который нажимался и фиксировался в нажатом положении, пока не нажать его повторно. При желании переключатель можно было подключить так, чтобы нажатое положение означало отключение режима Turbo. При отсутствии переключателя полагалось вместо него поставить на материнскую плату джампер.
В других корпусах и системных платах это была обычная кнопка, которая замыкала контакт и отключала режим Turbo, чем замедляла компьютер. Чаще всего получалось так, что кнопка Turbo отключала включённый по умолчанию режим Turbo, а не включала его.
Отказались от кнопки и светодиода действительно в начале эпохи «Пентиумов».
У меня на пне 120 была работающая кнопка "ло-хи". С соответствующим индикатором. И на многих материнках того времени была возможность подключать турбокнопку. Зачем оно было нужно, не знаю, разница почти не замечалась.
На следующем поколении пней уже такого не наблюлал, хотя кнопка на корпусе еще долго попадалась, просто была не подключена к материнке. Иногда ее использовали для замыкания какой-нибудь перемычки на материнке или плате расширения. Например, перемычки сброса настроек биоса (понятия не имею, зачем).
На моем пне 75 это была пауза. Ну скорее всего какой-то слип, но можно было остановить любую программу, даже дос, чаю попить, отжать кнопку и продолжить играть.
Индикатор был напрямую связан с кнопкой и "программировался" с помощью перемычек - что выставишь, то и будет показывается. А к материнке подключать эту кнопку было совершенно необязательно.
В каком-то компе видел, как её подрубили в разрыв пищалки.
Сопроцессор и на 386Dx был.
Отдельной микросхемой
Причём в случае с впаянным в плату основным камнем ещё больше похожей на процессор, как мы его представляем.
Забавно сейчас показать кому-то (из тех, кто "тройки" не застал) плату и попросить показать, где тут процессор.
Кстати, да, на части х86 архитектур, до того как осталось только двое, северный/общий мост был больше чем процессор, и/или процессор с ним образовывал многочиповое решение, размазанное между ними.
Например разные редакции Cyrix вплоть до Amd MediaGx, когда процессор и видеопроцессор с северным мостом размазывались в двух-трех чипах, т.к. реализация архитектуры у cyrix, ibm, ti, amd была различной.
Забавно у него кеш размазан по плате: область данных с одной стороны, возле BIOS и ОЗУ, а тэги внизу, промеж процессора и сопроцессора.
Я почему-то не открывая фуллсайз угадал где проц.
Но у меня прям дежавю т.к. моя первая мамака с 386 была очень похожа на эту, но на месте сопроцессора было пусто.
Есть такая штука, как RapidCAD в 386 гнездо. Там сопроцессор уже встроен. Видел чувака в ютубе, который ставил его на одну плату с сопроцессором Weitek (еще одно редкое чудо) - и таким образом, можно было иметь в системе уже два разных сопроцессора с разными системами команд (Weitek вроде бы не из серии x87 и требовал специальных драйверов), хотя и не одновременно.
Weitek был своеобразной, но очень интересной железкой )
CMPXCHG - теперь сравнивать и перемещать данные между регистрами можно было атомарно, не надо было писать отдельные инструкции
"Принёс нам" -- это кому? Сама подобная операция известна была задолго до появления 80486 и даже до 8086. В частности, она была реализована на (почти) всех мэйнфреймах Системы 370 (команды CS и CDS), а это начало 1970-х.
Старшие 386 тоже работали быстрее скорости шины. Собственно, шина была на 16 МГц, больше не удавалось выжать из стандартной памяти (ОЗУ). Чипы DRAM на 20 и 24/25 МГц в природе были, но были дорогие и редкие. Ещё точнее, между шиной и процессором часто ставили кэш-память (отдельный контроллер и отдельные чипы SRAM на материнской плате), но сами процессоры могли работать и без этого, с множителем внутренней частоты.
Собственно, даже старшие 286 работали быстрее шины, потому что у них почти напрямую была подключена шина ISA аж на целых 8 МГц.
Так если он был первым, вам было тяжело сравнить с тем, что было до 486 =)
Так, начнём вот с чего. 486 был моим первым процессором. Это было мажорство, но я не возражал. 100 мегагерц было достаточно всему. Игры шли вообще без каких либо тормозов. Тогда вообще мало что тормозило.
моя история, "плюсую" :) машина по тем временам отличная
Хотелось бы заметить, что страничная организация памяти - технологический костыль, а не какое-то преимущество. Позволяла адресоваться к большим адресам имея ограниченную по разрядности шину адреса. Цена вопроса - время операции. Адрес выставлялся в несколько заходов.
Забавно, что когда 4ГБ (32 бита) стало мало для всех, то сначала придумали именно РАЕ, как самое очевидное.
Что-то путаете, похоже. Перед PAE был ещё PSE36 и вот он был "вначале" костылём с 4MB страницами, где в свободных питах в PTE размещались старшие биты физ. адреса.
PAE пошло вторым и вот оно было уже полноценным решением, расширяемым на 64 бита.
Возможно. Просто я помню свои эксперименты с 16ГБ ОЗУ на Windows 7 x86. Там можно было активировать РАЕ (так было сказано в сопроводительной документации к хаку - РАЕ) через хак ядра и тогда система позволяет запускать несколько "тяжёлых" процессов в разных физических частях ОЗУ. Т.е., в отличии от х64 системы у тебя остаётся ограничение на 4ГБ на каждый процесс (включая DLL и аппаратуру), но таких инстанцев можно было запустить 4шт.
На это они оба, PSE36 и PAE, годились. Но PSE36 сложнее, это работало только на 4MB страницах, а это могло само по себе подпортить удобство системе. PAE сделано более традиционным (4KB базовая страница), зато физический адрес с ходу получался до 64 бит (дальше срабатывало уже ограничение конкретной модели процессора на его шине).
Вы таки путаете страничную организацию с сегментной. 16-битный 8086 мог работать с 1Мб ОЗУ именно за счёт сегментов (а 80286 - и с 16 Мб ОЗУ при тех же 16 битах адреса).
Забавно, что сейчас ситуация обратная. "Гражданские" 64-битные процессоры, как правило, ограничивают адрес 48 бит, серверные иногда поднимают планочку до ~52. Типа зачем тратить лишние транзисторы, если физического ОЗУ столько быть не может даже близко. Полные 64 бита имеют разве что PowerPC (НЯЗ)
Полные 64 бита в том или ином виде используются для реализации так называемых tagged pointers, когда в адрес зашивается "тэг", для увеличения безопасности работы с памятью (с помощью от железа, разумеется чисто софтовые реализации тоже есть). У intel - Linear Address Masking, AMD - UAI (Upper Address Ignore), и даже на каких-то ARM вроде было. Но для intel/amd это относительно новое.
UAI появилось в Zen4, совсем свежак. Аналог от Интела описан в 2020 году.
До этого все неиспользуемые биты были обязаны быть равными самому старшему биту (который всегда 0 для юзерспейса и 1 для ядра). И сделано это было именно, чтобы дать по рукам любителям потегировать указатели ценой потенциальной несовместимости с будущими процессорами.
В частности, дефолтная JVM, которая использует тегирование для сборщика мусора, выделяет под это дело 3 старших допустимых бита (биты 45-47), в которых хранит номер "поколения". Таким образом, они сами себе режут потенциальное адресное пространство в 8 раз, но считают это оправданным. А дальше вообще финт ушами: они мапят при помощи ОС виртуальное адресное пространство своего процесса на физическое 8 раз, чтобы все 8 вариантов адреса с тегами указывали на одну и ту же физическую ячейку памяти. В итоге, видя такие страдания, Intel и AMD сдались:)
С ветвлениями надо быть всё же поосторожнее. Если важна производительность, надо следить, чтобы ветвления были предсказуемы. Если же там по сути алгоритма вероятность перехода около 50%, то нужно думать, или как эту вероятность в какую либо из сторон сдвинуть, или же полностью отказаться от ветвления.
Навскидку пару дополнительных вещей:
-Появление дополнительных ядер с уменьшенным количеством электронно-реализованных команд, вследствие чего и потребляющих намного меньше энергии.
-Вследствие ошибки в транзисторной реализации операций с плавающей запятой и чуть-ли не банкротством из-за возможных рисков, что весь мир захочет поменять 'бракованный' процессор - Intel перестал быть чистым CISC процессором, а перешёл на смесь CISC и RISC, чтобы не все новые команды с помощью транзисторов делать, а использовать микрокод. Который можно удалённо и апдэйтить.
Строго говоря, микрокод у них был со времён 8086. И то же деление делалось микрокодом. А также всякие сложные адресации. Просто во времена 8086 этот микрокод был "захардкожен" в масочном ПЗУ - на кристалле тупо либо были дорожки, либо не были. Со временем это ПЗУ стало shadow, евпочя.
После ошибки с делением они сделали возможность этот микрокод апгрейдить из БИОСа или драйверов. В ПЗУ, разумеется, оставалась базовая версия.
Что, вот прям с самого 8086 микрокод, а не какого-нибудь 486? пруфы?
С 80286 более вероятно. Ссылку не дам, но такие вещи, как загрузка-выгрузка всех регистров при переключении задачи через task gate, выполнение команды loadall... - были в микрокоде.
Реально граница между микрокодом (микропрограммой) и схемным управлением не очень чёткая. Конечно, когда микропрограмма загружается в ОЗУ, как это было, скажем, на ЕС-1035 и ЕС-1045, сказать можно чётко: микропрограмма. Если она намертво зашита в ПЗУ, такое сказать уже сложней: не поменяешь же, не забравшись внутрь проца. А если на ПЛМ (вроде, так было сделано в нашей серии К1801)? Это, по большому счёту, уже не отличается от схемного управления, где управляющие сигналы вырабатывались логикой -- но за счёт более "стройной" структуры блока управления, не "размазанного" по 100500 триггерам, управляющим друг другом с помощью столько же "размазанной" логики, выглядит ближе к микропрограмме...
Реально граница между микрокодом (микропрограммой) и схемным управлением не очень чёткая.
Есть такая проблема, да. Вот например таким примером дополню - это уже микропрограмма или ещё просто логика, которая для удобства уложена в ПЗУ?
(Мне тут показателен термин "секвенсор".)
Но, если речь идёт о визуально отделяемом автомате исполнения отдельных команд процессора - даже если программа сидит в ПЗУ, это таки микрокод.
Дык вот же кристалл
После ошибки с делением они сделали возможность этот микрокод апгрейдить из БИОСа или драйверов. В ПЗУ, разумеется, оставалась базовая версия.
Тут чуть не так. В случае FDIV, например, или аналогичной проблемной команды могло делаться и две версии железа, с переключением между ними флажком. А вот дальше вопрос, как этот флажок реализовывался: мог идти во внутренний регистр, а мог патчем, который накладывался на микрокод - какая именно из команд выполняется.
Они таким образом несколько раз пытались сделать TSX и деактивировали... кажется, так и не запустили (хочу послушать, почему. У ARM получилось, а у Intel - нет? в чём сложность?)
Shadowed ПЗУ на ОЗУ - да, стандартный подход.
del, 504 timeout
Мне кажется, что про спекулятивное выполнение написано не совсем правильно. Это больше про выполнение выполнение операций, которые потом могут оказаться не нужны. Например, вычислить обе ветке if до проверки условия. Поправьте, если я не прав.
Ага, спасибо, поправил
Спекулятивное -- да, выполнение в предположении того, что оно действительно понадобится. Хотя обычно связано это с предсказанием ветвлений: куда предсказало, ту ветвь и выполняем, а потом либо подтверждаем выполнение, либо отбрасываем в зависимости от того, правильным ли было предсказание.
Еще появилось гибкое управление энергопотреблением, до этого оно, конечно - тоже было (i80186, 386SL, и незабвенная команда HLT), но сейчас можно управлять частотами, напряжением, задавать лимиты по TDP.
С частотами иногда и хитрее было: у некоторых процессоров (ещё не микро) переменная длина такта. Скажем, у проца СМ-1420 одна микрокоманда выполнялась либо 200, либо 300 нс (задавалось в самой микрокоманде и было связано с тем, какие микрооперации нужно было выполнить; в частности, если выполнялось обращение к шине, всегда использовалась длительность 300 нс). А у проца ЕС-1035, микроархитектурно содранного с IBM 370/145, если склероз не изменяет (основная масса советских ЕСок были полностью своими разработками, но конкретно в этой только окончательная реализация на уровне микросхем была своя), было 3 или 4 длительности такта в зависимости от вида микрокоманды, а микрокоманды обращения к памяти, кажется, вообще два такта выполнялись, причём разной длительности. Но подробности не помню уже; если доживу (надеюсь) до написания статейки по этой машине -- тогда всё распишу подробно.
Попробовал оценить максимальную эффективность SMT/HT с помощью пакета stress-ng.
Мой процессор 4C/8T, 2011 год выпуска.
Открыл два терминала, в первом пишу:
$ taskset -c 0,2,4,6 stress-ng --cpu-method int64 --cpu 4 --metrics-brief --perf -t 30
Жду 30 секунд; результат: 4871924 bops
Во втором пишу:
$ taskset -c 1,3,5,7 stress-ng --cpu-method float128 --cpu 4 --metrics-brief --perf -t 30
Жду 30 секунд, результат 47903 bops
Затем запускаю одновременно (почти), жду 30 секунд, результат 4815118 и 46985.
Получается, что в идеальных условиях эффективность SMT может превышать 98%.
В 80-х годах использовались 8-битные процессоры
16-битные были скорее более массовыми.
но которые были введены в x86 еще с начала 80-х, это страничная организация и виртуальная память
Не было там страничной памяти - была сегментная. Страничная появилась в i386. И виртульная память - это термин больше на уровне операционной системы.
но в 90-х годах с появлением процессоров Intel с поддержкой технологии Hyper-Threading (HT) появилась возможность выполнять два "потока" на одном физическом ядре.
P4 с гипердрейдингом появились в 2002 году
Благодаря HT и, позднее, многим физическим ядрам в процессоре, мы смогли выполнять несколько программ или частей программы физически параллельно, снижая время ожидания. Например, в играх это используется для разделения логики, обработки звука, физики и рендеринга, где каждое ядро или поток может быть занят своей задачей.
Игры тогда (до распространения нормальной двухядерности) были почти все однопоточные, преимущество HT раскрывалось только в приложениях, где распараллеливание было сделать проще. Например - перекодирование видео.
Позже объёмы памяти стали настолько велики (гигабайты и терабайты оперативной памяти), что маленького кэша уже не хватало для охвата всей доступной памяти. При работе с большими объёмами данных происходила "вытеснение" данных из кэша, и алгоритм начинал работать даже медленнее, чем при доступе к основной памяти. Появились кэши второго и последующих уровней, чтобы с одной стороны обеспечивать доступ к большому объему оперативной памяти, а с другой — не быть слишком медленными и успевать "кормить" кэш первого уровня.
Автор вообще знает как аппартно реализуется и работает кэш? Как-то не похоже.
Спасибо, поправил
И даже более того.
Вторая половина 80-x это уже эпоха 32-bit: i386, i486, SPARC V7, ARM2/ARM3, Motorola 68020/68030, MIPS R3000, Zilog Z80000, NEC V60. Это всё 32-bit CPU из того времени и наверняка не полный список.
Подозреваю что уже тогда были и интегрированные FPU, кэши и даже brach prediction: все это было, например, у IBM POWER1 который вышел в 1990 и я сомневаюсь что он был прям первым таким.
Вот многоядерность и SMP появилось сильно позже. Самый конец 90-x/начало 2000-x, да.
И ведь перечисленное Вами -- микропроцессоры. А ведь никуда не делись процессоры на рассыпухе, которые и 32-разрядными были, и вещественной арифметикой располагали, и прочая и прочая (в частности, многопроцессорность; ну а многоядерность -- это просто несколько процессоров на одном кристалле, что концептуально не отличается от нескольких процов, каждый из которых занимает пару отдельных шкафов, но которые входят в состав одной машины).
Я про аппартную реализацию и почему вообще
Как раз подтверждение, что на железном уровне понимания - нет. Это как большинство современных программистов знают о всяких объектах, шаблонах, интерфейсах, и при этом не разбираются в ассмеблерном коде.
Позже объёмы памяти стали настолько велики (гигабайты и терабайты оперативной памяти), что маленького кэша уже не хватало для охвата всей доступной памяти
Объем кэширумой памяти никак не зависит от размера кэша. Он зависит от длины адресного тэга (+ битность смещения в странице кэша). Для примера могу вспомнить кэш память на материнских платах (времен P1), которая хоть и была большего объема, чем в процессоре, но могла буферизировать меньший размер памяти, чем позволяла установить материнка.
Появились кэши второго и последующих уровней, чтобы с одной стороны обеспечивать доступ к большому объему оперативной памяти, а с другой — не быть слишком медленными и успевать "кормить" кэш первого уровня.
Кэши старших уровней появились потому что аппаратные ограничения повышают задержки кэша при росте его объема (не считая сложностей размещения больших объемов кэша на одном кристелле с процессорным ядром).
Почему увеличение размера увеличивает время доступа, можете раскрыть? Современный L1 кэш наборно-ассоциативный - ассоциативный между банками и прямое отображение внутри банка. Условные 32Кб, например, могут быть 8 банков по 64 строки по 64 байта. Увеличивать количество банков дорого, потому что для каждого нужно отдельно проверить попадание. В чем ограничение на увеличение размера банка? Независимо от размера мы читаем только 1 строку, адресуем её по части адреса памяти, физической или виртуальной. То что SRAM занимает много места и потребляет много энергии при работе на частоте ЦПУ понятно, почему нельзя сделать банк более 4к непонятно.
можно сделать банк и более 4 К и кэш L1 побольше. Все зависит от того будет ли в Вашем дизайне кэш L1 узким местом , т.е. в нем будет критический путь определяющий частоту. Можно сделать много мелких банков, каждый из которых влезет в цикл, но после них придется добавлять произвольную логику и уже из-за неё может испортится частота. Опять же слишком большая ассоциативность это раздувание площади L1, а это опять проблема с циклом. Это из моей практики.
Дешифратор адреса в банке: либо быстро, но большой объем логики (плюс сложности с разводкой на кристалле), либо каскадно, но больше задержки. С ассоциативной частью примено то же самое. Конкретно по размеру базового банка - тут скорее просто подобран/рассчитан оптимальный объем.
Растут длины линий связи, а значит, не только "прямолинейное" время распространения сигнала, но и паразитные индуктивности и ёмкости. Это сильно ограничивает возможность увеличивать геометрические размеры схемы, а начиная с определённого предела потребует лепить размножители (повторители) сигналов и т.п. промежуточную логику, которая тоже вносит свои задержки. В этом плане вычислительные блоки сильно проще: там связи почти всегда локальные, между близко расположенными транзисторами, а число приёмников у каждого источника невелико. Ну, это грубо, конечно, но все эти факторы и ограничивают возможность увеличения объёма кэша без снижения его частоты.
У банок SRAM(вообще у любых но у SRAM в частности тоже) есть ограничение по глубине/частоте. А поскольку у вас ширина задана - то фактически ограничение на максимальный объём банки. Это во-вторых.
Во-главных же: вы просто не разведёте (на этапе физ-дизайна) достаточно большой кэш за достаточно маленькое число тактов.
Чисто теоретические модели - могут дать логарифмическое время доступа от размера, но на практике они слабо применимы.
Ну и в итоге вы балансируете (на своём наборе нагрузок):
cache_hit_prob * cache_hit_time + (1 - cache_hit_prob) * cache_miss_time.
Суперскалярность еще.
Суперскалярность появилась в 1960-е.
Много чего описанного в статье появилось до 486.
Тут же вроде разговор конкретно про х86, суперскалярность в котором появилась в пентиуме.
Из всего описанного в статье - вроде бы только TLB и SIMT появились не в 1960-1970.
TLB имелся во всех IBMовских мэйнфреймах с виртуальной памятью -- т.е. почти во всех машинах Системы 370, появившейся в 1970-м. Насчёт SIMT не понял, если честно. Если речь о SIMD, то в СССР в самом начале 1980-х уже была супер-ЭВМ ПС-2000, которая, по сути, SIMD. В Штатах первый Cray появился в 1975-м
можно конечно понять что создатели ПС-2000 ее супер ЭВМ называют, но объективно тактовая частота 3MHz это немного, Cray XMP в 1983 году на 105MHz работал, что касается SIMD, то этим много занимались в 1960х (см. Slotnick - ILLIAC), а в системах реального времени еще раньше (1958)
Всё-таки SIMT.
Каким-то пунктом идёт GP-GPU.
GP-GPU это fine-grane-multithrading + Predicated-instructions + SIMT. Из всего этого - только SIMT появились достаточно поздно, вроде в 1980.
Про TLB vs IBM 360 спасибо. С памятью знаком сильно хуже, чем с вычислительной частью.
П.С.
SIMT vs SIMD difference.
https://forums.developer.nvidia.com/t/simd-versus-simt-what-is-the-difference-between-simt-vs-simd/10459
Почитал вику про этот самый SIMT. Не сказать, чтоб какие-то кардинальные отличия от обычного SIMD были:
The key difference between SIMT and SIMD lanes is that each of the SIMT cores may have a completely different Stack Pointer (and thus perform computations on completely different data sets), whereas SIMD lanes are simply part of an ALU that knows nothing about memory per se.
Такое, в общем-то, и на обычном SIMD сделать можно, если подготовить данные должным образом.
Может меня слегка подводит мой маразм, но в PS3 не было никакого 8-ядерного процессора, как бы там ни фантазировали об этом сонибои. Там был одноядерный CPU с HT (или 2-ядерный без HT, уже не помню). Плюс семь сопроцессоров, объединенных шиной токен-ринг (привет IBM). Программистам игровых движков пришлось очень сильно стараться чтоб всё это заработало с приемлемой скоростью. В этот же момент у Бокса был честный 3-ядерный CPU.
Ну они были, их было семь, да с ними было сложновато работать, и похоже только сами студии сонивские и могли полноценно при поддержке спецов. Формально они могли делать очень многое, так например в XBlades туда были вытащена физика, звук и партиклы. Сони очень продвигали эту технологию на старте
Не обязательно сониевские студии. Были попытки запускать на нем научные расчеты, у меня даже был доступ к какому-то исследовательском проекту на эту тему в середине 00, но фокус интересов быстро сменился и ничего путного тогда сделать не успели.
Это я к тому, что не было 8-ядерноого процессора в том понимании, как про это думают сейчас, типа какой-нибудь Intel i7-10700.
У PS3 одноядерный двухпоточный PowerPC и 8 SPE (из которых один отключён производителем в процессе отбраковки, и ещё один зарезервирован системой).
Помимо SIMD‑ов есть ещё куча расширений типа AES и Bit manipulation.
И ещё стоит упомянуть аппаратную виртуализацию.
Команды для манипуляций битами точно были ещё в VAX-11; шифрование одной командой есть и постепенно расширяется (по мере появления новых стандартов) в z/Architecture. Аппаратная виртуализация Системе 370 и её последователям, включая z/Architecture, не обязательна: там сама архитектура достаточно прямая для создания виртуальных машин. Собственно, VM/370 и работала изначально на самых обычных мэйнфреймах Системы 370; поддержка виртуализации, имеющаяся во многих процессорах этой и последующих архитектур, лишь ускоряет работу виртуальных машин, но не является безусловно необходимой -- в отличие от интеловского уродства.
Статья посвящена конкретно эволюции x86.
Ну строго говоря VMware/Connectix сначала работали без аппаратной поддержки виртуализации. Какими хаками с бинарной трансляцией - вопрос отдельный.
Ну, настоящей виртуализации (не программной эмуляции чужой системы команд) без железной поддержки на IA-32 быть не может из-за наличия команд, которые являются непривилегированными, но работают с системной информацией (считывают содержимое каких-то системных регистров, если склероз не изменяет). Соответственно, либо делать неполноценную "обычную" виртуализацию, которая работать будет лишь в случае, если гостевая ОС эти команды никогда не использует (а соответственно, не требуется их перехватывать и эмулировать средствами гипервизора), либо как-то разбираться с машинным кодом гостевой системы перед его выполнением, обнаруживать такие команды, заменять их чем-то, вызывающим прерывание... Ну, думаю, Вы поняли. Оба подхода не дают 100% надёжности работы, а второй, к тому же, очень сложен и временами вызывает сильные тормоза. Ну а как делали эти самые VMware/Connectix -- понятия не имею, честно говоря.
либо как-то разбираться с машинным кодом гостевой системы перед его выполнением, обнаруживать такие команды, заменять их чем-то, вызывающим прерывание...
Вы сейчас описали разницу между ванильным command.com из DOS/Win9x и его заменителем cmd.exe из WinNT. Все привелегированные вызовы (в том числе и сервис DOS) эмулируются через исключение.
Вы сейчас описали разницу между ванильным command.com из DOS/Win9x и его заменителем cmd.exe из WinNT. Все привелегированные вызовы (в том числе и сервис DOS) эмулируются через исключение.
Я не вижу, в чём тут аналогия, но с виртуализацией сильно сложнее.
1. Пачка команд: SMSW, SLDT, SIDT, SGDT, STR - могла быть выполнена в user mode (IOPL=3). С этим нельзя виртуализировать режим супервизора напрямую: он мог, например, через SMSW убедиться, что реально работает в защищённом режиме вместо реального. К чести Intel, они сделали, что при CR4.UMIP==1 на эти команды срабатывает защита. Не вижу, в каком процессоре они это сделали (текущий SDM не упоминает версию); CharGPT сказал, что это только с Skylake (Corei 6е поколение), то есть очень поздно (сильно позже введения собственно VMX).
То есть до появления VMX надо было для гарантии защиты от такого транслировать каждую страницу, разбирая по командам. При этом учтите, что код может быть самомодифицирующийся - и гипервизор должен перехватывать эти изменения.
2. Регистр Flags содержит IOPL. Команда PUSHF должна сохранять его полностью. Вот и снова светим значением поля. Кроме IOPL, туда же RF, IF, VIF... Причём в отличие от пункта 1, это не регулируется и сейчас. Значит, аналогичные PUSHF тоже перехватывать, снова без бинарной трансляции не обойтись.
И это я явно ещё не все случаи вспомнил, только самые видимые на поверхности.
Итого, я очень сочувствую тем ребятам из VMWare и прочих, которым пришлось всё это костылять ;[
А вот если бы они хотя бы попробовали ввести соответствие даже тому примитивному критерию Попека-Голдберга, который был опубликован в 1974 (ещё 8086 не было в проекте), а придуман явно раньше - "Any sensitive instruction must be privileged" - то тут проблемы бы не было. Даже с подпорками в виде shadow paging, как в SystemZ, оно бы уже работало, и пошёл бы вопрос о том, как сделать эту работу быстрее, а не как сделать её в принципе.
Поэтому VMX (Intel) и SMX (AMD) стали глотком воды в пустыне.
"Any sensitive instruction must be privileged"
В том то и проблема, что изначально не ясно, какие инструкции потенциально привилегированные. Потому что есть инструкции явно привилегированные, есть инструкции явно не привилегированные. А есть такие, которые могут влиять на защищённый режим только в определённых условиях.
В том то и проблема, что изначально не ясно, какие инструкции потенциально привилегированные.
Это в каком смысле-то? В спеке ISA должно быть сказано, какие привилегированные.
Для соответствия PG важно выяснить, какие из них "sensitive", то есть затрагивают те аспекты режимы работы компьютера, которые относятся к управлению доступом. А вот это выясняется достаточно легко: есть чётко очерченный набор параметров. Собственно режим (kernel/user). Защита памяти. Весь I/O, по умолчанию (поэтому его команды должны быть привилегированными). Регистры/память обработки прерываний/исключений. Общее состояние (типа, полный останов относится => команда такого останова должна быть привилегированной). И так далее. Сильная зависимость от конкретной архитектуры, но понимание простое и однозначное.
И вот случай 80286, когда SMSW позволяет даже просто читать, в каком режиме работаем - уже подпадает под нарушение. Нельзя позволять читать режим, не имея привилегий - или же команда чтения должна показывать всегда фейковое значение, если это не спец. команда "прочитать имея на то полные права" (как в 386 то же самое делается чтением CR0).
А есть такие, которые могут влиять на защищённый режим только в определённых условиях.
Тогда или надо разделять их на разные команды, или как-то управлять этими условиями, так, чтобы не позволять лишнего доступа.
Проблема x86-до-VMX/SVM в том, что не просто не могли чего-то ожидать и понять - могли, но сначала бездумно игнорировали, а потом почему-то тормозили с лечением.
Это в каком смысле-то? В спеке ISA должно быть сказано, какие привилегированные.
Ну, например:
PUSH #NUMBER
RETКазалось бы, 2 не привилегированные команды, а активно юзаются при уязвимостях переполнения буфера. Это один из слабых случаев. Есть и посильнее и более не явнее.
Никаких проблем с виртуализацией эти команды не создают.
То, что вы описали, не имеет никакого отношения к понятиям привилегированных и чувствительных команд. Иначе надо было бы вообще любые действия считать такими - они же получают данные, из которых генерируются другие данные, в которых могут быть ошибки, которые приведут к уязвимостям. Это несерьёзный подход, и поэтому так никто в здравом уме не считает.
Это несерьёзный подход, и поэтому так никто в здравом уме не считает.
Конечно не считает. Но те, кому это надо, использовать это при этом не прекращают. Повторюсь, приведённый мной пример самый наивный. По факту там есть гораздо более извращённые методы. Были даже абьюзы системы внеочередного выполнения инструкций.
Иначе надо было бы вообще любые действия считать такими
А изначально они все такими и были. Защита появилась именно после появления необходимости в многопоточности. Чтобы какой-то из потоков не мог убить (или повредить) хотя-бы системный (друг друга пусть бьют, это не так важно), который и должен был обеспечивать стабильность и функциональность системы. Посмотрите, столько колец (уровней) доступа у х86. А та же моторола обходилась всего 2мя: супервизор и юзер и отлично себя ощущала в разных машинах.
PS Я не имею цели спорить на эту тему. Я лишь хотел сказать, что чем сложнее становится процессор тем сложнее предвидеть все случаи, которые обеспечат несанкционированный прямой или косвенный доступ пользовательскому коду. Особенно, когда узлы этого процессора разрабатываются вообще разными командами. Отсюда и уязвимости, которые обнаруживаются спустя десятилетия, причём некоторые только после того, как появится благоприятное для этого программное обеспечение, которое явно не проектировалось под уязвимость. Т.е. энтропия процессора помножается на энтропию программного обеспечения.
Посмотрите, столько колец (уровней) доступа у х86. А та же моторола обходилась всего 2мя: супервизор и юзер и отлично себя ощущала в разных машинах.
Ну вот этого уже достаточно, чтобы понять, что вы просто не понимаете, о чём говорите :(
Реально из тех колец, начиная с 80386, два: 0 (супервизор) и 3 (пользователь). Это так потому, что в системе пейджинга есть только один бит на уровень доступа на страницу: цитирую SDM:
Every access to a linear address is either a supervisor-mode access or a user-mode access. For all instruction fetches and most data accesses, this distinction is determined by the current privilege level (CPL): accesses made
while CPL < 3 are supervisor-mode accesses, while accesses made while CPL = 3 are user-mode accesses.<...>
If the U/S flag (bit 2) is 0 in at least one of the paging-structure entries, the address is a supervisor-mode address. Otherwise, the address is a user-mode address.
Соответственно уровни (кольца) 1 и 2, оставшиеся в наследие от 80286, просто никем никогда всерьёз не использовались. Кто и зачем их придумал в x86 - ХЗ. Возможно, они просто косплеили VAX и тому подобных, где есть реальная польза в этой схеме уровней и её никто не ломал.
Зато добавление SMM даёт в этой нумерации условный уровень -1 (а ME - -2, но уже не лезем туда). И это уже соответствует традициям новых архитектур - ARM, RISC-V: 0 - user, 1 - supervisor, 2 - hypervisor (только в ARM; RISC-V не стал его в итоге вводить), 3 - machine (аналог SMM и т.п.) - вот это уже разумная схема. У VAX достаточно близко к этому.
А то, что вы говорите про Motorola (какой? M68k?), точно так же до чёрта где, включая упоминаемые тут в треде S/360 с потомками.
А изначально они все такими и были. Защита появилась именно после появления необходимости в многопоточности. Чтобы какой-то из потоков не мог убить (или повредить) хотя-бы системный (друг друга пусть бьют, это не так важно)
Важно. Именно что важно. Вы опять не в курсе и фантазируете. В условиях одной очень дорогой машины отдаваемой по факту в субаренду многим пользователям - разделение доступа имело смысл и коммерческий (нефиг воровать секреты друг от друга), и специально-служебный (разные отделы даже в одной воинской части или в каком-нибудь местном ГБ не должны знать данные друг друга и менять чужие данные), и прочий аналогичный. "Многопоточность" в смысле multithreading одного процесса тут никаким боком, она появилась заметно позже.
Повторюсь, приведённый мной пример самый наивный. По факту там есть гораздо более извращённые методы. Были даже абьюзы системы внеочередного выполнения инструкций.
Если мы говорим про то, когда в коде ядра/супервизора есть ошибка, которая позволяет допустить что-то на основании недопроверки данных - то это одно. Если meltdown, spectre и прочее - это уже совсем другое. Утечка подобного рода может быть вообще на чём угодно, и там, где её всерьёз опасаются, вообще не допускают одновременного физического присутствия на одном железе (а то и в одном помещении); эти уязвимости просто легче всего, автоматизированно и скрыто эксплуатировались. Смешивая эти случаи, вы убиваете возможность серьёзного обсуждения. Перестаньте смешивать, тогда можно будет обсуждать.
Я лишь хотел сказать, что чем сложнее становится процессор тем сложнее предвидеть все случаи, которые обеспечат несанкционированный прямой или косвенный доступ пользовательскому коду.
Верно. Стандартные модели не ловят побочные каналы доступа. Но сами эти каналы - особенность оптимизации, которая может быть легко устранена на программном уровне - средства к этому есть.
Но - в третий раз говорю - не собираюсь смешивать эти вопросы с общими вопросами защиты.
Важно. Именно что важно. Вы опять не в курсе и фантазируете. В условиях одной очень дорогой машины отдаваемой по факту в субаренду многим пользователям - разделение доступа имело смысл и коммерческий (нефиг воровать секреты друг от друга), и специально-служебный (разные отделы даже в одной воинской части или в каком-нибудь местном ГБ не должны знать данные друг друга и менять чужие данные), и прочий аналогичный. "Многопоточность" в смысле multithreading одного процесса тут никаким боком, она появилась заметно позже.
Теперь я понял, что мы говорим с разных позиций и точек зрения. Вы - про сервера и виртуализацию в корпорате (а значит зарабатыванию денег и прочих вещей), а я с позиции пользователя ПК дома. Если смотреть с вашей точки зрения, то я считаю, что там должно быть принципиально другое оборудование. И оно таким и было, пока кое-кто не подмял под себя большую часть рынка. И то, даже там они пытаются в видимость "иного" оборудования (привет Xeon'ам), но при этом проблемы тянутся из пользовательского сегмента.
Что касается ваших замечаний про "не понимаю" - всё я понимаю, но не могу повлиять на тех, кто заявленное производителем использует на своё усмотрение, часто не придерживаясь официальной спецификации.
Теперь я понял, что мы говорим с разных позиций и точек зрения. Вы - про сервера и виртуализацию в корпорате (а значит зарабатыванию денег и прочих вещей), а я с позиции пользователя ПК дома.
Я говорю в контексте полной виртуализации, потому что ветка дискуссии посвящена именно этому. "Пользователь ПК дома" таким практически не пользуется. Если что-то и виртуализуется, то без его ведома.
Если смотреть с вашей точки зрения, то я считаю, что там должно быть принципиально другое оборудование. И оно таким и было, пока кое-кто не подмял под себя большую часть рынка.
Про что речь? Про линию S/360 с потомками? У неё свои особенности, которые могут и мешать тут (хотя больше помогают).
всё я понимаю, но не могу повлиять на тех, кто заявленное производителем использует на своё усмотрение, часто не придерживаясь официальной спецификации.
А это всегда со всеми происходит. И иногда производителю приходится выгинаться под то, что не просто не ожидал, но и противоречит всему ожидаемому. Увы. Но опять же это другая история.
"Многопоточность" в смысле multithreading одного процесса тут никаким боком, она появилась заметно позже.
Вот тут Вы ошибаетесь: многопоточность именно в таком смысле была в OS/360 MFT с подзадачами и в OS/360 MVT, т. е. уже в конце 1960-х. Подзадачи в терминологии OS/360 -- это как раз потоки одного процесса, если использовать терминологию Винды (ну а задачей именовался головной поток).
Можно ещё отметить, что критерий опубликовали в 1974, но IBM и без него всё сделала правильно с первого же раза (VM/370 -- 1971 год; железо, соответственно, проектировалось ещё раньше). А Интел и опубликованное, и уже широко используемое не помогло. Вероятно, чукча не читатель...
Зашёл в комментарии проверить, что кто-то вспомнил и про виртуализацию. Отлично, Хабр настороже 🫡
Исследуя материал для доклада по ветвлениям внутри студии, я пришел к выводу, что данный штраф не так критичен, учитывая, что в среднем лишь 5% предсказаний ошибочны. Непредсказуемые ветвления — это минус, но большинство из них хорошо поддаются профилированию в горячих функциях и их хорошо видно что в PIXe, что в Razor'e. Оптимизировать алгоритм имеет смысл только там, где профилировщик выявляет проблемы. За последние двадцать лет процессоры стали более устойчивыми к неоптимизированному коду, а компиляторы научились его оптимизировать, так что оптимизация ветвлений ранзыми костылями и хаками из конца 90-х уже не так актуальна и требуется в основном для максимального увеличения производительности уже на этапах пост профилировки релиза.
Branch-order-buffer завезли в x86 вроде бы в Nehalem (как и почти всё перечисленное - изобретения 1960-1970 годов).
Раньше branch missprediction стоил сотни такотов. Начиная с Nehalem (благодаря BOB) - длину конвейра.
Ссылка почитать:
https://www.realworldtech.com/sandy-bridge/3/
Господа,
Предлагаю нам всем создать общий реестр сравнения микропроцессоров, и микроконтроллеров (в том числе археологических)
Предлагаю именно в виде электронной таблице, так как можно делать сортировку по строкам и столбцам, подсвечивать ячейки.
Как говорят: "всё познается в сравнении".
Это поможет нам лучше понимать ход развития истории в этой предметной область, находить ближайшие аналоги, прослеживать эволюцию, делать аналитику, ретроспективу находить рыночные ниши.
Было бы здорово, если каждый напишет про тот процессор с которым упорно работал.
Кто готов пополнить реестр, я добавлю возможность редактировать.
Публикации
486-го хватит всем