Обратиться на микроконтроллере к любым ячейкам памяти можно, но, скажем, сделать переключалку потоков без ассемблера уже не получится: для этого нужно манипулировать указателями стеков (их может быть несколько), различными управляющими регистрами процессора и т.д. -- в общем, сущностями, о которых язык высокого уровня понятия не имеет (и не должен иметь). Так что абсолютный контроль без ассемблера оказывается невозможен.
Да, это можно сделать средствами встроенного ассемблера -- но, во-первых, это будет таки ассемблер, а не С/С++, а во-вторых, встроенного ассемблера может и не быть (это в GCC или CLANG он есть, а мало ли что экзотическое может потребоваться использовать).
Ну так это уже гигантская компания, получается, пускай и состоящая из очень большого количества мелких подразделений, выполняющих одни и те же функции.
Не убить. Плат там много, остальные продолжать работать. Ну а программы, которые выполнялись на убитой плате, будут, скорей всего, перезапущены автоматом с контрольной точки.
Группы поколений данных? Да, но, как по мне, оно не шибко удобно, хотя вполне себе работает. Но учитывая, что OS/360, похоже, была вообще первой "настоящей большой ОС" в истории (а современная MVS тянет совместимость с ней), трудно было всё сделать и правильно, и удобно :)
Насчёт коробок согласен. Для условной кафешки нужно готовое решение, но она ничем, с точки зрения учёта, закупок и т.д. и т.п., не отличается от 100500 других кафешек. Ну а любая очень крупная контора имеет свои специфические фишки, которые в коробки просто не заложишь -- а значит, хошь-не хошь, а придётся что-то дописывать, переделывать и т.д. и т.п. Ну а поскольку SAP ориентирован, как понимаю, исключительно на крупный бизнес, то там коробка попросту не нужна: у них не бывает клиентов, где можно просто "скопировать программу с дискеты" и всё будет работать.
Лично у меня из прочтения той статьи сложилось впечатление, что автор не SAP как таковой ругает, а говорит о том, что его выбирать приходилось не из-за отсутствия достойных альтернатив, а из-за того, что он де-факто навязывается западными регуляторами.
У него сдвоенное обозначение, но почему, лично я не в курсе. Но вообще, такое бывало достаточно часто, но обычно с забугорными машинами (скажем, ЕС-1040 и ЕС-1055 имели у Роботрона свои собственные обозначения).
Во-первых, это, скорей, не суперкомпьютеры, а кластеры обычных компьютеров: физически там множество компьютеров, каждый под управлением своей собственной ОС и т.д. и т.п.
А во-вторых, на железе от Интел их не строят никогда -- их строят на железе и Невидии, и именно её ГПУ выполняют всю "суперкомпьютерную" обработку, а кто скармливает им работу, абсолютно неважно.
Но таки да, на мэйнфреймах суперкомпьютеры-числодробилки не строят -- они под другие задачи заточены.
Прикладные программы переписывать не требуется, там, насколько мне известно, 100% переносимость (и какой-нибудь прикладной код из 1965-го будет без изменений работать и сейчас), а вот ядро системы (супервизор, грубо говоря) -- необходимо, ведь именно оно обеспечивает возможность работы на 64 битах, оно должно поддерживать новые возможности управления адресными пространствами и т.д. и т.п.
И производительность, и прямизна архитектуры в целом и архитектуры ввода-вывода в частности -- именно благодаря этому мэйнфреймы прекрасно виртуализируются, ну а по-настоящему качественных виртуализаций ПК не существует и вряд ли будет существовать (имеющиеся гипервизоры виртуализируют некоторое подмножество, достаточное для исполнения Винды/Линуха, но далеко не всегда способные работать с чем-то нестандартным; мэйнфреймы изначально виртуализировались абсолютно полностью, поэтому на виртуальной машине можно было творить ту же дичь с вводом-выводом, что и на реальном железе -- и всё работало).
Не уверен, но мне кажется, вы путаете разные технологии восстановления при сбоях и отказах железа - ECC для памяти и шин процессора и т.п. и в x86 уже работают достаточно давно
Нет, речь именно о возможности восстановления работы после сбоя/отказа, а не чисто схемы коррекции ошибок -- таковые в мэйнфреймах были очень давно, но они -- лишь техническая база, так сказать. Скажем, наша ЕС-1035 микроархитектурно содрана с IBM 370/145 (если правильно помню; кстати, это единственный известный мне случай, когда наша машина микроархитектурно повторяет IBMовскую -- остальные, с которыми разбирался, хотя и имеют большее или меньшее сходство, но имеют и серьёзные микроархитектурные отличия) на уровне железа поддерживала контроль и коррекцию управляющей (микропрограммной) и основной (оперативной) памяти по коду Хэмминга, а также умела выполнять сбойнувшие микрокоманды повторно -- отказ фиксировался, если 8 повторений оказывались безуспешными. Но всё это, как понимаете, -- чисто железные (или микропрограммные, что для программы безразлично) вещи, и никакой специальной поддержки со стороны ОС им не нужно: они работают сами по себе.
Вы уверены, что мэйнфрейм 1974 года обеспечивал такой функционал?
Если мэйнфрейм двухпроцессорный (что для 1974 года было редкостью, но таки было -- первые ещё в 1960-х появились), то да, такая возможность была. Ну а будет ли рестарт с текущего состояния или с контрольной точки, зависит от того, удалось ли сохранить текущее состояние в корректном виде, а это уже зависит от вида отказа -- но это и сейчас так.
Скажем, в ЕС-1033 (архитектурно это ещё Система 360 -- без MMU, а соответственно, без виртуальной памяти) блок диагностики работал абсолютно независимо от самого процессора, имел собственное микропрограммное управление и т.д. и т.п. Поэтому при отказе процессора он мог сам сохранить содержимое всех регистров в память -- естественно, при условии, что их содержимое не пострадало (контроль по нечётности), интерфейс с памятью работает и т.д.; другой процессор двухпроцессорного комплекса уведомлялся об отказе посредством прерывания, и ОС могла, проанализировав сохранённые данные, принять решение о дальнейших действиях.
Но вообще, даже на однопроцессорных машинах определённые средства и возможности были. В частности, полноценный обработчик машинных ошибок (MCH, machine check handler), который был предусмотрен для любой машины Системы 370 и для некоторых старших моделей Системы 360, старался сохранить работоспособность того, что можно. Например, если неустранимый сбой возник при выполнении прикладной программы, её дальнейшее выполнение оказывалось невозможным, но работоспособность системы и других программ сохранялась. Кроме того, если для сбойнувшей программы был предусмотрен перезапуск, он мог производиться автоматически (либо с её начала, либо с последней контрольной точки). Если система была с виртуальной памятью (это уже не классическая MFT/MVT, а SVS или MVS -- но тоже первая половина 1970-х) и вышел из строя блок памяти, но его содержимое не менялось с момента последней загрузки, производилась загрузка нужной страницы в другой блок памяти, после чего работа возобновлялась -- ну и т.д. и т.п. Понятно, что всё это в дальнейшем совершенствовалось, и поздняя MVS ушла далеко вперёд от MFT, но, тем не менее, всё это начиналось с самого начала, а не сильно позже, и достаточно успешно работало уже в MFT/MVT, где железо позволяло.
мой тезис в том, что сейчас в мире x86 и существующая технология полной защиты от аппаратных сбоев достаточно мало востребована - эти проблемы решаются на уровне архитектуры прикладного ПО, кластеризации, контейнеризации и т.п.
Мне кажется, что все эти решения не обеспечивают полной защиты от проблем с железом. Как, например, восстановить работоспособность программы, если сдох процессор и содержимого регистров на момент отказа нет (они где-то в процессоре остались)? Никак тут не восстановишь с момента сбоя -- только с последней контрольной точки, если таковая имеется, ну или вообще только запуском с самого начала. Ну а на мэйнфреймах в тех случаях, когда это технически возможно (содержимое памяти корректно и были успешно сохранены регистры процессора), работа пострадавшей программы продолжается именно с точки сбоя, буквально с команды, при выполнении которой сдох процессор.
Кроме того, защищаться путём соответствующей архитектуры прикладного ПО, естественно, можно -- но это резко усложняет это самое ПО и заставляет создавать необходимый функционал в каждой прикладной программе. В этом плане возможность разруливать ситуацию и обеспечивать восстановление на уровне аппаратуры и ОС для любого прикладного кода весьма ценна -- хотя, естественно, лучшие результаты достигаются в случае, когда и прикладное ПО спроектировано так, чтоб облегчать восстановление.
Для виртуальных машин. А что с самим гипервизором? Или с приложениями, работающими под управлением ОС на реальной, а не виртуальной машине?
Способность восстановления после сбоев или отказов аппаратуры IBM развивала, начиная ещё с Системы 360, т.е. со второй половины 1960-х годов. Это довольно неплохо работало уже в поздних версиях классической OS/360 (а её развитие прекратилось на версии 21.8 году эдак в 1972-74; дальше шли уже системы с виртуальной памятью, быстро превратившиеся в MVS, из которой выросла нынешняя z/OS). Т.е. то, что на "обычных компах" появилось 15 лет назад, IBM имеет уже с полвека.
Как правильно отметили, вопрос именно в сохранении работоспособности программы, которая пострадала при отказе техники. Мэйнфрейм (аппаратура + программная поддержка в ОС) очень часто способен продолжить её выполнение -- когда прямо с точки сбоя, когда с некоторой контрольной точки, которая была чуть раньше.
И куда больше времени тратится на согласование работы, выполняемой на физически разных машинах. Где-то это может быть несущественно, где-то -- очень важно.
Ну так и мэйнфреймы давным-давно уже микропроцессорные. Да и не сказать, что доступные микропроцессоры произвели какую-то революцию. Ну, вышел 8080 (первый более-менее полноценный микропроцессор), и что? Он лишь слегка подвинул мини-ЭВМ из их ниши, поскольку тягаться даже с самыми слабыми из них ему было, скажем так, проблематично. А к тому времени, как производительность микропроцессоров в достаточной степени увеличилась, мини-ЭВМ тоже превратились в микропроцессорные машины, а несколько позже то же самое сделали и мэйнфреймы.
Обратиться на микроконтроллере к любым ячейкам памяти можно, но, скажем, сделать переключалку потоков без ассемблера уже не получится: для этого нужно манипулировать указателями стеков (их может быть несколько), различными управляющими регистрами процессора и т.д. -- в общем, сущностями, о которых язык высокого уровня понятия не имеет (и не должен иметь). Так что абсолютный контроль без ассемблера оказывается невозможен.
Да, это можно сделать средствами встроенного ассемблера -- но, во-первых, это будет таки ассемблер, а не С/С++, а во-вторых, встроенного ассемблера может и не быть (это в GCC или CLANG он есть, а мало ли что экзотическое может потребоваться использовать).
Ну так это уже гигантская компания, получается, пускай и состоящая из очень большого количества мелких подразделений, выполняющих одни и те же функции.
Не убить. Плат там много, остальные продолжать работать. Ну а программы, которые выполнялись на убитой плате, будут, скорей всего, перезапущены автоматом с контрольной точки.
Группы поколений данных? Да, но, как по мне, оно не шибко удобно, хотя вполне себе работает. Но учитывая, что OS/360, похоже, была вообще первой "настоящей большой ОС" в истории (а современная MVS тянет совместимость с ней), трудно было всё сделать и правильно, и удобно :)
Насчёт коробок согласен. Для условной кафешки нужно готовое решение, но она ничем, с точки зрения учёта, закупок и т.д. и т.п., не отличается от 100500 других кафешек. Ну а любая очень крупная контора имеет свои специфические фишки, которые в коробки просто не заложишь -- а значит, хошь-не хошь, а придётся что-то дописывать, переделывать и т.д. и т.п. Ну а поскольку SAP ориентирован, как понимаю, исключительно на крупный бизнес, то там коробка попросту не нужна: у них не бывает клиентов, где можно просто "скопировать программу с дискеты" и всё будет работать.
Лично у меня из прочтения той статьи сложилось впечатление, что автор не SAP как таковой ругает, а говорит о том, что его выбирать приходилось не из-за отсутствия достойных альтернатив, а из-за того, что он де-факто навязывается западными регуляторами.
У него сдвоенное обозначение, но почему, лично я не в курсе. Но вообще, такое бывало достаточно часто, но обычно с забугорными машинами (скажем, ЕС-1040 и ЕС-1055 имели у Роботрона свои собственные обозначения).
Во-первых, это, скорей, не суперкомпьютеры, а кластеры обычных компьютеров: физически там множество компьютеров, каждый под управлением своей собственной ОС и т.д. и т.п.
А во-вторых, на железе от Интел их не строят никогда -- их строят на железе и Невидии, и именно её ГПУ выполняют всю "суперкомпьютерную" обработку, а кто скармливает им работу, абсолютно неважно.
Но таки да, на мэйнфреймах суперкомпьютеры-числодробилки не строят -- они под другие задачи заточены.
На ЕС не встречал (хотя вполне могло быть), а вот на СМках это было обычное дело. IНЖАЛИД ДЕЖИЦЕ оттуда ж пошло :)
Прикладные программы переписывать не требуется, там, насколько мне известно, 100% переносимость (и какой-нибудь прикладной код из 1965-го будет без изменений работать и сейчас), а вот ядро системы (супервизор, грубо говоря) -- необходимо, ведь именно оно обеспечивает возможность работы на 64 битах, оно должно поддерживать новые возможности управления адресными пространствами и т.д. и т.п.
И, кстати, AMODE -- не 16, а 24, описка-с :)
Возможно, из-за того, что клавиатура ЕС-7927 рассчитана на ДКОИ, но собственно терминал внутри использует ASCII (точней, КОИ-что-то-там).
Возможно, это зависит от конкретной модели мэйнфрейма -- в последние могли и внедрить некую защиту от нелицензионного использования.
И производительность, и прямизна архитектуры в целом и архитектуры ввода-вывода в частности -- именно благодаря этому мэйнфреймы прекрасно виртуализируются, ну а по-настоящему качественных виртуализаций ПК не существует и вряд ли будет существовать (имеющиеся гипервизоры виртуализируют некоторое подмножество, достаточное для исполнения Винды/Линуха, но далеко не всегда способные работать с чем-то нестандартным; мэйнфреймы изначально виртуализировались абсолютно полностью, поэтому на виртуальной машине можно было творить ту же дичь с вводом-выводом, что и на реальном железе -- и всё работало).
Если аж 1990-й, то это ещё не z/OS -- до неё ещё 10 лет. Получается, уже на машинах ESA/390 сделали (а может, и на поздних ESA/370).
Про подобную реализацию не знал. Век живи -- век учись (и дураком помрёшь :) ).
Нет, речь именно о возможности восстановления работы после сбоя/отказа, а не чисто схемы коррекции ошибок -- таковые в мэйнфреймах были очень давно, но они -- лишь техническая база, так сказать. Скажем, наша ЕС-1035 микроархитектурно содрана с IBM 370/145 (если правильно помню; кстати, это единственный известный мне случай, когда наша машина микроархитектурно повторяет IBMовскую -- остальные, с которыми разбирался, хотя и имеют большее или меньшее сходство, но имеют и серьёзные микроархитектурные отличия) на уровне железа поддерживала контроль и коррекцию управляющей (микропрограммной) и основной (оперативной) памяти по коду Хэмминга, а также умела выполнять сбойнувшие микрокоманды повторно -- отказ фиксировался, если 8 повторений оказывались безуспешными. Но всё это, как понимаете, -- чисто железные (или микропрограммные, что для программы безразлично) вещи, и никакой специальной поддержки со стороны ОС им не нужно: они работают сами по себе.
Если мэйнфрейм двухпроцессорный (что для 1974 года было редкостью, но таки было -- первые ещё в 1960-х появились), то да, такая возможность была. Ну а будет ли рестарт с текущего состояния или с контрольной точки, зависит от того, удалось ли сохранить текущее состояние в корректном виде, а это уже зависит от вида отказа -- но это и сейчас так.
Скажем, в ЕС-1033 (архитектурно это ещё Система 360 -- без MMU, а соответственно, без виртуальной памяти) блок диагностики работал абсолютно независимо от самого процессора, имел собственное микропрограммное управление и т.д. и т.п. Поэтому при отказе процессора он мог сам сохранить содержимое всех регистров в память -- естественно, при условии, что их содержимое не пострадало (контроль по нечётности), интерфейс с памятью работает и т.д.; другой процессор двухпроцессорного комплекса уведомлялся об отказе посредством прерывания, и ОС могла, проанализировав сохранённые данные, принять решение о дальнейших действиях.
Но вообще, даже на однопроцессорных машинах определённые средства и возможности были. В частности, полноценный обработчик машинных ошибок (MCH, machine check handler), который был предусмотрен для любой машины Системы 370 и для некоторых старших моделей Системы 360, старался сохранить работоспособность того, что можно. Например, если неустранимый сбой возник при выполнении прикладной программы, её дальнейшее выполнение оказывалось невозможным, но работоспособность системы и других программ сохранялась. Кроме того, если для сбойнувшей программы был предусмотрен перезапуск, он мог производиться автоматически (либо с её начала, либо с последней контрольной точки). Если система была с виртуальной памятью (это уже не классическая MFT/MVT, а SVS или MVS -- но тоже первая половина 1970-х) и вышел из строя блок памяти, но его содержимое не менялось с момента последней загрузки, производилась загрузка нужной страницы в другой блок памяти, после чего работа возобновлялась -- ну и т.д. и т.п. Понятно, что всё это в дальнейшем совершенствовалось, и поздняя MVS ушла далеко вперёд от MFT, но, тем не менее, всё это начиналось с самого начала, а не сильно позже, и достаточно успешно работало уже в MFT/MVT, где железо позволяло.
Мне кажется, что все эти решения не обеспечивают полной защиты от проблем с железом. Как, например, восстановить работоспособность программы, если сдох процессор и содержимого регистров на момент отказа нет (они где-то в процессоре остались)? Никак тут не восстановишь с момента сбоя -- только с последней контрольной точки, если таковая имеется, ну или вообще только запуском с самого начала. Ну а на мэйнфреймах в тех случаях, когда это технически возможно (содержимое памяти корректно и были успешно сохранены регистры процессора), работа пострадавшей программы продолжается именно с точки сбоя, буквально с команды, при выполнении которой сдох процессор.
Кроме того, защищаться путём соответствующей архитектуры прикладного ПО, естественно, можно -- но это резко усложняет это самое ПО и заставляет создавать необходимый функционал в каждой прикладной программе. В этом плане возможность разруливать ситуацию и обеспечивать восстановление на уровне аппаратуры и ОС для любого прикладного кода весьма ценна -- хотя, естественно, лучшие результаты достигаются в случае, когда и прикладное ПО спроектировано так, чтоб облегчать восстановление.
Для виртуальных машин. А что с самим гипервизором? Или с приложениями, работающими под управлением ОС на реальной, а не виртуальной машине?
Способность восстановления после сбоев или отказов аппаратуры IBM развивала, начиная ещё с Системы 360, т.е. со второй половины 1960-х годов. Это довольно неплохо работало уже в поздних версиях классической OS/360 (а её развитие прекратилось на версии 21.8 году эдак в 1972-74; дальше шли уже системы с виртуальной памятью, быстро превратившиеся в MVS, из которой выросла нынешняя z/OS). Т.е. то, что на "обычных компах" появилось 15 лет назад, IBM имеет уже с полвека.
Как правильно отметили, вопрос именно в сохранении работоспособности программы, которая пострадала при отказе техники. Мэйнфрейм (аппаратура + программная поддержка в ОС) очень часто способен продолжить её выполнение -- когда прямо с точки сбоя, когда с некоторой контрольной точки, которая была чуть раньше.
И куда больше времени тратится на согласование работы, выполняемой на физически разных машинах. Где-то это может быть несущественно, где-то -- очень важно.
Ну так и мэйнфреймы давным-давно уже микропроцессорные. Да и не сказать, что доступные микропроцессоры произвели какую-то революцию. Ну, вышел 8080 (первый более-менее полноценный микропроцессор), и что? Он лишь слегка подвинул мини-ЭВМ из их ниши, поскольку тягаться даже с самыми слабыми из них ему было, скажем так, проблематично. А к тому времени, как производительность микропроцессоров в достаточной степени увеличилась, мини-ЭВМ тоже превратились в микропроцессорные машины, а несколько позже то же самое сделали и мэйнфреймы.