Comments 48
Программа не может перевести процессор в останов, переход в это состояние всегда является следствием внешних событий
Я встречал упоминание о ещё двух вариантах:
Срабатывание схем аппаратного контроля может сразу перевести ЦП в останов, а не вызывать соответствующее прерывание.
Некорректное PSW программных прерываний на некоторых моделях также может перевести ЦП в останов.
Останов при срабатывании схем контроля -- это так называемый тяжёлый останов. Отличается от обычного, в частности, тем, что при нём нельзя процессор просто взять и запустить -- он будет стоять, пока не будут сброшены признаки ошибок. Архитектурой сие никак не регламентируется, так как является полностью зависящим от реализации. Ну а обычный останов -- это именно что архитектурное состояние, общее для любых моделей.
Это уже зависящее от реализации поведение. В общем случае процессор уходит в бесконечную цепочку прерываний, выйти из которой можно только сбросом (что тоже регламентируется архитектурой).
Вы уж поправьте 2020 или 1020, кстати я обслуживал дисковую подсистему.
А вот интересно, насколько по сложности разные машины серии ЕС больше или меньше классической СМ-4?
ЕСки очень, Очень, ОЧЕНЬ сильно сложнее, чем СМки. Недаром процессор СМки -- один ящик в стойке, а ЕСки -- вся стойка, а у некоторых каналы -- ещё одна стойка.
А насколько оправдана эта сложность была? Мне тогда казалось что СМ PDP красива, особенно система команд, а ЕС IBM урод и там много костылей.
А если сравнить с младшими вариантами VAX, где и памяти сравнимо, и виртуальная память, и 32 бит, кластера итд?
Ну, система команд PDP-11, как по мне, -- лучшая среди 16-разрядных, а VAX-11 -- среди 32-разрядных, но, как говорится, есть нюансы.
Адресация у DECовских машин более гибкая и эффективная, что, естественно, способствует сокращению объёма программы и потенциально -- повышению производительности. В то же время базовая система команд Системы 360 более проста для реализации (пять чётких форматов команд, не имеющих значимых с точки зрения выборки-декодирования исключений, более простая адресация -- обычная сумма одного-двух регистров и смещения, без всяких модификаций регистров, косвенной адресации и т.п.), и её намного проще "положить на конвейер" -- уже первые старшие модели Системы 360, как и наша ЕС-1050, были конвейерными, и, понятно, по производительности рвали любую PDP-11 как тузик грелку. Сделать конвейерную PDPшку или VAX... можно, но значительно сложней (а соответственно, куда больше логики нужно -- и на тогдашнем технологическом уровне это было недостижимо из соображений стоимости и габаритов).
Кроме того, система команд у Системы 360 побогаче будет, а в дальнейшем она всё расширялась и продолжает расширяться -- при этом умудряются не сломать совместимость и поддерживать простоту кодирования (сейчас, например, какое-нибудь там шифрование выполняется одной командой -- и, естественно, обеспечивается намного более высокая производительность, чем у самого навороченного "обычного" процессора, где это надо делать программно). Наличие команд десятичной арифметики, например, резко упрощает жизнь разработчикам экономических приложений -- не надо никаких мер предосторожности, чтоб результаты получались такие же, как при ручных вычислениях (в двоичной возможны нюансы из-за округления; плюс диапазон представимых чисел -- госдолг США, как мы помним, стало возможным хранить лишь в 64-разрядном регистре, ну а в Системе 360 -- запросто, там двоично-десятичные числа лежат в памяти и могут иметь до 31 цифры плюс знак; в PDP-11, кстати, теоретически присутствовал "коммерческий набор команд" -- CIS, но, похоже, встречался крайне редко). Команда TRT (одна из "костыльных" в том плане, что один из операндов является неявным и лежит в строго определённом регистре -- полей для кодирования не хватало) резко упрощает написание программ разбора текста (на ней, грубо говоря, половина лексического анализатора любого ассемблера/компилятора держится). Есть пересылка сразу порции данных (до 256 байтов), а также логические операции над байтовыми полями переменной длины -- соответственно, обнулить память можно куда быстрей, чем чисто программно в цикле (во всяком случае, теоретически: зависит от особенностей реализации; скажем, продвинутая модель, увидев "исключающее или" с одним и тем же стартовым адресом, может просто обнулить эту память, причём, естественно, не побайтово, как предполагается концептуально, а на всю ширину физического доступа в конкретной модели).
Ещё один аспект -- ввод-вывод. У Системы 360 он логически отделён от процессора и свален на каналы, что потенциально, не выходя за рамки архитектуры. позволяет реализовать очень быстрый обмен. У PDPшки всё висит на единственной довольно медленной шине; интенсивный обмен с диском запросто затормозит работу процессора и т.д. (Понятно, что у младших, а отчасти и средних моделей Системы 360 та же проблема -- но она вытекает не из архитектуры, а из реализации; в старших моделях процессор и каналы работают подлинно параллельно и тормоза возникают лишь при одновременном обращении к одному и тому же, выражаясь более современными терминами, банку памяти, -- но там выручает кэш, который у старших моделей появился довольно быстро, хотя у самых первых ещё не было, вроде бы). Поэтому для управляющих применений (где надо постоянно опрашивать битики в регистрах устройств и т.п.) PDPшка или, скажем, современный ARM подходит куда лучше, но вот при обработке больших массивов информации -- наоборот. (Попутно замечу, что великолепнейшая виртуализация машины, реализованная ещё в начале 1970-х в VM/370, так и осталась непревзойдённой по сей день -- если не считать z/VM, конечно, но она -- наследница VM/370 и работает на z/Architecture, выросшей из Системы 360 и сохранившей с ней совместимость на прикладном уровне; во многом она достигнута именно благодаря унифицированному вводу-выводу: гипервизору ничего не нужно знать про работу внешних устройств, если с ними умеет работать гостевая ОС -- он просто преобразует канальные программы в плане физических адресов памяти да передаёт их каналам на выполнение; в той же PDPшке виртуализация... как минимум, проблематична, в IA-32 aka x86 и вовсе невозможна без специальный аппаратной поддержки из-за абсолютнейшей кривизны архитектуры -- Интел, кажется, смогла воплотить все мыслимые и немыслимые архитектурные ошибки...)
Добавьте к этому аппаратный контроль. У PDPшек контролировали разве что чётность оперативной памяти и памяти микропрограмм; у Системы 360 контроль намного более полный, причём во многих более поздних моделях имеются средства восстановления, зачастую позволяющие продолжить работу при случайных сбоях, а уж обнаруживать проблемы вообще в 100% случаев (в младших моделях, особенно ранних, -- в частности, в ЕС-1020, -- он не такой полный, поэтому некоторые сбои будут оставаться "незамеченными", но большинство вещей всё ж контролируется; в частности, АЛУ выполнено в двух экземплярах, и результаты его работы сравниваются -- вот и куда больший объём аппаратуры по сравнению с СМками, ведь тогдашнее АЛУ -- это половина процессора).
Система 360 изначально предполагала возможность построения многопроцессорных систем. Правда, в этой версии архитектуры это было проработано довольно плохо, но опыта-то не было. Когда набрались, многое переделали -- уже в Системе 370, и это сохраняется до сих пор (с некоторыми расширениями).
Насчёт костылей в системе команд Системы 360 не согласен :) Они там есть, конечно, но их, пожалуй, меньше, чем в PDP-11, и существенно меньше, чем у VAX, хотя система команд по функционалу богаче PDPшки. Например, команда XOR в PDPшке -- костыльная по сравнению с остальными, у неё один из операндов обязательно должен лежать в регистре; имеется совершенно дурацкая команда... ээээ... MARK, кажется (вроде б компилятором Фортрана используется, но уж не помню столь интимные подробности); нет логических сдвигов (только арифметические), ещё там что-то было... MMU на многих моделях не позволяет реализовать полноценную виртуальную память (с загрузкой/выгрузкой задач по частям -- поскольку не обеспечивает правильный "откат" при прерывании в процессе выполнения команды), а там, где позволяет (PDP-11/70, например), это делается программными плясками (ОС должна сама выполнить "откат", MMU просто сохраняет нужную для этого информацию в одном из своих регистров) -- ну а в мэйнфреймах, когда виртуальную память сделали (в Системе 370, причём не сразу -- но очень быстро), сразу сделали правильно (принципиально она ничем не отличается от современных архитектур -- те же самые таблицы переадресации в памяти).
У вас, конечно, ну очень пристрастный взгляд. Ничуть не против, но всё же )
MARK не сильно большее извращение, чем тот-же TRT. Оба – трюки, придуманные под конкретный запрос.
Первый – потому что оказалось, что кроме подпрограмм (под которые обычный RET и сконструирован) есть ещё и функции, а им надо передавать аргументы, и лучше на стеке, и при возврате надо как-то указатель стека правильно передвигать. Дичь, конечно, но очень занятное решение.
Второй – я вообще не знаю, как TRT появился. Есть подозрение, что делали под криптографию, но очень может быть, что оно оттуда же, откуда вся эта сложная кухня с адресацией: Бэкус насоветовал, чтобы Фортран удобнее компилировать было.
И вообще, если уж ассемблеры сравнивать в смысле instruction set architecture – то WASM точно самый красивый )
Ну почему пристрастный. Я на PDPшках (СМках, точней, -- но не суть) прилично программировал на асме, и, как уже сказал, считаю его лучшим из 16-разрядных. Просто там тоже свои извраты есть, как и везде.
А причём здесь WASM, кстати? Это ж не архитектура проца, чтоб иметь свою систему команд.
А причём здесь WASM, кстати? Это ж не архитектура проца
Ну так у /360 архитектур процев и окружений тоже много всяких, а ассемблер более-менее един. Wasm в каком-то смысле тоже единый ассемблер для очень разных архитектур и окружений, причём такой, в котором куча детских болезней вполне уже взрослых архитектур генетически невозможна.
В реальный машинный код оно преобразуется однопроходным транслятором, так что считайте что у вас в процессоре просто второй декодер опкодов и второй слой микрокода, который реализует стековую машину.
Что же касается сравнения с VAXом, то с ним корректней уже будет сравнивать поздние варианты Системы 370, а не ранние Системы 360 -- ведь между ними 10, если не больше, лет разницы. "Общая" система команд у VAX приятней будет, в общем и целом; в отдельных вещах он лучше и в специальных случаях, а Система 370 -- в других (десятичную арифметику, кажется, никто лучше так и не сделал -- одна из причин доминирования мэйнфреймов в финансовом секторе). По вводу-выводу VAX сильно уступает -- как уступает и любая современная архитектура (попробуй подключить к ПК -- именно к ПК, не по локалке, -- тысячи дисков, и чтоб оно ещё и летало, -- ну а к мэйнфрейму z/Architecture -- запросто, если у тебя есть деньги на эти тысячи дисков :) ).
На поздней Системе 370 появился механизм двойного адресного пространства (впоследствии расширен до множества адресных пространств), что резко упрощает и ускоряет реализацию программ-серверов, обслуживающих программы-клиенты. Без этого механизма вызов подпрограммы в сервере надо производить через ядро ОС, с ним -- можно вызывать прямо, при этом привилегии у клиента и сервера разные, но всё контролируется и защищено. У VAX ничего подобного я не видел -- хотя с поздними вариантами не знаком. В IA-32 было "жалкое подобие левой руки" -- таблицы дескрипторов со шлюзами вызова позволяют, теоретически, добиться того же, но всё было спроектировано настолько криво, что этими возможностями никто не пользовался (и AMD выпилила их, делая 64-разрядный вариант архитектуры, -- что впоследствии скопировала Интел, провалившись со своей IA-64 aka Itanium). В общем, в плане системной архитектуры, на мой взгляд, Система 360 и её наследники -- лучшее, что было и есть. По системе команд -- VAX лучше, если не брать частности (которые в него вполне можно было бы добавить, конечно). По простоте реализации -- безусловное превосходство Системы 360 (ну, это неудивительно: в первой половине 1960-х развернуться было особо негде, железо ограничивало -- отсюда, кстати, ряд костылей и неудачных решений, и в первую очередь -- 24-разрядный адрес памяти; просто, похоже, никто не думал, что через 20 лет этого будет мало). По гибкости ввода-вывода -- превосходство VAX, но по пропускной способности -- Системы 360.
В общем, разные архитектуры друг друга не исключают, а дополняют. Ставить Систему 360 в качестве управляющей машины -- верх идиотизма, пытаться заменить один мэйнфрейм тыщей персоналок -- примерно то же самое. Надо исходить из задачи и выбирать адекватные средства.
Спасибо за подробный ответ
На VAX помнится, системные библиотеки отображались в верхние 2 гига read-only, так что большинство вызовов не требовали смены адресного пространства
А зачем 1000 дисков? Поставить их вы бы смогли и каналы. А по конфликтам с памятью? Вот если бы в программе канала можно было бы написать raid... Но вроде в канале были очень примитивные программы
А зачем сейчас столько дисков ставят? Хранение и обработка гигантских объёмов информации, естественно.
Канальные программы -- да, примитивные, но свою задачу (разгрузку ЦП от управления вводом-выводом) вполне себе выполняют.
Про конфликты с памятью вроде сказал уже. Если память разделена на несколько банков, то, пока обращения идут к разным банкам, их легко распараллелить средствами многопортового контроллера памяти; кстати говоря, на СМках с 4 Мбайтами память была двухпортовой: один порт для проца, второй -- для периферии. Просто в Системе 360 проще распараллеливать, поскольку память там является единственной общей точкой -- ну а в более привычных архитектурах процессор напрямую обращается к устройствам и ими управляет, что требует обеспечить соответствующую связь, т.е. делать или общую шину, или огромное количество соединений точка-точка с коммутаторами, -- первое медленно, когда устройств много (некритично для мини-ЭВМ, но недопустимо для мощного мэйнфрейма), второе -- очень сложно и затратно по железу.
На VAX помнится, системные библиотеки отображались в верхние 2 гига read-only, так что большинство вызовов не требовали смены адресного пространства
В VM/370 так тоже было сделано, не обязательно 2 гига – на сегментной основе, и настраивалось на уровне отдельных приложений. Это называлось “разделяемые сегменты”. В частности, XEDIT в CMS, помнится, был один в разных адресных пространствах.
Если память не изменяет, в VAX разделение памяти на 2 нижних гига и 2 верхних навязывалось архитектурой, -- но, возможно, с чем-то путаю, а искать сейчас лениво :) Ну а в Системе 370 и последующих у всей памяти полное равноправие. Вообще, в смысле системной архитектуры IBMовские мэйнфреймы -- пожалуй, самые прямые из всех машин (а одни из самых кривых, если не самые кривые, -- ПК :) ).
Если память не изменяет, в VAX разделение памяти на 2 нижних гига и 2 верхних навязывалось архитектурой
Да, у VAX принципиально четыре квадранта, один в резерве, один для супервизора (ОС), таблицы у них различны. Их можно менять по частям.
И, кстати, вот это как раз лучше чем то, что в x86, S/370, RISC-V и прочих, где таблица одна на всех (ну, у S/370 другие факторы могут смягчать?) Трансляция области супервизора в общей памяти обычно поддерживается одинаковой на все процессы. При этом, если в корневом каталоге меняются записи нижележащих каталогов, надо их менять для всех процессов. Часто это оставляют на момент переключения процессов, держа учёт поколения этого подсписка каталогов. Это не сложно - один раз написать - но громоздко. У AArch64 два каталога страниц, на нижнюю и верхнюю область, но граница между ними регулируется, а не жёсткая, как у VAX.
Ещё у VAX плохо было сделано, что нет иерархии каталогов, а вместо этого на каждый квадрант один плоский каталог. Толстые процессы вследствие этого было сложно расширять, могло оказаться, что нет связного куска памяти для каталога пошире.
Ну, у Системы 370 двухуровневые таблицы переадресации, поэтому там достаточно гибко можно было сделать и расширять. У современных z/Architecture -- пятиуровневые, но идея та же самая, хотя и расширенная. Скажем, таблица сегментов (второй снизу уровень -- и верхний в Системе 370) может указывать не на начало таблицы страниц, а задавать сразу положение всего сегмента в физической памяти -- тем самым избавляя от нужды иметь таблицу страниц в случае, если сегмент всегда отображается или не отображается целиком.
Скажем, таблица сегментов (второй снизу уровень -- и верхний в Системе 370) может указывать не на начало таблицы страниц, а задавать сразу положение всего сегмента в физической памяти -- тем самым избавляя от нужды иметь таблицу страниц в случае, если сегмент всегда отображается или не отображается целиком.
В x86, RISC-V и прочих той же конструкции - "не отображается целиком" было с самого начала (и странно было бы если б сделали иначе). А вот "всегда отображается" представлено в x86 в виде superpages (2MB или 4MB) или hugepages (1GB); 4MB появились с PSE36, 2MB и 1GB страницы - с PAE. Оно используется относительно мало, я видел массовое использование только в HPC приложениях, где хотят исключить затраты на трэшинг TLB (кэша страничной адресации) на каждую маленькую страницу. (В типовом процессоре x86 несколько тысяч записей в TLB. Например, если 1024, как пишут для Haswell, то это только 4MB на минимальных страницах. А там нормально иметь матрицы на гигабайты. Страницы усиленного размера резко сокращают тут затраты на эти поиски.)
Что за "весь сегмент" в 370, я не понял. Если весь адрес в 24 или 31 бит, а корневой каталог покрывает 32 бита, то перемещать сегмент с нулевого адреса больше некуда.
Что за "весь сегмент" в 370, я не понял. Если весь адрес в 24 или 31 бит, а корневой каталог покрывает 32 бита, то перемещать сегмент с нулевого адреса больше некуда.
В 370 адрес только 24 бита, 31 бит появился лишь в 370-XA (в последних 370 он был для ввода-вывода, но не для процессора, поэтому не в счёт).
Сегменты же -- верхний уровень переадресации в 370, ниже них -- страницы; соответственно, для переадресации в управляющий регистр заносится адрес начала таблицы сегментов; каждый элемент таблицы сегментов содержит адрес соответствующей таблицы страниц, ну а элементы таблиц страниц -- реальные адреса соответствующих страниц в памяти (ну или индикацию отсутствия страницы).
В исходной реализации виртуальной памяти в 370 можно было управлять длиной таблицы сегментов и длинами таблиц страниц, чтобы не хранить ненужные элементы, но нельзя было обойтись без таблиц страниц вообще -- а соответственно, хошь-не хошь, а отображай память страницами по 2 или 4 Кбайта, даже если в реальности отображение выполняется целым сегментом (64 Кбайта или 1 Мбайт). В современных же z/Architecture 5 уровней: внизу -- страницы, над ними -- сегменты, а выше -- три уровня регионов, ну и была введена возможность отображать сразу целыми сегментами, а чуть позже -- и регионами 3-го уровня, а не отдельными страницами. Благодаря этому можно избавиться от таблиц страниц (и таблиц сегментов), если в конкретном случае выгоднее отображать виртуальную память более крупными блоками (сегментами или регионами третьего уровня). Понятно, что это востребовано на "тяжёлых" системах, почему на IA-32 (x86) аналогичные вещи используются только в HPC приложениях, как Вы написали, но, подозреваю, на мэйнфреймах это используется куда чаще в силу специфики их применения.
По вводу-выводу VAX сильно уступает -- как уступает и любая современная архитектура (попробуй подключить к ПК -- именно к ПК, не по локалке, -- тысячи дисков, и чтоб оно ещё и летало, -- ну а к мэйнфрейму z/Architecture -- запросто, если у тебя есть деньги на эти тысячи дисков :) ).
Нетъ. Представим себе чуть другую реализацию для S/360: что там бы использовалось отображение на память, и, например, вместо SIO было бы: проверить слово по адресу CB (channel base), что он ещё может принять одну команду; записать в CB+4 адрес первой CCW, в CB+8 адрес устройства, и в CB+12 константу 1 (SIO), а дальше канал исполняет работу сам. Отличалось бы это по эффективности от команды SIO процессора? Безусловно, нет.
И именно этот подход, с точностью до маппинга значений и адресов, используется сейчас в контроллерах NVMe, AHCI, разных USB хостах, продвинутых сетевухах (да даже NE2000 уже сама делала ввод-вывод), в общем, в любом лаптопе x86 это в полный рост. Ещё раньше - в SCSI контроллерах, на которых уже в 80-х держали десятки дисков в корзинах.
Главное - чтобы скорости всех промежуточных участников, типа системной шины, хватало на это.
Так что насчёт "уступает и любая современная архитектура (попробуй подключить к ПК -- именно к ПК" вы совершенно неправы. Подключить можно, результат тот же - и он реально достигается в достаточно толстых серверах. Просто смысла реально нет на один сервер подключить тысячу дисков. А вот один и чтобы с SSD туда-обратно одновременно ходило до 256 (реально) или до 65536 (ни один контроллер не умеет, но тег на NVMe - 16 бит) операций и чтобы диск их отрабатывал впараллель, как ему удобно - это в полный рост.
А на PDP-11, VAX и прочих это не делали именно потому, что не было возможности впихнуть полный набор подобных средств в доступные ресурсы, в отличие от. Но дисковые контроллеры с собственным DMA - делали. А когда в PCI ввели возможность bus mastering для каждого устройства, стало понятно, что и для уровня PC это пришло.
Метод с канальными программами и командами управления типа SIO (SXCH) - хорош, конечно, для работы из виртуальной машины, не нужно отслеживать каждую операцию с регистрами устройства в MMIO. Но можно и устройство сделать так, чтобы виртуализировалось без проблем - и это сейчас делают, например, в Infininiband контроллерах, выделяя по странице DAT на подустройство.
Зато через канальные программы неудобно делать некоторые другие вещи. Например, почему-то:) в этой линии таймеры сделаны через память или через отдельные команды процессора. Или вот ожидание прихода данных с сетевого адаптера: это означает в канальной архитектуре запустить операцию чтения и она может неопределённое время (секунды и больше) висеть в ожидании чуда. Это поэтому в S/370 сделали много "субканалов" на устройство? По сути таки костыль.
Главное - чтобы скорости всех промежуточных участников, типа системной шины, хватало на это.
Вот именно. Это всё упирается в производительность PCIe. В то время как у каждого канала связь с устройствами своя.
В то время как у каждого канала связь с устройствами своя.
Вы криво прочли. На SCSI шине, например, связь каждого "канала" (контроллера) с устройствами своя, там уже нет общего PCIe.
В пределах одного контроллера SAS.
Но контроллер SAS сам по себе, если не брать совершенно экзотические сценарии, не является конечным источником или потребителем данных, поэтому дальше всё равно поток данных приходит в общую шину PCIe. Контроллер в PC, в отличие от канала мейнфрейма, не может же выполнять DMA в обход PCI.
Контроллер в PC, в отличие от канала мейнфрейма, не может же выполнять DMA в обход PCI.
Ваше предложение неуместно. "Контроллер канала мейнфрейма" должен так или иначе получать доступ к памяти. Значит, между ними есть какая-то шина (группа шин). Это аналог PCI (любого PCI) для архитектуры на нём, и вопрос в организации и производительности одной конкретной шины, а не в общем принципе.
Детали зависят уже от того, как эта шинная структура организована. И тут нет причин фиксироваться именно на PCI. Тот же Infiniband используется в некоторых ну очень продвинутых версиях (и PCI формально бегает поверх него).
Вопрос в том, что каналы в мейнфрейме подключены к многовходовой оперативной памяти независимо, а в PC через общую шину.
Конечно, можно воспроизводить мейнфрейм и прокидывать PCI через коммутируемую сеть Infiniband. Как и можно канал воспроизводить на шине PC, как в P/390. Но всё равно аппаратно это разные архитектурные решения, даже если они могут эмулировать ABI друг друга.
Отображение устройств на память намного более гибко по сравнению с каналами Системы 360, и с этим спорить глупо. И, кстати, это одна из причин, почему данная архитектура отнюдь не покрывала все "360 градусов" потребностей пользователей: сделать из неё управляющую машину... сложно, скажем политкорректно :)
Но вот пропускная способность системы ввода-вывода у неё сильно выше по сравнению с "шинными" архитектурами вроде PDP-11 и VAX-11. Причём замечу, что даже появление Massbus (лет через 10, если не больше, после появления интерфейса ввода-вывода Системы 360) эту проблему не решил, а лишь снизил.
Поэтому, если тебе нужно управлять условным станком, там какая-нибудь PDP-11 однозначно лучше. Но если ты обрабатываешь 100500 банковских транзакций, то даже PDP-11/70 (вероятно, самая производительная из PDPшек 1970-х годов) проиграет средненькому, но грамотно сконфигурированному мэйнфрейму аналогичного времени.
Подканалы (субканалы, как Вы их называете) -- чисто логическая сущность; по сути, это управляющая информация, хранящаяся в памяти канала и используемая при работе с конкретным устройством. В 370-XA ввод-вывод сильно пересмотрели в том плане, что стали управлять не каналами, а напрямую подканалами; теоретически, появилась возможность иметь хоть свой персональный интерфейс для каждого устройства, а работа одного подканала никак не мешает работе другого подканала. На практике, понятно, ограничения есть, но эта модернизированная модель ввода-вывода позволяет смягчать ограничения на уровне железа, где это надо (скажем, вместо одного блок-мультиплексного канала, где в любой момент времени возможен обмен данными только с одним устройством, хотя в ожидании передачи могут находиться несколько устройств, можно сделать дюжину отдельных интерфейсов, к каждому из которых присобачить отдельную группу внешних устройств -- и добиться, тем самым, физически одновременного обмена данными).
Ну и виртуализация, да. По сути, гипервизору (монитору виртуальных машин) можно вообще ничего не знать про периферийное устройство, если с ним умеет работать гостевая ОС -- ему достаточно знать адрес этого устройства, и всё. Любые запросы гостевой ОС он корректирует в плане адресов памяти и адреса устройства, и сей процесс полностью унифицирован вне зависимости от типа устройства. Потому VM/370 и её последователи так и остались непревзойдёнными в плане технического качества виртуализации. (Ну а на IA-32, как известно, из-за кривизны архитектуры без специальной аппаратной поддержки, появившейся лишь очень поздно, виртуальные машины были вообще невозможны).
Но вот пропускная способность системы ввода-вывода у неё сильно выше по сравнению с "шинными" архитектурами вроде PDP-11 и VAX-11. Причём замечу, что даже появление Massbus (лет через 10, если не больше, после появления интерфейса ввода-вывода Системы 360) эту проблему не решил, а лишь снизил.
Тут рядом уже обсуждалось, и я думаю, что эти машины в принципе не предполагали тут настолько серьёзного ускорения - потому что стоило бы сразу резко больше.
Ну и виртуализация, да. По сути, гипервизору (монитору виртуальных машин) можно вообще ничего не знать про периферийное устройство, если с ним умеет работать гостевая ОС -- ему достаточно знать адрес этого устройства, и всё. Любые запросы гостевой ОС он корректирует в плане адресов памяти и адреса устройства
Это если трансляция 1:1 на внешнее устройство или на его часть (в стиле LPAR). Но часто требуется логика посерьёзнее.
Потому VM/370 и её последователи так и остались непревзойдёнными в плане технического качества виртуализации.
Вот тут вопрос, насколько это зависит от формата запросов ввода-вывода, а насколько от того, что гостевые системы помогают в виртуализации.
Ну а на IA-32, как известно, из-за кривизны архитектуры без специальной аппаратной поддержки, появившейся лишь очень поздно, виртуальные машины были вообще невозможны
Это разные вопросы. Сделать в IA-32 полное соответствие входным условиям виртуализации в виде классического Попека-Гольдберга было банально, это один вопрос (добавили бы флажок в регистр) - а вот текущий подход с теневыми регистрами и двухуровневым DAT сильно меньше требует паравиртуализации, было достаточной причиной, чтобы его вводить.
Тут рядом уже обсуждалось, и я думаю, что эти машины в принципе не предполагали тут настолько серьёзного ускорения - потому что стоило бы сразу резко больше
Ну, потому и неразумно хвалить/осуждать некую архитектуру за (не)соответствие тем или иным задачам. Можно, разве что, поругать пиарщиков IBM за их "360 градусов", что ни разу не правда даже на момент появления этой архитектуры -- но верить пиарщикам...
Это если трансляция 1:1 на внешнее устройство или на его часть (в стиле LPAR). Но часто требуется логика посерьёзнее.
Да понятно, что есть. Но возможность вот просто взять и отобразить, ничего не меняя в гипервизоре, весьма и весьма полезна хотя б для разработчиков новых устройств и осей (драйверов).
Вот тут вопрос, насколько это зависит от формата запросов ввода-вывода, а насколько от того, что гостевые системы помогают в виртуализации.
Гостевая система может даже не подозревать о том, что работает на виртуальной машине -- и всё будет работать. Конечно, если она знает и помогает, выполнение будет эффективнее, но уже второй вопрос.
Это разные вопросы. Сделать в IA-32 полное соответствие входным условиям виртуализации в виде классического Попека-Гольдберга было банально, это один вопрос (добавили бы флажок в регистр) - а вот текущий подход с теневыми регистрами и двухуровневым DAT сильно меньше требует паравиртуализации, было достаточной причиной, чтобы его вводить.
Ну дык не сделали ж соответствие -- причём уже имея возможность ознакомиться с чужим опытом (80386 -- это ближе к середине 1980-х, а VM/370 -- 1971-й, если память не изменяет). Вообще, в Интеле всю жизнь архитекторы были... странные.
Ну а наличие специальной поддержки виртуализации -- вещь полезная, с этим никто не спорит. Однако в любом случае факт остаётся фактом: на Системе 370 можно было реализовать ВМ, не имея никаких технических средств поддержки виртуализации, кроме собственно обычного механизма виртуальной памяти и обычного же разделения режимов выполнения на пользователь/супервизор, а в IA-32 это было невозможно. (Кстати говоря, на ЕС-1035 без поддержки виртуализации MVT как гостевая работала, по ощущениям, так же быстро, как и на реальной машине: своей виртпамяти у неё, как известно, нет, поэтому с этой стороны тормозов не было, а тормоза на ввод-вывод были минимальными из-за лёгкости его виртуализации благодаря архитектуре. Понятно, что если проводить точные замеры, производительность была бы всё-таки ниже, но явно не в разы. Вот SVS виртуализировать я не пробовал.)
Ну, потому и неразумно хвалить/осуждать некую архитектуру за (не)соответствие тем или иным задачам. Можно, разве что, поругать пиарщиков IBM за их "360 градусов", что ни разу не правда даже на момент появления этой архитектуры -- но верить пиарщикам...
Ну почему же. Они говорили, что машина годится одновременно для математических, экономических и управляющих задач - чем не 360 градусов? ;) Ну при этом ещё и домен realtime они, скорее всего, просто не предполагали.
Ну дык не сделали ж соответствие -- причём уже имея возможность ознакомиться с чужим опытом (80386 -- это ближе к середине 1980-х, а VM/370 -- 1971-й, если память не изменяет). Вообще, в Интеле всю жизнь архитекторы были... странные.
Тут согласен на 300%, количество и специфику странных решений у них можно обсуждать часами.
Однако в любом случае факт остаётся фактом: на Системе 370 можно было реализовать ВМ, не имея никаких технических средств поддержки виртуализации, кроме собственно обычного механизма виртуальной памяти и обычного же разделения режимов выполнения на пользователь/супервизор, а в IA-32 это было невозможно.
У x86 этому не хватало буквально ограничения нескольких команд (SMSW, SIDT, STR, ещё какой-то, точно не помню). Вполне можно было поставить на них дополнительное ограничение, и получилось бы примерно так же.
Но тут вступает в силу следующий фактор. Виртуализация классического стиля Попек-Голдберг предполагает, что хозяйская система ведёт теневые страницы механизма DAT, иначе не может справиться с трансляцией. (В документах по VM/370 это описано явно.) В современных системах предпочитают двухэтапную трансляцию. В x86 это EPT, которая действует на адреса от гостя отдельно от хозяйского процесса. В ARM, RISC-V напрямую два этапа трансляции через разные каталоги, но пространство то же, что у хозяйского процесса. Чтобы не дёргаться с shadow paging, лучше сразу, чтобы процессор знал про виртуализацию. А тогда ничего не мешает сделать вообще поддержку процессором понимания разделения между хозяйским и гостевым уровнем.
А вот shadow paging сильно начинает бить по производительности, если не поддержана паравиртуализацией.
MVT как гостевая работала, по ощущениям, так же быстро, как и на реальной машине
Потери там таки должны быть именно на формировании теневых страниц по каждому чиху.
Вот SVS виртуализировать я не пробовал.
Она к ней уже должна быть готова.
А вот shadow paging сильно начинает бить по производительности, если не поддержана паравиртуализацией.
Ну, с этим-то я и не спорю. Но всё равно приятней иметь возможность для виртуализации, пускай медленной, чем вообще её не иметь.
Потери там таки должны быть именно на формировании теневых страниц по каждому чиху.
Ну, сама MVT вместе с её приложениями оказывалась, конечно, в виртуальной памяти, но один раз создал страницу -- и всё, больше ничего делать не надо, если физической памяти хватает, чтобы не страдать страничным обменом, а её хватало (на машине было 3 Мбайта ОП, что для СВМ + MVT выше крыши, если не гонять слишком уж прожорливые в плане памяти задачи, а их у нас не было).
Она к ней уже должна быть готова.
Подозреваю, зависит от конкретной версии что СВМ, что ОС ЕС... Во всяком случае, для ЕС-1035 поддержка СВМ, в теории, была, хоть и очень ограниченная, однако та версия СВМ, которой я располагал, её использовать не могла -- вероятно, под эту СВМ нужна была другая версия микропрограмм самого проца. Поэтому и работала СВМ без какой-либо поддержки виртуализации. (Вот на ЕС-1130 уже использовала поддержку со стороны проца.) Так что, полагаю, для ОС тоже нужно было соответствие версий, чтоб использовать их "сотрудничество".
Но вообще, запуском MVT я чисто баловался, никакой нужды не было: просто шёл процесс перехода с ЕС-1035 на ЕС-1130, и я поочерёдно извращался на обоих машинах, когда они бывали свободны. В конечном итоге, работало всё на ЕС-1130, но не в MVT или SVS, а в БОС под СВМ: понятно, что это эффективней для СВМ, но менее эффективно, чем "обычная" ОС на реальном железе. Просто обычную ОС ЕС к тому времени благополучно "пролюбили": диск похерился, а работоспособных копий не оказалось -- квалифицированные операторы к тому времени уже разбежались, дисциплина копирования и т.п. упала, я тоже уже с год работал в другом месте, но вызвали спасать, и единственным вариантом оказалось сгенерить СВМ, так как она у меня была на личных лентах, которые сохранились -- в отличие от тех, которые оставались на ВЦ и благополучно были утеряны/испорчены.
Вот SVS виртуализировать я не пробовал.
Она к ней уже должна быть готова.
Работал в SVS под VM на ЕС1036... не рекомендую.
На поздней Системе 370 появился механизм двойного адресного пространства (впоследствии расширен до множества адресных пространств), что резко упрощает и ускоряет реализацию программ-серверов, обслуживающих программы-клиенты. Без этого механизма вызов подпрограммы в сервере надо производить через ядро ОС, с ним -- можно вызывать прямо, при этом привилегии у клиента и сервера разные, но всё контролируется и защищено
О, вот это интересно. В "Principles of operation" куча технических подробностей, но как начнёшь читать про все эти ASTEIN, так шарики за ролики заезжают и сложно понять, кому и как это вообще было нужно. Явно же не для простой виртуализации.
Это хорошая тема для отдельной статьи. Или уже есть где-то популярное описание, как это строилось и работало?
Есть мой перевод последней редакции "Принципов работы Системы 370". Ну а сделано это для серверов приложений -- и получило дальнейшее углубление и развитие в ESA/370, ESA/390 и z/Architecture.
Есть мой перевод последней редакции "Принципов работы Системы 370".
Спасибо. Ну мне перевод с английского не требуется, а вот то, что это чистый справочник, и не даёт типовых или рекомендованных примеров такого применения - даёт, что это существенно не то.
(Хотя вот открыл и увидел ваши примечания на некоторых страницах... это может быть существенно.)
Ну а сделано это для серверов приложений -- и получило дальнейшее углубление и развитие в ESA/370, ESA/390 и z/Architecture.
Спасибо. Не то чтобы стало понятнее, но подтверждение подскажет, куда смотреть дальше...
Ну, я лично с этими механизмами не сталкивался: на тех советских машинах, с которыми имел дело, их попросту не было, а с IBMовской техникой работать не довелось. Но, кстати говоря, этот механизм, похоже, позволяет реализовать в т.ч. микроядерную ОС, как это изначально предполагалось (а не как преподносится сейчас -- в, например, QNX), без сколько-нибудь существенной потери производительности. А вообще, гляньте, например, в сторону https://en.m.wikipedia.org/wiki/CICS -- оно как раз использует множественные адресные пространства (дальнейшее развитие двойного адресного пространства).
P.S. Кстати говоря, именно из-за отсутствия личного опыта я и не планирую пытаться писать отдельную статью по этому поводу: одно дело теоретически понять, как можно использовать такую специфическую архитектурную фишку, и другое -- видеть и использовать её на практике.
Уродливость системы команд -- понятие, которое зависит от вкуса, привычек, опыта работы с ними. Если сравнивать, к примеру, с MIPS или ARM (ранними), так ЕС вполне достойно смотрится.
Только зачем нужны красивые системы команд, когда на ассемблере не пишут практически ничего? Даже операционные системы. Уже при написании IBM MVS широко использовался язык PL/S, а это середина 1970-х.
От красоты или уродства системы команд, как минимум, зависят сложность её декодирования (IA-32 -- кошмар, Система 360 -- прекрасно, ARM -- где-то посредине) и сложность создания эффективного кодогенератора для компиляторов.
Одни из самых сложных процедур в оптимизирующем кодогенераторе -- это поиск в программе паттернов, которые бы отображались напрямую на комбинации команд и режимов адресации в прикладном режиме. И я не сказал бы, что красивая система команд однозначно упрощает этот процесс. Приведу пример из PDP-11.
Имеется автодекрементная адресация, которая по архитектуре применима ко многим командам. Однако, чтобы задействовать этот режим адресации для генерации команд помимо MOV, требуется научить кодогенератор отыскивать очень специфичные (и редко встречающиеся) комбинации в исходном коде. Теперь, гипотетически, создадим другую, не такую красивую систему команд, в которой автодекрементую адресацию оставим только как особый случай команды MOV. Кодогенерация при этом, очевидно, упрощается: нет лишних комбинаций команд -- не нужно выявлять для них паттерны -- нет лишних проблем.
(Нетрудно заметить, что выше я просто-напросто пересказал кусок из идеологии RISC. Ну да, набор команд у них не назовешь однозначно красивым.)
Ну, что эффективная, но сложная система команд однозначно затрудняет создание хорошего кодогенератора -- это, конечно, так. Но, как по мне, это не повод делать неэффективную систему команд -- а любые классические RISCи именно такими и являются. Недаром постепенно они сами от своих идей и отошли. Скажем, у современных ARMов единственное, что от идеологии RISC осталось, -- это отсутствие команд, прямо обрабатывающих данные в памяти, все остальные атрибуты они утратили: есть сложные команды, выполняемые несколько тактов, команды имеют разную длину (система команд Thumb), декодирование стало весьма нетривиальным...
Ну и про ручное программирование всё ж не стоит забывать. Да, на ассемблере пишут редко, но иногда такая нужда бывает. Кроме того, помня, что 90% времени расходует 10% кода, в некоторых задачах вполне оправданной может быть ручная ассемблерная оптимизация. Естественно, подходить надо без фанатизма, но и без пофигизма (зачем оптимизировать? поставим более мощный проц! а что мобила из-за этого работает от батареи 2 часа, а не 20 -- пофиг, у конкурентов то же самое).
Скажем, у современных ARMов единственное, что от идеологии RISC осталось, -- это отсутствие команд, прямо обрабатывающих данные в памяти, все остальные атрибуты они утратили: есть сложные команды, выполняемые несколько тактов, команды имеют разную длину (система команд Thumb), декодирование стало весьма нетривиальным...
AArch64 вернулся к фиксированной длине команд, Thumb остался в 32 битах. (В среднем код толще аналогичного для x86 на 1-2%.)
Большинство команд стараются оставить в пределах одного такта, при этом вводя много хитрых приёмов (например, см. CSEL семейство - трюк практически гениальный, или как BFM семейство забрало на себя все сдвиги на константную ширину).
Прямая обработка в памяти существует для атомарных операций. В 8.0 архитектуре их не было, было LR/SC (LDXR, STXR), но обнаружили, что у них этот метод отвратительно масштабируется на много процессоров, с 8.1 ввели compare-and-set и аналогичные для операций AND/OR/ADD/etc.
Флаги NZVC есть, но у большинства команд есть варианты, которые не ставят эти флаги, если не нужно. У многих вообще варианта нет поставить флаги (местами, я думал, перестарались - как для SDIV, где детект ситуаций типа MIN/-1 средствами процессора был бы очень полезен).
В целом я бы сказал, что ARM тут очень хорошо держат баланс, отходя от чистой RISC идеологии только там, где без этого будет существенная потеря в чём-то.
Мне тогда казалось что СМ PDP красива, особенно система команд, а ЕС IBM урод и там много костылей.
Мне в детстве тоже казалось, что у PDP-11 идеальная система команд ("в детстве" это не полемическая форма, я с ними столкнулся в ~14 лет). Впоследствии с опытом пришло видение, сколько там было явно сомнительных решений, например:
Отсутствие идеи про расширение команд на второе слово, если нужно (на поздних этапах там возникла давка в кодах вокруг FPP и тому подобного).
Вынос некоторого ограниченного количества операций в наиболее "широкий" по свойствам набор (ccssdd₈), забив пространство кодов - даже на XOR не осталось, она уже попала в урезанный набор.
Тупейшая реализация ADC и SBC: без громоздких костылей работать более чем с 2-словными числами невозможно, получается, как будто их вообще нет. Последующие версии (как ADC/SBB в x86, ALC/SLC в S/390) в этом смысле умнее, и, главное - очевидно сделаны прямо и без извращений. Совершенно непонятно, зачем в PDP-11 было такое.
MOV которое ставит флаги согласно значению. Во всех последующих уровнях хотя бы "мини" не повторялось. (Даже 6502 их меняет на LDA, но не на STA.)
Минимально используемый (я видел только в шутках) 5-й тип адресации,
@-(Rn). В VAX его поэтому убили. Можно было зарезервировать под расширения.8KB страницы для DAT - неэффективно. Даже возможность размещать их не на естественных границах не очень помогает. Странно, почему не сделали их 4KB или 2KB. Похоже, решили "меньше 8 нельзя, но сэкономим".
Разумеется, всё это "послезнание" - я не представляю себе обстановку конца 60-х, о чём тогда и как думали. Вероятно, просто не было толком опыта, чем эти решения плохи.
Из гениальных решений в ней это однозначно схема флагов NZVC. Её автору надо поставить памятник.
Думаю, основная "человеческая" критика S/360 видя PDP-11 это проблема костылей на некоторых наиболее неприятных операциях типа загрузки полных констант и дальней адресации. Если бы, например, в S/360 сразу сделали команду типа IILF от z/Arch (6-байтная, 32-битная константа целиком в регистр) и/или адресацию от PC (например, сделав правило "регистр 8 как база заменяется на адрес текущей команды") - уже половина плачей ушла бы. Сюда же, вероятно, сделать знаковыми непосредственные смещения в RX и RS командах (IBM это сделала позже в Y-подтипе команд, там 20 бит со знаком), опять же, в других ISA везде со знаком.
Насчёт костылей System/360 согласен, но там причина понятна сразу: они были первыми. Невозможно попасть в десятку сразу по всем архитектурным вопросам, не накопив опыта. К тому же, со временем приоритеты смещаются, к примеру (правда не про процессор), устройства прямого доступа по схеме "счёт-ключ-данные" некоторые время считались весьма перспективными.
И, кроме того, подобные диски позволяли легко использовать изначально ленточные наборы данных: на ленте блоки имеют переменную длину, и здесь получили то же самое. Подозреваю, что на это тоже смотрели в своё время, ведь, пожалуй, как раз до Системы 360 основным носителем данных была магнитная лента.
Так до появления НЖМД с сервоповерхностью (100/200 Мб) дорожка диска по сути представляла собой кусок магнитной ленты с одной выделенной начальной точкой - индексным отверстием.
Угу. Просто можно было бы всегда форматировать её блоками фиксированного размера подобно более поздним дискам -- но сделали CKD. Вот я и предполагаю, что это, в том числе, из-за лёгкости миграции с магнитных лент (можно оперировать блоками переменного размера; метки томов и наборов данных МЛ на дисках тоже могут размещаться -- соответственно, для прикладного ПО, в первом приближении, вообще ничего не меняется при переходе от ленты к диску).
Всё так, но не до конца. CKD позволяла сделать ещё две "убойные фишки", на то время.
Во-первых, CKD позволяет System/360 единообразно работать с достаточно различающимся устройствами: магнитными барабанами, магнитными картами и магнитными дисками. Кто тогда мог знать, что выживут только диски?
Во-вторых, CKD позволяет выполнять поиск данных по ключу средствами подканала, устройства управления и самой дисковой стойки, т.е. не задействуя центральный процессор. Поначалу, казались, что это супер круто, недостатки выплыли потом, когда запилили ISAM.
Ну, про это я просто не стал упоминать. Поиск файла в каталоге (набора данных на томе) средствами чисто контроллера диска, без участия проца -- это действительно весьма круто, особенно учитывая хилость тогдашних процов с современной точки зрения. Жалко ж тратить приличное процессорное время на тупое сравнение байтиков :)
Ну а ISAM... Конечно, железный поиск по индексу -- это хорошо, но, по моему опыту, был реально оправдан только для справочников, которые почти никогда не менялись. Если же набор данных постоянно меняется, то сплошной гемор с областями переполнения и прочим (а заодно и производительность теряется).
Процессор ЭВМ ЕС-1020. Блок регистров