Комментарии 16
понравился последний вопрос, чему-то конечно научились в процессе, но в итоге время потеряли, при Сталине тоже передирали (например Ту-4), но не так бездарно
Ну, судя по внутреннему устройству ЕС-1045/46, ереванская контора мало чему научилась. Да, машина получилась быстрая, но железа в ней... Явно больше, чем следовало бы, и, опять-таки, приличное его недоиспользование. Хотя до такого откровенного идиотизма, как в 1030, там всё-таки не доходит: чему-то таки научились, но явно недостаточно.
Честно говоря, я б на месте профильного нашего руководства после разработки 1030 просто разогнал бы ереванский институт нафиг. Пускай лучше коньяк делают: он у них лучше получался :) Но, думаю, у армян был не только коньяк, но и сильное лобби где надо. Ведь позже они не дали казанцам сделать новую машину на смену 1033, пропихнув свою 1045.
трудно поверить, но был у них в свое время, коньяк вполне оценил, с моей точки зрения милые люди, дела ЕС меня тогда не касались, какое-то лобби у них конечно было, теперь какая разница, примерно как про походы князя Игоря на половцев :)
но железа в ней...
Но зато хорошее железо: в гараже стоит шкаф из ЦП ЕС-ки, отличная вещь. Очень тяжелая, но отличная.
Давеча откопал в своих загашниках книгу "Операционная система ОС ЕС". В.П. Данилочкин, В.В. Митрофанов и др. Финансы и статистика, 1988. 592 страницы мелким шрифтом. В книге есть немного про макроассемблер, но самое интересное - "Глава 2. Процедура начальной загрузки". Так, что если где-то завалалась ЕС ЭВМ в более-менее нераздербаненном виде - готов поучавствовать в её запуске. ;)
"Операционная система ОС ЕС"
Позволю себе небольшую цитату из этой книги:
Система виртульаных машин (СВМ ЕС) представляет собой следующий шаг в развитии концепции виртуализации системных ресурсов вплоть до понятия виртуальной машины (ВМ). В СВМ ЕС может одновременно функционировать до 10 000 виртуальных машин, каждая из которых функционально эквивалентна реальной ЭВМ. Таким образом, СВМ ЕС представляет возможности параллельной работы на одной реальной ЭВМ Ряд-2,3 различных системно-независимых программ и операционных систем, включая ДОС ЕС и ОС ЕС.
Принципы работы виртульной машины соответствуют принципам работы моделей ЕС ЭВМ Ряд-2, за исключением того, что в виртуальной машине не поддерживаются средства мультипроцессирования и прямого управления. Дня неё моделируются монитором виртуальных машин все технические средства реальной ЭВМ, включая пульт управления, процессор, основная память, каналы ввода-вывода, устройства управления и периферийные устройства, называемые в этом случае соответственно виртуальный пульт управления, виртуальные периферийные устройства и т.д.
Ряд-2 это почти все машины серии ЕС-1020, ЕС-1030, ЕС-1040 и ЕС-1060.
Удивительно то, что виртуализация и понятие гипервизора (монитора виртуальных машин), существовавшие в ЕС ЭВМ (IBM System/360/370) с 1970-х годов пришло в PC только в середине 2000-х и теперь преподносится как нечто очень новое, модное и молодежное.
Надо еще покопаться в старом хламе. Помню была книга по программированию СМ-ок (PDP), примерно тех же времён.
К «Ряду 2» (аналог серии System/370) принадлежали модели ЕС-1015, ЕС-1025, ЕС-1035, ЕС-1045, ЕС-1055, ЕС-1060, ЕС-1061, ЕС-1065.
Насчёт Ряда 2 Вас уже поправили. 1020, 1022, 1030, 1032, 1033, 1040, 1050, 1052 -- Ряд 1, т. е. Система 360. Там поддержки виртуальной памяти не было, а значит, и СВМ работать не могла.
Что же до позднего появления виртуализации ПК, то здесь надо спасибо сказать фирме Интел, которая за всю свою историю не создала ни одного вменяемого процессора, если говорить про архитектуру: сплошное уродство на уродстве. Поэтому до появления специальных средств поддержки виртуализации создание системы виртуальных машин на интеловской архитектуре было невозможным технически. Ну а Системе 370 никаких дополнительных средств для этого не требовалось, хватало обычного механизма виртуальной памяти. Если специальные средства поддержки виртуализации имелись, они ускоряли работу и гипервизора, и виртуальных машин, но принципиально ничего не изменяли.
Ну а насчёт "нового и молодёжного" -- это не только виртуализация. Почти всё "новое" реально появилось впервые в 1960-70-х годах. Собственно, только Plug&Play, кажется, и стал реально новым, когда он появился на ПК в 1990-х.
Что же до позднего появления виртуализации ПК, то здесь надо спасибо сказать фирме Интел, которая за всю свою историю не создала ни одного вменяемого процессора, если говорить про архитектуру: сплошное уродство на уродстве.
А чем вам не нравятся процессоры Intel - те, которые x86? С учетом их цены, естественно. Например, виртуальный режим 8086/8088, позволявшший запускать несколько виртуальных копий DOS (реально позволявший, я такое делал под DESQView в самом начале 90-х), появился уже в 80386, ещё аж в 1985 году. Там же появилась и вполне полноценная страничная организация памяти, позволявшая реализовывать виртуальную память в духе IBM System/370. Так что сделать аналог той же IBM VM/SP (я, кстати, немало с ней поработал в молодости на EC1045, где, кстати, никаких аппартных средств поддержки виртуалихации кроме этой самой виртуальной памяти тоже не было) возможность была ещё тогда.
Причина позднего прихода виртуализации IMHO была в другом: памяти массовых ПК под нее, с учетом выросших потребностей прикланого ПО, откровенно не хватало. Памяти за разумные деньги ещё в начале 90-х не хватало даже для широкого распространения ОС с вытесняющей многозадачностью, типа разнообразных Unix или линейки систем от команды из DEC (RSX/VMS/Windows NT). Память была настолько ценным ресурсом, что побеждали системы с кооперативной многозадачностью: Windows на ПК, Netware на сервере и т.д. Потому что им памяти требовалось меньше. А вы говорите - "виртуализация"...
PS Ну да, в 80286 Intel вовсю поигралась с дhугой моделью организации памяти - сегментной (а потом тащила совместимость с ней аж до x64). Впрочем, тогда ещё не было очевидно, лучше ли она страничной или хуже, так что это IMHO было простительно.
Архитектура у интеловских процов ужасна. И в плане системы команд, особенно её кодирования (попробуйте, хотя бы, определить длину команды -- с учётом всех этих идиотских префиксов), и в плане системных вещей. В частности, виртуализацию на 80386 сделать невозможно технически, потому что дебилы-архитекторы половину системных по своей сути команд сделали непривилегированными. Установить значения системных регистров код пользователя не мог, а прочитать -- запросто, и это полностью убивает любую возможность виртуализации. Ну а в Системе 370 все такие команды были привилегированными -- потому виртуализация и оказалась возможной.
Что же до памяти, СВМ ЕС, она же VM/370, работала уже на машине с 512 килобайтами памяти. Ну а вытесняющая многозадачность была и в OS/360 MFT (минимальный объём -- 128 Кбайт), и в "бабке Винды" RSX-11M -- которой, если уж совсем минимальная конфигурация, хватало 32 Кбайт, а в полной её вовсю крутили на машинах с 248 Кбайтами. Да, все эти системы без графики, но, простите, первая версия Винды работала ещё на 8086/88, имея лишь 640 Кбайт ОЗУ -- т.е. пары мегабайт уж точно хватило бы и на графику невысокого разрешения, и на вытесняющую многозадачность. Ну а такой объём ОЗУ был, по сути, минимальным для компьютеров на 80386 -- память уже не была по-настоящему дефицитным ресурсом.
попробуйте, хотя бы, определить длину команды -- с учётом всех этих идиотских префиксов).
Но с другой стороны, это позволяло сэкономить на длине команды: в System/360 1-байтовых команд не было, а в 8086 - были. Но таки да: шестнадцатеричный дамп памяти на ЕС читать было сильно легче.
В частности, виртуализацию на 80386 сделать невозможно технически, потому что дебилы-архитекторы половину системных по своей сути команд сделали непривилегированными.
Ну, VMWare же сделали ;-) Правда есть нюанс - как именно: если на то, что в режиме пользователя программа видит CR0-3 хоста, можно наплевать, то привилегированный режим пришлось поддерживать в режиме интерпретации :-Q
В целом, микропроцессоры Intel были спроектированы под другую область применения с другими компромисными решениями. И для нее, как показала практика, они подошли хорошо. Виртуализации там просто не предполагалось, иначе бы команды чтения управляющих регистров сделали бы привилегированными.
Что же до памяти, СВМ ЕС, она же VM/370, работала уже на машине с 512 килобайтами памяти.
Я же не зря уточнял: "с учетом выросших потребностей прикладного ПО". 512 КБ к началу 90-х - хватало уже не для каждой программы даже на однозадачной DOS. А в 90-х и 640К стало достаточно не только лишь всем, в результате куча программ начала использовать DOS extender, тот же культовый Doom требовал целых 4МБ, и школьников из небогатых российских семей это немало огорчало.
Собственно, требования к памяти были ключевым аспектом в конкуренции ОС того времени. Именно они - это то, что не позволило стать лидером на ПК не только ОС с вытесняющей многозадачностью: Unix и Windows NT (хотя последняя, казалось бы - тоже Windows), но и кооперативной, но менее компромисной OS/2 2.0 - у которой, при всех ее достоинствах было минимальное требование 4МБ, в то время как под Windows 3.x можно было вполне продуктивно работать уже на 2МБ.
Ну, и немного про позабытое.
Ну а насчёт "нового и молодёжного" -- это не только виртуализация. Почти всё "новое" реально появилось впервые в 1960-70-х годах. Собственно, только Plug&Play, кажется, и стал реально новым, когда он появился на ПК в 1990-х.
А как насчет механизмов асинхронного ввода/вывода на уровне ядра - и не просто, а с учетом файловой системы? Отложенных процедур обработки прерыванийв NT? Порта завершения ввода-вывода в коммерческих Unix и NT? Структурной обработки исключений, в том числе - и в режиме ядра?
А вот что на ЕС ЭВМ PnP не было - это никаким недостатком не было: если бы PnP была, то не полчилось бы калымить на генерациии ОС :-)
Но с другой стороны, это позволяло сэкономить на длине команды: в System/360 1-байтовых команд не было, а в 8086 - были
Подобную "экономию" надо рассматривать в комплексе. Наличие или отсутствие однобайтовых команд само по себе абсолютно неважно, важна совокупная длина программы, решающей некую задачу. Причём важна и в наши дни: хотя ёмкость ОЗУ можно считать условно бесконечной, ёмкость кэша первого уровня весьма невелика и является одним из основных факторов, ограничивающих производительность.
Ну, VMWare же сделали ;-) Правда есть нюанс - как именно: если на то, что в режиме пользователя программа видит CR0-3 хоста, можно наплевать, то привилегированный режим пришлось поддерживать в режиме интерпретации :-Q
Я понятия не имею, как сделали VMWare и на что они опирались. Но если там приходилось что-то интерпретировать в массовом порядке, это по определению не могло быть эффективным решением -- ну а в VM/370 гостевая система практически не теряла в производительности, если у неё не было собственной виртуальной памяти (если была, то для эффективности нужна была уже специальная поддержка, а без таковой тормоза таки возникали -- но не сказать, чтоб очень большие).
Виртуализации там просто не предполагалось, иначе бы команды чтения управляющих регистров сделали бы привилегированными.
Вряд ли виртуализация всей машины сразу предполагалась в Системе 370. Если на то пошло, в Системе 360 команды, считывающие "системные" данные, тоже были привилегированными -- т.е. IBM с самого начала шла правильным путём, полностью запретив пользователю доступ к тому, что его не касается. А в Интел -- просто дебилы, а "не предполагалось". Были б у них мозги -- не было бы, в частности, префиксов для команд, поскольку это исключает возможность быстрого и дешёвого декодирования команды. Не говоря уже о том, что архитекторы должны думать наперёд, а здесь у них даже отмазы в стиле "мы первопроходцы, до нас никогда этого не делали" не было.
Я же не зря уточнял: "с учетом выросших потребностей прикладного ПО". 512 КБ к началу 90-х - хватало уже не для каждой программы даже на однозадачной DOS. А в 90-х и 640К стало достаточно не только лишь всем, в результате куча программ начала использовать DOS extender, тот же культовый Doom требовал целых 4МБ, и школьников из небогатых российских семей это немало огорчало
Не смешивайте одно с другим. Для вытесняющей многозадачности и виртуальных машин памяти много не надо. То, что она требуется определённым прикладным программам, ни разу не увеличивает потребность в памяти для самой ОС.
RSX-11M в полноценном варианте могла работать на машине с примерно 128 Кбайтами ОЗУ (сама система под себя и драйверы пожирала меньше 100 Кбайт). Запустить, например, компилятор Паскаля на такой машине уже не получилось бы: он требовал под себя 64 Кбайта и не полез бы в оставшуюся память (полноценной виртуальной памяти на большинстве PDPшек не было из-за технических ограничений процессора и MMU, лишь на некоторых моделях, в частности, на PDP-11/70, такое можно было сделать). А вот ассемблер или Фортран в оставшийся объём вписывались и работали бы.
Так что не объём памяти был препятствием для нормальных ОС на ПК, а кривая архитектура процессора и компьютера в целом. И, кстати говоря, если RSX-11M хватало под себя условных 100 Кбайт ОЗУ (с вытесняющей многозадачностью и всем таким прочим, включая драйверы устройств), то почему убогой MS DOS и без драйверов (ввод-вывод управлялся кодом BIOS) нужно больше? Не говорит ли это как о качестве системы команд, так и о качестве кода системы?
А как насчет механизмов асинхронного ввода/вывода на уровне ядра - и не просто, а с учетом файловой системы? Отложенных процедур обработки прерываний в NT? Порта завершения ввода-вывода в коммерческих Unix и NT? Структурной обработки исключений, в том числе - и в режиме ядра?
RSX-11M была насквозь асинхронной и на уровне ядра, и на прикладном уровне -- в отличие от всяких Унихов, где асинхронного ввода-вывода для пользователя просто нет. (Да, в POSIX включили, но это не ОС, а стандарт, и далеко не везде эти расширения поддерживаются; в Линухе сравнительно появился IO_URING или как его там -- но, как по мне, оно какое-то... переусложнённое и неудобное).
Механизм отложенной обработки прерываний в NT -- практически 1:1 копия механизма VAX/VMS, а тамошний -- расширение механизма RSX-11M.
Порты завершения ввода-вывода -- это уже пользовательский уровень, причём принципиально новых возможностей не дающий.
Структурная обработка исключений -- это вообще про языки высокого уровня (C/C++), которые-то как раз развивались и далеко ушли от раннего Паскаля или Фортрана с Коболом. Я говорю о новых вещах на уровне, в первую очередь, железа, а там с подлинно новым весьма туго, особенно если говорить о концептуальном уровне, а не о реализации. Понятно, что современные суперскалярные процессоры куда круче микроархитектурно, чем первые -- но сама концепция впервые появилась и была воплощена именно в 1960-е.
Даже если взять ту же PCI Express: конечно, ничего аналогичного в 1970-е не было, однако сама идея синхронной последовательной передачи данных по одной линии вместо асинхронной по параллельной не только была в умах, но и на практике такие линии были -- только использовались не в качестве системных шин, а чисто для связи с определённой периферией. Или, скажем, GPU. Их не было, а вот матричные процессоры уже были -- а GPU, по большому, счёту, матричным процессором и является. Точней, несколькими матричными процессорами с кучей локальной памяти и некоторыми узкоспециализированными аппаратными блоками (для отсечения и отбраковки пикселей, не попадающих в кадр, например -- это можно делать и программно, но специализированная аппаратура справляется, понятно дело, быстрей), но базовая идея (широкий SIMD и всё такое) -- та же самая.
Впрочем, тогда ещё не было очевидно, лучше ли она страничной или хуже, так что это IMHO было простительно.
Ну да, в пдп-11 к тому времени уже 10 лет была страничная организация и оси под это (тот же ранний unix), а этим было "не очевидно".
Просто там какие-то програмисты-фрики-перфекционисты решали, по-видимому: слухи, что якобы архитектуру 8086 разрабатывал программист, ужаснейший iapx432 который может показаться прикольным тоже только фрику-программисту, ну и сами "замечательные" сегменты вместо страниц в 286. Что там ещё, "замечательный" стек FP-регистров в 8087 например. По последнему можно вспомнить как Дейкстра, что ли, очень восхищался архитектурой burroughs, чисто стековой.
Ну, справедливости ради, на PDP-11 была не совсем страничная организация в том смысле, как обычно её понимают: там MMU работало по-другому (и это правильно, учитывая, что машинка была 16-разрядная, а не 32, как IBMовские мэйнфреймы). С точки зрения лёгкости управления отображением памяти и его влияния на производительность машины PDPшная схема лучше, но она не масштабируется с увеличением разрядности адреса.
Но таки да, виртуальную память со страничной организацией уже вовсю обкатали, как минимум, на Системе 370, где соответствующие ОС (OS/360 SVS и затем MVS и VM/370) появились в самом начале 1970-х, и уже было понятно, что оно работает эффективно, но требует некоторых улучшений. В частности, в поздних Системах 370 появилась команда IPTE -- INVALIDATE PAGE TABLE ENTRY -- чтобы запрещать доступ к определённой странице и одновременно чистить TLB от копий именно запрещаемого элемента (до этого была только команда PTLB, которая очищала весь TLB, что, естественно, не способствовало сохранению производительности).
Так что Интел могла бы уже на 8086/88 предусмотреть управление памятью в стиле PDP-11: для 16-разрядных адресов это куда эффективней со всех точек зрения, чем уродливые сегменты. Собственно, в Z8000 нечто аналогичное было сделано; правда, реализовано было с помощью дополнительной микросхемы, но, как по мне, это вполне разумно: сам проц 16-разр, ну а раз всё "на борт" впихнуть нельзя, оставьте решение за разработчиком компьютера. Никого ж не смущало, что FPU долго ещё был отдельной микросхемой, так почему для MMU это не разрешить?
Так, что если где-то завалалась ЕС ЭВМ в более-менее нераздербаненном виде - готов поучавствовать в её запуске. ;)
Хорошо бы для начала найти копию ОС ЕС. System/360 выкладывали и в дистрибутивах, и в собранном виде, а вот с ОС ЕС глухо...
Неуместные пассажи в статье и некоторых комментариях :-(
Процессор ЭВМ ЕС-1030. Пульт управления и заключение