Вы перепутали статью на 39 страниц и тезисы на 249 с похожим названием. Это оттуда
На мой взгляд наоборот: на математике вся компьютерная наука держится. Например, теория типов. Она применяется, как для определения свойств безопасности языков, например тех же инструкций x86 или другого набора. Так и для упрощения отладки и много чего еще. Без строгих математических оснований ничего бы столь сложного, как машины и операционные системы, не существовало бы.
В Википедии ссылаются на тезисы Гольдберга 1973 года "Architectural Principles for Virtual Computer Systems", где он впервые ввел эту типизацию.
Собственно, Таненбаум тоже ссылается на Гольдберга 1974 года, когда пишет про чувствительные инструкции. А архитектура x86 появилась в 1978 году только.
Для любого обычного компьютера может быть создан монитор виртуальной машины, если набор чувствительных инструкций для этого компьютера является подмножеством набора привилегированных инструкций...
Чувствительная к управлению инструкция (control sensitive instruction) – это инструкция, которая может повлиять на конфигурацию машины... Инструкция, чувствительная к поведению (behavior sensitive instruction) – это команда, действие которой частично определяется контекстом, в котором она выполняется...
...не все наборы инструкций имеют конфиденциальные (т.е. чувствительные?) инструкции только для привилегированных пользователей, в том числе, пожалуй, самый популярный – набор инструкций Intel x86. Как оказалось, в этом наборе 17 конфиденциальных инструкций, которые не являются привилегированными.
...пока конфиденциальные инструкции перехватываются при выполнении в пользовательском режиме, мы можем безопасно выполнять все нечувствительные инструкции непосредственно на базовом оборудовании.
Могу предположить, что чудесные свойства архитектуры, описываемой в статье, следуют из того, что набор чувствительных инструкций является подмножеством привилегированных. А для x86 приходится либо использовать эмуляцию, либо паравиртуализацию, либо еще что-то.
В случае нашего HPC вообще просто: гостевому Линуксу одному отдаются все доступные ресурсы. Т.е. аппаратные средства (или по-другому Power PHYP native bare-metal hypervisor in firmware) запускают одну ОС в одной партиции и больше ничего особенного не делают. Все дублирующие элементы машины с несколькими процессорами https://shorturl.at/3OfVx используются только для эффективности вычислений.
Могу предположить, что в случае z/VM одного функционала bare-metal hypervisor недостаточно, и требуется поддержка на уровне самой специализированной ОС z/VM (программного гипервизора в вашей терминологии), чтобы запускать тысячи гостевых машин на каком-то меньшем числе партиций LPAR мейнфрейма.
С моей точки зрения, оба они программные гипервизоры, просто один из них находится в firmware, а другой - в ОС z/VM. И этому гипервизору в ОС z/VM требуется поддержка микропрограмм процессоров, упомянутая в статье, чтобы эффективнее осуществлять свою виртуализирующую деятельность.
Освежил свои представления и оказалось, что в PowerPC Linux используется POWER Hypervisor, аналогичный мейнфреймовским. Приведу здесь немного информации об архитектуре из https://en.wikipedia.org/wiki/Hypervisor для удобства:
IBM provides virtualization partition technology known as logical partitioning (LPAR) on System/390, zSeries, pSeries and IBM AS/400 systems. For IBM's Power Systems, the POWER Hypervisor (PHYP) is a native (bare-metal) hypervisor in firmware and provides isolation between LPARs...For real-mode addressing by operating systems (AIX, Linux, IBM i), the Power processors (POWER4 onwards) have designed virtualization capabilities where a hardware address-offset is evaluated with the OS address-offset to arrive at the physical memory address.
Похоже, что для LPAR технологии не обязательны мейнфреймовские процессоры, она в таком же виде существует и для RISC POWER процессоров. Linux после petitboot просто грузится как гостевая ОС. А гипервизор реализован на уровне firmware, не требуя особой поддержки от микропрограмм процессоров .
Я имел дело с серверами IBM на архитектуре Power и под ОС Linux, но не с мейнфреймами. И на HPC кластере, без виртуализации. Больше всего запомнилось отличие petitboot загрузчика (PowerPC на Linux) от загрузчика x86. https://sthbrx.github.io/blog/2016/05/13/tell-me-about-petitboot/
Если я правильно понимаю, разработчик мейнфрейма IBM (я не имею ввиду прикладного разработчика под ОС z/VM) может заниматься как разработкой прошивки процессора (firmware), так и разработкой самой ОС z/VM. В силу того, что компания занимается и железом и софтом. Не знаю, как у процессоров мейнфрейма, но для разных устройств прошивка (например, firmware for IBM Power System) - это обычное ПО, которое также разрабатывается, легко меняется и обновляется.
Мне представляется, что аналогично тому, как в firmware маршрутизатора можно реализовать функционал, например, брандмауэра, так и в firmware мейнфрейма (в т.ч. его процессоров) можно реализовать функционал гипервизора. И он будет 1-го типа, поскольку близок к железу и узкоспециализированный.
Это не zVM, это реальная машина МФ с партициями реализованными PR/SM (Processor Resource/Systems Manager), ошибочно считающимся Type-1 Hypervisor. Почему ошибочно? Потому что каждая партиция это реальный МФ. PR/SM это микропроцессор МФ и микрокод на котором написаны все те же "Принципы работы МФ".
Микрокод - это ведь software с точки зрения разработчиков МФ? Тогда слой этого микрокода реализует гипервизор 1-го типа. Если zVM хоть немного считать ОС общего назначения, то она реализует уже гипервизор 2-го типа. Особенно, если при этом она как-то расширяет функционал гипервизора за счет возможностей ОС, недоступных в слое микрокода. Если же функционал гипервизора и zVM полностью независимы (настолько я не знаком с zVM, чтобы определить это), то такая типизация теряет смысл, поскольку zVM переиспользует гипервизор 1-го типа, находясь рядом с ним, но не являясь гипервизором 2-го типа.
Процедура — блок кода, выполняющий определенную логику, не возвращающий значение. Предлагаю считать это понятие подмножеством функции и убрать из обихода, добавив определение процедурного стиля.
Чтобы лучше понять разницу между функциями и процедурами, можно рассмотреть понятия переменных (variables) и "присваеваемых" (assignables). Не знаю, как лучше перевести, можно думать о них, как о ячейках памяти. Часто в литературе их также называют переменными, что скрывает различие между variable и assignable. Переменные вводятся с помощью функциональной абстракции, а смысл им придается с помощью подстановок. Например, 1-арная лямбда-функция связывает переменную-аргумент с выражением: lambda(x){x+3}(2); -> 5 "Присваевыемые" вводятся с помощью объявления, а смысл им придается с помощью присваивания и возвращения содержимого. Например, 0-арная лямбда-функция может использовать значение ранее объявленной "присваеваемой": declare x=2; lambda(){x+3}(); -> 5
Далее, у нас есть функции, в которые подставляются значения переменных для получения возвращаемого значения. Также, у нас есть команды, которые выполняются ради побочных эффектов над "присваиваемыми".
Процедура — это функция, которая возвращает невыполненную команду в качестве значения. Вызов процедуры — это композиция применения функции (возвращающей команду) и вызова этой команды.
Вы перепутали статью на 39 страниц и тезисы на 249 с похожим названием. Это оттуда
На мой взгляд наоборот: на математике вся компьютерная наука держится. Например, теория типов. Она применяется, как для определения свойств безопасности языков, например тех же инструкций x86 или другого набора. Так и для упрощения отладки и много чего еще. Без строгих математических оснований ничего бы столь сложного, как машины и операционные системы, не существовало бы.
В Википедии ссылаются на тезисы Гольдберга 1973 года "Architectural Principles for Virtual Computer Systems", где он впервые ввел эту типизацию.
Собственно, Таненбаум тоже ссылается на Гольдберга 1974 года, когда пишет про чувствительные инструкции.
А архитектура x86 появилась в 1978 году только.
Кажется, пришло время цитировать Таненбаума:
Для любого обычного компьютера может быть создан монитор виртуальной машины, если набор чувствительных инструкций для этого компьютера является подмножеством набора привилегированных инструкций...
Чувствительная к управлению инструкция (control sensitive instruction) – это инструкция, которая может повлиять на конфигурацию машины...
Инструкция, чувствительная к поведению (behavior sensitive instruction) – это команда, действие которой частично определяется контекстом, в котором она выполняется...
...не все наборы инструкций имеют конфиденциальные (т.е. чувствительные?) инструкции только для привилегированных пользователей, в том числе, пожалуй, самый популярный – набор инструкций Intel x86. Как оказалось, в этом наборе 17 конфиденциальных инструкций, которые не являются привилегированными.
...пока конфиденциальные инструкции перехватываются при выполнении в пользовательском режиме, мы можем безопасно выполнять все нечувствительные инструкции непосредственно на базовом оборудовании.
Могу предположить, что чудесные свойства архитектуры, описываемой в статье, следуют из того, что набор чувствительных инструкций является подмножеством привилегированных. А для x86 приходится либо использовать эмуляцию, либо паравиртуализацию, либо еще что-то.
В случае нашего HPC вообще просто: гостевому Линуксу одному отдаются все доступные ресурсы. Т.е. аппаратные средства (или по-другому Power PHYP native bare-metal hypervisor in firmware) запускают одну ОС в одной партиции и больше ничего особенного не делают. Все дублирующие элементы машины с несколькими процессорами https://shorturl.at/3OfVx используются только для эффективности вычислений.
Могу предположить, что в случае z/VM одного функционала bare-metal hypervisor недостаточно, и требуется поддержка на уровне самой специализированной ОС z/VM (программного гипервизора в вашей терминологии), чтобы запускать тысячи гостевых машин на каком-то меньшем числе партиций LPAR мейнфрейма.
С моей точки зрения, оба они программные гипервизоры, просто один из них находится в firmware, а другой - в ОС z/VM. И этому гипервизору в ОС z/VM требуется поддержка микропрограмм процессоров, упомянутая в статье, чтобы эффективнее осуществлять свою виртуализирующую деятельность.
Освежил свои представления и оказалось, что в PowerPC Linux используется POWER Hypervisor, аналогичный мейнфреймовским. Приведу здесь немного информации об архитектуре из https://en.wikipedia.org/wiki/Hypervisor для удобства:
IBM provides virtualization partition technology known as logical partitioning (LPAR) on System/390, zSeries, pSeries and IBM AS/400 systems. For IBM's Power Systems, the POWER Hypervisor (PHYP) is a native (bare-metal) hypervisor in firmware and provides isolation between LPARs...For real-mode addressing by operating systems (AIX, Linux, IBM i), the Power processors (POWER4 onwards) have designed virtualization capabilities where a hardware address-offset is evaluated with the OS address-offset to arrive at the physical memory address.
Похоже, что для LPAR технологии не обязательны мейнфреймовские процессоры, она в таком же виде существует и для RISC POWER процессоров. Linux после petitboot просто грузится как гостевая ОС. А гипервизор реализован на уровне firmware, не требуя особой поддержки от микропрограмм процессоров .
Я имел дело с серверами IBM на архитектуре Power и под ОС Linux, но не с мейнфреймами. И на HPC кластере, без виртуализации. Больше всего запомнилось отличие petitboot загрузчика (PowerPC на Linux) от загрузчика x86. https://sthbrx.github.io/blog/2016/05/13/tell-me-about-petitboot/
Если я правильно понимаю, разработчик мейнфрейма IBM (я не имею ввиду прикладного разработчика под ОС z/VM) может заниматься как разработкой прошивки процессора (firmware), так и разработкой самой ОС z/VM. В силу того, что компания занимается и железом и софтом. Не знаю, как у процессоров мейнфрейма, но для разных устройств прошивка (например, firmware for IBM Power System) - это обычное ПО, которое также разрабатывается, легко меняется и обновляется.
Мне представляется, что аналогично тому, как в firmware маршрутизатора можно реализовать функционал, например, брандмауэра, так и в firmware мейнфрейма (в т.ч. его процессоров) можно реализовать функционал гипервизора. И он будет 1-го типа, поскольку близок к железу и узкоспециализированный.
Микрокод - это ведь software с точки зрения разработчиков МФ? Тогда слой этого микрокода реализует гипервизор 1-го типа. Если zVM хоть немного считать ОС общего назначения, то она реализует уже гипервизор 2-го типа. Особенно, если при этом она как-то расширяет функционал гипервизора за счет возможностей ОС, недоступных в слое микрокода. Если же функционал гипервизора и zVM полностью независимы (настолько я не знаком с zVM, чтобы определить это), то такая типизация теряет смысл, поскольку zVM переиспользует гипервизор 1-го типа, находясь рядом с ним, но не являясь гипервизором 2-го типа.
Каждая архитектура на основе микрослужб содержит наполовину сломанную реимплементацию Erlang
Чтобы лучше понять разницу между функциями и процедурами, можно рассмотреть понятия переменных (variables) и "присваеваемых" (assignables). Не знаю, как лучше перевести, можно думать о них, как о ячейках памяти. Часто в литературе их также называют переменными, что скрывает различие между variable и assignable. Переменные вводятся с помощью функциональной абстракции, а смысл им придается с помощью подстановок. Например, 1-арная лямбда-функция связывает переменную-аргумент с выражением:
lambda(x){x+3}(2); -> 5"Присваевыемые" вводятся с помощью объявления, а смысл им придается с помощью присваивания и возвращения содержимого. Например, 0-арная лямбда-функция может использовать значение ранее объявленной "присваеваемой":declare x=2; lambda(){x+3}(); -> 5Далее, у нас есть функции, в которые подставляются значения переменных для получения возвращаемого значения. Также, у нас есть команды, которые выполняются ради побочных эффектов над "присваиваемыми".
Процедура — это функция, которая возвращает невыполненную команду в качестве значения. Вызов процедуры — это композиция применения функции (возвращающей команду) и вызова этой команды.
Подробнее об этом, например, в Harper: Practical Foundations for Programming Languages