Да, и насчёт 1420, которая годами... Может, это была какая-то военная сборка? Или повезло) У нас эти СМ-ки и их периферия ломались довольно часто.
Ну, я несколько СМок и ЕСок знал лично -- и чисто электронная часть везде работала (почти) надёжно, если и дохли, то вполне конкретные микросхемы, а не то одно, то другое -- что наводит на мысль о разном качестве изготовления на разных заводах. Вот периферия -- да, везде не самым сильным местом была, хотя тоже есть нюансы (скажем, древние 7,25-мегабайтные ЕС-5052 и ЕС-5056, оставшиеся "в наследство" от ЕС-1022, работали вполне себе надёжно, а их контроллеры вообще никогда не ломались, а вот новые ЕС-5080 на 200 Мбайт -- это был ужас).
Насчёт военки -- именно та, с которой мужики экспериментировали, скорей всего, именно такая и была; у нас на ВЦ одну из ЕС-1035 называли "военной", хотя "военного" там, кажется, только золото на разъёмах, сами микросхемы -- обычная 500-я серия, главным образом (хотя фиг знает, может, для военных ЕСок шли обычные же микросхемы, только проверенные качественно; другая наша ЕС-1035 была "оловянной" и постоянно сбоила из-за неконтактов -- чинилась пинками по рамам процессора).
Только не с кассетами, а с пакетами уже -- кассетные были меньше (2,4 и 13 Мбайт). Они действительно много жрали (ЕС-5061, которые очень близки, хотя и не идентичны, -- кажется, 1,5 кВт, а в пике до 3). Мониторы выключали наверняка -- точней, по моему опыту, их включали, когда они были нужны только. НМЛы и принтер -- тоже по необходимости. Какой-нить там мультиплексор передачи данных, к которому мониторы подключены, и контроллеры дисков и лент вряд ли отключали -- но они и жрут довольно мало. Плюс, повторюсь, это завод, там станки в 3 смены пашут -- и на этом фоне что есть та СМка, что её нет...
Начали эксперимент ещё при СССР. Завод в три смены работал, поэтому отключать в плане экономии смысла не было (хотя диски, наверное, отключали, тем более, что самой системе они нужны только для загрузки): станки в любом случае жрали куда больше, чем одна СМка. Ну а десятков киловатт даже со всей периферией быть не могло. Процессор -- ватт 700, память -- ещё меньше, контроллеры периферии -- где 300, где 500 Вт... Это ж не ЕС ЭВМ, где действительно несколько десятков киловатт могло быть, когда всё включено.
Потому я и сказал про очень паршивые случаи. Сама ошибка предсказания ветвления -- да, где пару тактов (в достаточно примитивных процессорах), где, может, под сотню (Пень-4 с его жутко глубоким конвейером и всё такое), но уж точно не тысячи.
Ещё, кстати, интересно, что будет делать проц, если ветвление предсказано, а команды в кэше нет. По идее, запустит процесс выборки, не дожидаясь точного определения ветвления -- и в случае ошибки это тоже может дорого стоить.
Но я всё это больше к тому, что реальная производительность может очень сильно зависеть от того, насколько хорошо компилятор (или программист) расположил код -- чтоб минимизировать риски кэш-промахов, а тут надо и предсказания ветвлений по возможности учитывать, и адреса размещения и команд, и данных, и команды предвыборки разумным образом вставлять... Ну, это в идеале, конечно :)
Просто когда мы говорим о пенальти там и сям, то я сторонник подхода "покажите мне код-демку или документацию"
Как по мне, зачастую достаточно "правдоподобных рассуждений" -- тем более, что некоторые вещи трудно проверить в реальности. Скажем, создать описанную мной ситуацию (кэш-промах и одновременная занятость нужного банка памяти интенсивным вводом-выводом) на ПК весьма и весьма непросто, если вообще возможно с разумными усилиями, да и на микроконтроллере, где ты работаешь с голым железом и действительно можешь такое создать, за 5 минут демку не набросаешь.
Так а если в кэше нет команды, на которую переход? Жди, пока заполнится из памяти. А если в этот момент с этим банком памяти идёт интенсивный ввод-вывод? Жди, пока он не закончится. Вот и набегают тысячи тактов. Так что неверно предсказанный переход может быть крайне дорогим, если рассматривать всю вычислительную систему в комплексе, а не ограничиваться только процессорным ядром.
Ну, 133-ю я в измериловке встречал -- но не в ЭВМ. Хотя, возможно, сами приборы изначально делались для вояк и лишь потом появились на гражданских предприятиях.
131-я была -- кажется, в СМ-1600 в проце как раз К131ИП3, а не 531, но за давностью лет утверждать не берусь.
У меня из моих запасов микросхем самая древняя -- триггер К155ТВ1 1973 года (ещё со старым обозначением, К1ТК551, вроде б). С год назад его специально нашёл, запустил -- работает-с :)
В общем, думаю, тут как повезло (например, на каком конкретно заводе производили микросхемы).
С периферией у нас всё сильно хуже было, если говорить про качество и надёжность. Да и с самими носителями тоже. Были, например, НМЛ ЕС-5025 (если склероз не изменяет), обеспечивающие плотность записи и 32, и 64 бит/мм. Наши ленты на 32 работали, на 64 -- фигвам, а буржуйские (басфовские, вроде б) -- без проблем. Т.е. сам наш НМЛ, получается, реально мог работать на этой плотности (впрочем, у IBM за лет 10 до этого уже была 246 бит/мм), а нормальную ленту производить так и не научились (во всяком случае, доступную обычным предприятиям).
Дык тогда и было -- вторая половина 1980-х и 90-е. Электроника дохла очень редко. У одной из знакомых СМ-1420 примерно за 10 лет -- одна КР531ИП3 в диспетчере памяти (MMU) и ещё пару отказов электроники в периферии; у одной СМ-1600 постоянно дохли К170-что-то-там в синхронном последовательном интерфейсе, забыл его шифр, но всё остальное работало много лет без проблем; в ЕС-1035 постоянно дохла только оперативная память (К565РУ1, с темпом микросхема в месяц, но код Хэмминга спасал, давая нормально отработать смену), логика -- очень редко (ну, за те же примерно 10 лет несколько микросхем заменили), в проце ЕС-1130 за больше 5 лет сдохла одна К1800ВС1 и, кажется, всё (вот с дисками ЕС-5080 там проблемы были постоянные -- но это уже не чистая электроника). Так что всё вполне надёжно было. Ну а так -- да, в СМках и большинстве ЕСовской периферии -- 155, 555, 531 и небольшое количество БИС (те же КР1804ВС1 в проце СМ-1420), в ЕСках -- в основном, 500-я серия...
А на сервисное обслуживание просто забили -- спирт же по нормам выписывают, а не по факту обслуживания :) Мужикам (на одном довольно крупном машиностроительном предприятии, я на другом работал, но общались постоянно) интересно стало, сколько машина проработает, поэтому и не выключали. (Основная работа была готовить перфоленты и всё такое прочее для станков с ЧПУ и что-то там умное считать -- ну и змейку гонять, конечно).
А я вот знаю одну СМ-1420 под управлением ОС-РВ, в девичестве RSX-11M, которая без перезагрузки работала несколько лет (что странно, за это время не было поломок не только в чистой электронике -- к тому времени делать её надёжно у нас уже научились, но даже в дисках -- хотя, может, про них уже подзабыл, их на машине несколько штук, поэтому можно было выводить из действия и подключать обратно по мере необходимости). Так что код коду рознь, и качество может быть совершенно различным. Нынешний код, если брать "в среднем по больнице", пожалуй, будет хуже -- но это следствие снижения порога входа в профессию.
Зависимость от ветвления? В современных чипах это ветвление занимает ноль тактов.
Неудачно предсказанное ветвление в современных чипах может стоить сотни, а в особо неудачных случаях -- и тысячи тактов.
Прямо так никто не думал, ага.
Угу, не думали-с. Потому что, в зависимости от того, на чём работал и каков объём программы, компиляция и сборка могли занять и несколько секунд, и несколько часов. Это сейчас хелловорлды мгновенно собираются -- и то лишь с точки зрения человека.
Хотя насчёт... хм... языка... хм... статьи я Вами полностью согласен.
Ничего не сохранилось -- всё было на магнитной ленте, которую мать пустила на верёвку.
Насчёт проблемы я написал: система использовала в качестве консоли пишмашку, а на ЕС-1130 её уже не было, поэтому работа была возможна только на виртуальной машине, где пишмашку эмулировал гипервизор.
Чудесно, когда можно полностью избавиться от слоя виртуализации, организуя все только с помощью партиционинга. Но вот проблема: живая миграция, например, в этом случае будет невозможна.
Если изоляция -- не с помощью ручного перетыкания кабелей и перещёлкивания переключателей, то возможна, если я правильно понимаю, что такое "живая миграция".
что именно можно считать подлинной виртуализацией, а что - таковой не является
Как по мне, подлинная виртуализация -- это когда программа независимо от того, что она делает, всегда получает одни и те же результаты что при работе на реальной физической машине, что при работе на виртуальной машине. Естественно, при соблюдении двух очевидных условий: 1) результаты не зависят от конкретного времени выполнения, 2) программа не выходит за рамки оговорённого архитектурой -- например, не использует команды, результаты выполнения которых зависят от конкретной модели -- будь то команда ДИАГНОСТИКА на мэйнфреймах или функции и содержимое моделезависимых регистров на IA-32/AMD64.
И нужна ли она вообще?
Полезна, но не необходима. Скажем, на ПК в общем случае невозможно написать и отладить драйвер какой-то железки, используя ВМ, поскольку виртуализация периферии очень плоха, ну а на классической VM/370 такое делалось без проблем.
Моя супер-пупер-мега-ОС, которую я начал лепить на железной ЕС-1035, потом делалась в рамках СВМ ЕС, в девичестве VM/370, на ЕС-1130; на реальной ЕС-1130 я её запускать не мог, поскольку в качестве единственного консольного терминала я использовал пишущую машинку, а у ЕС-1130 её уже не было; поддержку дисплеев я реализовать банально не успел -- хотя наверняка сделал бы, если б продолжал работать на прежнем месте. Так вот, виртуальную память, а отчасти и работу с дисками я доводил до ума уже под СВМ, и это было намного удобнее: работая на ЕС-1035 без СВМ (она не сразу в моём распоряжении появилась), я для трансляции исходников был вынужден загружать ОС ЕС (OS/360), а после трансляции, сборки и записи результата на магнитную ленту -- загружаться с неё и тестировать полученное, что, естественно, сильно тормозило процесс. Под СВМ мне для этого достаточно было переместить свою пятую точку между двумя соседними мониторами, каждый из которых был консолью двух разных виртуальных машин -- на одной работала ОС ЕС, на второй -- моя меганедосистема. Плюс, отладка с помощью СВМ удобней, чем с железного пульта управления машиной (даже в сочетании с пишмашкой, которая в пультовом режиме могла распечатывать память или позволять её изменять, ну и всё такое прочее).
Ну что ж, вот теперь мне ясно, что реально Вы не понимаете, что такое виртуализация и как она реализуется технически, и Вы не понимаете, как в реальности работают операционные системы вообще. Вопросов больше не имею.
На самом деле, этот подход, хотя и более-менее работает на практике, в теории не даёт 100% виртуализации: например, программа может "на лету" модифицировать свой собственный код (это, например, делали первичные обработчики прерываний ввода-вывода и внешних прерываний в классической OS/360). Очевидно, что гипервизор не заметит подобной модификации, поскольку технически это обычная запись в память. (Да, я знаю, что можно запретить запись в страницы памяти, занимаемые кодом, -- но кто сказал, что это не будут страницы с данными? В упомянутой OS/360 всё это происходит в самой первой странице размером 4 Кбайта, где лежат и начала обработчиков прерываний, и куча системной информации, которая должна быть доступна и на чтение, и на запись). Или, например, нечто было формально загружено как данные, а потом исполняется как программа (тоже реальные случаи из OS/360). В общем, этот подход в общем случае не работает, и единственной гарантированной возможностью "виртуализировать" условный 80386 на нём самом является интерпретация всего кода вообще -- даже непривилегированного, ведь в непривилегированном режиме потенциально могут работать части ОС, готовящие информацию для привилегированного режима (скажем, в истинно микроядерной системе). Собственно, это подход более-менее работает как раз потому, что он применяется лишь к узкому кругу "стандартных" ОС с хорошо известным поведением, в то время как классическая VM/370 на классических мэйнфреймах сможет успешно работать с любой ОС или системно-независимой программой.
Ну а если подобные команды являются строго привилегированными, никаких проблем не возникает: они гарантированно "попадут в лапы" гипервизору. Да и производительность, по итогу, окажется ещё и больше: в любом случае надо переключаться из непривилегированного в привилегированный режим, но хоть не надо анализировать код программы.
В общем, как по мне, это как раз полнейшая катастрофа в плане виртуализации -- если только разработчики не предусмотрели "отключение" этой команды каким-то подпольным образом. Такое вполне может быть предусмотрено, но я отнюдь не исключаю, что они либо действительно идиоты (в конце концов, идиотскую архитектуру IBM PC и его BIOS с целой кучей нелепостей именно в IBM придумали), либо просто решили забить на виртуализацию.
Ок. Объясните как эта команда, EPSW, нарушает "возможности виртуализации"?
А вот что-то, но не ответ:
Ещё раз повторяю: нарушением является факт возможности получения привилегированной информации непривилегированным кодом.
Какая такая приилегированная информация имеется в PSW программы? Формат PSW надеюсь Вам известен и Вы можете указать на байты и биты с "привелигерованной информациеЙ" и связать это с "нарушением возможности виртуализации". Прошу.
===========================
Конкретно по битам для 128-разрядного PSW: биты 0:17 и 24 (не считая разрядов, которые пока что не используются и равны нулю), содержат привилегированную информацию, которую от выполняемой программы необходимо скрывать, чтобы обеспечить полноценную виртуализацию. Непривилегированной информацией являются код условия (18:19), маска программы (20:23) и адрес команды (64:127). И именно привилегированную информацию EPSW возвращает программе (биты PSW[0:11,13:31]) -- т.е. делает ровно то же самое, что делают весьма многочисленные команды 80286 и 80386, из-за которых позже Интелу пришлось приделывать костыль для виртуализации.
Код, выполняющий подобные команды при работе на реальной машине, получит корректную информацию о состоянии процессора -- в частности, о том, работает ли он как код пользователя или супервизора и каково состояние масок прерываний и т.п. На основе этой информации он принимает решение, что делать дальше (например, системная по своей сути программа, если обнаружит, что была вызвана кодом пользователя и поэтому работает в режиме пользователя, может запросить у ядра переход в режим супервизора, если это ей для чего-то необходимо; или ей нужно переключить режим переадресации; или ей нужно сменить ключ доступа к памяти; или ей нужно понять, разрешены или запрещены прерывания или PER). При выполнении же на виртуальной машине эта же команда вернёт логически неверную информацию -- а именно ту, которая отражает состояние реального процессора, а не виртуального (и эта же самая гипотетическая программа увидит, например. что она работает в режиме пользователя с ненулевым ключом, хотя логически она должна выполняться в режиме супервизора с нулевым ключом -- просто PSW будет считан реальный, а не виртуальный).
Ещё раз повторяю: это абсолютно та же самая ошибка, что была допущена архитекторами Интел. Если для Вас это не очевидно, я тут бессилен.
Это не бред это привелигированая команда LOAD PSW (LPSW)
Бред -- не команда LPSW, а Ваше утверждение в ответ моё утверждение:
================
Кстати говоря, в современных мэйнфреймах появилась команда, позволяющая прикладному коду узнать содержимое PSW, в т.ч. состояние задача/супервизор -- что нарушает возможности виртуализации. Либо нынче в IBM сидят идиоты,
Не надо торопиться обвинять.
Нарушением была бы возможность изменять состояние задача/супервизор. Это можно сделать только командой загрузить новое PSW. Это привилегированная команда.
=================
Ещё раз повторяю: нарушением является факт возможности получения привилегированной информации непривилегированным кодом. Вы, похоже, этого не понимаете, иначе не было бы ни вышеприведённого Вашего утверждения, ни вот этого:
И давайте обойдемся без упоминания х86-64 в разговоре о МФ.
Ещё раз повторяю: проблема интеловской архитектуры -- в существовании команд, которые позволяют прикладному коду читать системные сущности (адреса таблиц описателей, например). Любые команды, подобные мэйнфреймовской LPSW, на 80286 и последующих процессорах являются привилегированными. И появление EPSW точно так же разрушает возможность виртуализации в мэйнфреймах.
Все есть и описано. Не надо наводить тень на плетень.
В "Принципах работы" -- не описано. Я не утверждал, что это вообще нигде не описано, я утверждал, что не описано в "Принципах работы", и что реальные мэйнфреймы работают сложней, чем там указано.
Не красиво и обидно слышать от Вас. Вы выглядили компетентным специалистом по МФ.
Ну так разберитесь с тем, в чём реальная причина невозможности виртуализации на интеловской архитектуре, а не просто отмахивайтесь от неё, -- тогда и не будете писать бред и слышать в ответ обидное. Я, извините, политкорректностью не страдаю и если вижу бред, то так и говорю.
А специалистом я ни разу не являюсь, я последний раз программировал для мэйнфрейма в 1993 или 94 году (на советской ЕС-1130), а в последний раз обслуживал её как электронщик или системщик -- году эдак в 98-м. Ничего современнее Системы 370 в виде советских машин я в моей реальной жизни даже не видел.
Ну, я несколько СМок и ЕСок знал лично -- и чисто электронная часть везде работала (почти) надёжно, если и дохли, то вполне конкретные микросхемы, а не то одно, то другое -- что наводит на мысль о разном качестве изготовления на разных заводах. Вот периферия -- да, везде не самым сильным местом была, хотя тоже есть нюансы (скажем, древние 7,25-мегабайтные ЕС-5052 и ЕС-5056, оставшиеся "в наследство" от ЕС-1022, работали вполне себе надёжно, а их контроллеры вообще никогда не ломались, а вот новые ЕС-5080 на 200 Мбайт -- это был ужас).
Насчёт военки -- именно та, с которой мужики экспериментировали, скорей всего, именно такая и была; у нас на ВЦ одну из ЕС-1035 называли "военной", хотя "военного" там, кажется, только золото на разъёмах, сами микросхемы -- обычная 500-я серия, главным образом (хотя фиг знает, может, для военных ЕСок шли обычные же микросхемы, только проверенные качественно; другая наша ЕС-1035 была "оловянной" и постоянно сбоила из-за неконтактов -- чинилась пинками по рамам процессора).
Только не с кассетами, а с пакетами уже -- кассетные были меньше (2,4 и 13 Мбайт). Они действительно много жрали (ЕС-5061, которые очень близки, хотя и не идентичны, -- кажется, 1,5 кВт, а в пике до 3). Мониторы выключали наверняка -- точней, по моему опыту, их включали, когда они были нужны только. НМЛы и принтер -- тоже по необходимости. Какой-нить там мультиплексор передачи данных, к которому мониторы подключены, и контроллеры дисков и лент вряд ли отключали -- но они и жрут довольно мало. Плюс, повторюсь, это завод, там станки в 3 смены пашут -- и на этом фоне что есть та СМка, что её нет...
Начали эксперимент ещё при СССР. Завод в три смены работал, поэтому отключать в плане экономии смысла не было (хотя диски, наверное, отключали, тем более, что самой системе они нужны только для загрузки): станки в любом случае жрали куда больше, чем одна СМка. Ну а десятков киловатт даже со всей периферией быть не могло. Процессор -- ватт 700, память -- ещё меньше, контроллеры периферии -- где 300, где 500 Вт... Это ж не ЕС ЭВМ, где действительно несколько десятков киловатт могло быть, когда всё включено.
Потому я и сказал про очень паршивые случаи. Сама ошибка предсказания ветвления -- да, где пару тактов (в достаточно примитивных процессорах), где, может, под сотню (Пень-4 с его жутко глубоким конвейером и всё такое), но уж точно не тысячи.
Ещё, кстати, интересно, что будет делать проц, если ветвление предсказано, а команды в кэше нет. По идее, запустит процесс выборки, не дожидаясь точного определения ветвления -- и в случае ошибки это тоже может дорого стоить.
Но я всё это больше к тому, что реальная производительность может очень сильно зависеть от того, насколько хорошо компилятор (или программист) расположил код -- чтоб минимизировать риски кэш-промахов, а тут надо и предсказания ветвлений по возможности учитывать, и адреса размещения и команд, и данных, и команды предвыборки разумным образом вставлять... Ну, это в идеале, конечно :)
Как по мне, зачастую достаточно "правдоподобных рассуждений" -- тем более, что некоторые вещи трудно проверить в реальности. Скажем, создать описанную мной ситуацию (кэш-промах и одновременная занятость нужного банка памяти интенсивным вводом-выводом) на ПК весьма и весьма непросто, если вообще возможно с разумными усилиями, да и на микроконтроллере, где ты работаешь с голым железом и действительно можешь такое создать, за 5 минут демку не набросаешь.
Нет, это показатель того, что не только современные компьютеры могут годами работать без перезагрузки.
Так а если в кэше нет команды, на которую переход? Жди, пока заполнится из памяти. А если в этот момент с этим банком памяти идёт интенсивный ввод-вывод? Жди, пока он не закончится. Вот и набегают тысячи тактов. Так что неверно предсказанный переход может быть крайне дорогим, если рассматривать всю вычислительную систему в комплексе, а не ограничиваться только процессорным ядром.
А что именно, кстати, обслуживали, ежели не секрет? Т.е. какие модели -- может, в этом дело?..
Довольно много чего делалось и у нас, и у болгар. В частности, проц от ЕС-1035 производился и в Минске, и в НРБ; по периферии тоже часто так.
Ну, 133-ю я в измериловке встречал -- но не в ЭВМ. Хотя, возможно, сами приборы изначально делались для вояк и лишь потом появились на гражданских предприятиях.
131-я была -- кажется, в СМ-1600 в проце как раз К131ИП3, а не 531, но за давностью лет утверждать не берусь.
У меня из моих запасов микросхем самая древняя -- триггер К155ТВ1 1973 года (ещё со старым обозначением, К1ТК551, вроде б). С год назад его специально нашёл, запустил -- работает-с :)
В общем, думаю, тут как повезло (например, на каком конкретно заводе производили микросхемы).
С периферией у нас всё сильно хуже было, если говорить про качество и надёжность. Да и с самими носителями тоже. Были, например, НМЛ ЕС-5025 (если склероз не изменяет), обеспечивающие плотность записи и 32, и 64 бит/мм. Наши ленты на 32 работали, на 64 -- фигвам, а буржуйские (басфовские, вроде б) -- без проблем. Т.е. сам наш НМЛ, получается, реально мог работать на этой плотности (впрочем, у IBM за лет 10 до этого уже была 246 бит/мм), а нормальную ленту производить так и не научились (во всяком случае, доступную обычным предприятиям).
Дык тогда и было -- вторая половина 1980-х и 90-е. Электроника дохла очень редко. У одной из знакомых СМ-1420 примерно за 10 лет -- одна КР531ИП3 в диспетчере памяти (MMU) и ещё пару отказов электроники в периферии; у одной СМ-1600 постоянно дохли К170-что-то-там в синхронном последовательном интерфейсе, забыл его шифр, но всё остальное работало много лет без проблем; в ЕС-1035 постоянно дохла только оперативная память (К565РУ1, с темпом микросхема в месяц, но код Хэмминга спасал, давая нормально отработать смену), логика -- очень редко (ну, за те же примерно 10 лет несколько микросхем заменили), в проце ЕС-1130 за больше 5 лет сдохла одна К1800ВС1 и, кажется, всё (вот с дисками ЕС-5080 там проблемы были постоянные -- но это уже не чистая электроника). Так что всё вполне надёжно было. Ну а так -- да, в СМках и большинстве ЕСовской периферии -- 155, 555, 531 и небольшое количество БИС (те же КР1804ВС1 в проце СМ-1420), в ЕСках -- в основном, 500-я серия...
А на сервисное обслуживание просто забили -- спирт же по нормам выписывают, а не по факту обслуживания :) Мужикам (на одном довольно крупном машиностроительном предприятии, я на другом работал, но общались постоянно) интересно стало, сколько машина проработает, поэтому и не выключали. (Основная работа была готовить перфоленты и всё такое прочее для станков с ЧПУ и что-то там умное считать -- ну и змейку гонять, конечно).
А я вот знаю одну СМ-1420 под управлением ОС-РВ, в девичестве RSX-11M, которая без перезагрузки работала несколько лет (что странно, за это время не было поломок не только в чистой электронике -- к тому времени делать её надёжно у нас уже научились, но даже в дисках -- хотя, может, про них уже подзабыл, их на машине несколько штук, поэтому можно было выводить из действия и подключать обратно по мере необходимости). Так что код коду рознь, и качество может быть совершенно различным. Нынешний код, если брать "в среднем по больнице", пожалуй, будет хуже -- но это следствие снижения порога входа в профессию.
Неудачно предсказанное ветвление в современных чипах может стоить сотни, а в особо неудачных случаях -- и тысячи тактов.
Угу, не думали-с. Потому что, в зависимости от того, на чём работал и каков объём программы, компиляция и сборка могли занять и несколько секунд, и несколько часов. Это сейчас хелловорлды мгновенно собираются -- и то лишь с точки зрения человека.
Хотя насчёт... хм... языка... хм... статьи я Вами полностью согласен.
Да там сплошь нерусский русский...
Ничего не сохранилось -- всё было на магнитной ленте, которую мать пустила на верёвку.
Насчёт проблемы я написал: система использовала в качестве консоли пишмашку, а на ЕС-1130 её уже не было, поэтому работа была возможна только на виртуальной машине, где пишмашку эмулировал гипервизор.
Если изоляция -- не с помощью ручного перетыкания кабелей и перещёлкивания переключателей, то возможна, если я правильно понимаю, что такое "живая миграция".
Как по мне, подлинная виртуализация -- это когда программа независимо от того, что она делает, всегда получает одни и те же результаты что при работе на реальной физической машине, что при работе на виртуальной машине. Естественно, при соблюдении двух очевидных условий: 1) результаты не зависят от конкретного времени выполнения, 2) программа не выходит за рамки оговорённого архитектурой -- например, не использует команды, результаты выполнения которых зависят от конкретной модели -- будь то команда ДИАГНОСТИКА на мэйнфреймах или функции и содержимое моделезависимых регистров на IA-32/AMD64.
Полезна, но не необходима. Скажем, на ПК в общем случае невозможно написать и отладить драйвер какой-то железки, используя ВМ, поскольку виртуализация периферии очень плоха, ну а на классической VM/370 такое делалось без проблем.
Моя супер-пупер-мега-ОС, которую я начал лепить на железной ЕС-1035, потом делалась в рамках СВМ ЕС, в девичестве VM/370, на ЕС-1130; на реальной ЕС-1130 я её запускать не мог, поскольку в качестве единственного консольного терминала я использовал пишущую машинку, а у ЕС-1130 её уже не было; поддержку дисплеев я реализовать банально не успел -- хотя наверняка сделал бы, если б продолжал работать на прежнем месте. Так вот, виртуальную память, а отчасти и работу с дисками я доводил до ума уже под СВМ, и это было намного удобнее: работая на ЕС-1035 без СВМ (она не сразу в моём распоряжении появилась), я для трансляции исходников был вынужден загружать ОС ЕС (OS/360), а после трансляции, сборки и записи результата на магнитную ленту -- загружаться с неё и тестировать полученное, что, естественно, сильно тормозило процесс. Под СВМ мне для этого достаточно было переместить свою пятую точку между двумя соседними мониторами, каждый из которых был консолью двух разных виртуальных машин -- на одной работала ОС ЕС, на второй -- моя меганедосистема. Плюс, отладка с помощью СВМ удобней, чем с железного пульта управления машиной (даже в сочетании с пишмашкой, которая в пультовом режиме могла распечатывать память или позволять её изменять, ну и всё такое прочее).
Ну что ж, вот теперь мне ясно, что реально Вы не понимаете, что такое виртуализация и как она реализуется технически, и Вы не понимаете, как в реальности работают операционные системы вообще. Вопросов больше не имею.
На самом деле, этот подход, хотя и более-менее работает на практике, в теории не даёт 100% виртуализации: например, программа может "на лету" модифицировать свой собственный код (это, например, делали первичные обработчики прерываний ввода-вывода и внешних прерываний в классической OS/360). Очевидно, что гипервизор не заметит подобной модификации, поскольку технически это обычная запись в память. (Да, я знаю, что можно запретить запись в страницы памяти, занимаемые кодом, -- но кто сказал, что это не будут страницы с данными? В упомянутой OS/360 всё это происходит в самой первой странице размером 4 Кбайта, где лежат и начала обработчиков прерываний, и куча системной информации, которая должна быть доступна и на чтение, и на запись). Или, например, нечто было формально загружено как данные, а потом исполняется как программа (тоже реальные случаи из OS/360). В общем, этот подход в общем случае не работает, и единственной гарантированной возможностью "виртуализировать" условный 80386 на нём самом является интерпретация всего кода вообще -- даже непривилегированного, ведь в непривилегированном режиме потенциально могут работать части ОС, готовящие информацию для привилегированного режима (скажем, в истинно микроядерной системе). Собственно, это подход более-менее работает как раз потому, что он применяется лишь к узкому кругу "стандартных" ОС с хорошо известным поведением, в то время как классическая VM/370 на классических мэйнфреймах сможет успешно работать с любой ОС или системно-независимой программой.
Ну а если подобные команды являются строго привилегированными, никаких проблем не возникает: они гарантированно "попадут в лапы" гипервизору. Да и производительность, по итогу, окажется ещё и больше: в любом случае надо переключаться из непривилегированного в привилегированный режим, но хоть не надо анализировать код программы.
В общем, как по мне, это как раз полнейшая катастрофа в плане виртуализации -- если только разработчики не предусмотрели "отключение" этой команды каким-то подпольным образом. Такое вполне может быть предусмотрено, но я отнюдь не исключаю, что они либо действительно идиоты (в конце концов, идиотскую архитектуру IBM PC и его BIOS с целой кучей нелепостей именно в IBM придумали), либо просто решили забить на виртуализацию.
Какая такая приилегированная информация имеется в PSW программы? Формат PSW надеюсь Вам известен и Вы можете указать на байты и биты с "привелигерованной информациеЙ" и связать это с "нарушением возможности виртуализации". Прошу.
===========================
Конкретно по битам для 128-разрядного PSW: биты 0:17 и 24 (не считая разрядов, которые пока что не используются и равны нулю), содержат привилегированную информацию, которую от выполняемой программы необходимо скрывать, чтобы обеспечить полноценную виртуализацию. Непривилегированной информацией являются код условия (18:19), маска программы (20:23) и адрес команды (64:127). И именно привилегированную информацию EPSW возвращает программе (биты PSW[0:11,13:31]) -- т.е. делает ровно то же самое, что делают весьма многочисленные команды 80286 и 80386, из-за которых позже Интелу пришлось приделывать костыль для виртуализации.
Код, выполняющий подобные команды при работе на реальной машине, получит корректную информацию о состоянии процессора -- в частности, о том, работает ли он как код пользователя или супервизора и каково состояние масок прерываний и т.п. На основе этой информации он принимает решение, что делать дальше (например, системная по своей сути программа, если обнаружит, что была вызвана кодом пользователя и поэтому работает в режиме пользователя, может запросить у ядра переход в режим супервизора, если это ей для чего-то необходимо; или ей нужно переключить режим переадресации; или ей нужно сменить ключ доступа к памяти; или ей нужно понять, разрешены или запрещены прерывания или PER). При выполнении же на виртуальной машине эта же команда вернёт логически неверную информацию -- а именно ту, которая отражает состояние реального процессора, а не виртуального (и эта же самая гипотетическая программа увидит, например. что она работает в режиме пользователя с ненулевым ключом, хотя логически она должна выполняться в режиме супервизора с нулевым ключом -- просто PSW будет считан реальный, а не виртуальный).
Ещё раз повторяю: это абсолютно та же самая ошибка, что была допущена архитекторами Интел. Если для Вас это не очевидно, я тут бессилен.
Бред -- не команда LPSW, а Ваше утверждение в ответ моё утверждение:
================
Не надо торопиться обвинять.
Нарушением была бы возможность изменять состояние задача/супервизор. Это можно сделать только командой загрузить новое PSW. Это привилегированная команда.
=================
Ещё раз повторяю: нарушением является факт возможности получения привилегированной информации непривилегированным кодом. Вы, похоже, этого не понимаете, иначе не было бы ни вышеприведённого Вашего утверждения, ни вот этого:
Ещё раз повторяю: проблема интеловской архитектуры -- в существовании команд, которые позволяют прикладному коду читать системные сущности (адреса таблиц описателей, например). Любые команды, подобные мэйнфреймовской LPSW, на 80286 и последующих процессорах являются привилегированными. И появление EPSW точно так же разрушает возможность виртуализации в мэйнфреймах.
В "Принципах работы" -- не описано. Я не утверждал, что это вообще нигде не описано, я утверждал, что не описано в "Принципах работы", и что реальные мэйнфреймы работают сложней, чем там указано.
Ну так разберитесь с тем, в чём реальная причина невозможности виртуализации на интеловской архитектуре, а не просто отмахивайтесь от неё, -- тогда и не будете писать бред и слышать в ответ обидное. Я, извините, политкорректностью не страдаю и если вижу бред, то так и говорю.
А специалистом я ни разу не являюсь, я последний раз программировал для мэйнфрейма в 1993 или 94 году (на советской ЕС-1130), а в последний раз обслуживал её как электронщик или системщик -- году эдак в 98-м. Ничего современнее Системы 370 в виде советских машин я в моей реальной жизни даже не видел.