СРЕДСТВО ФУНКЦИОНАЛЬНОЙ ВИРТУАЛИЗАЦИИ ДЛЯ БЛОКИРОВКИ КОМАНДНОЙ ФУНКЦИИ МНОГОФУНКЦИОНАЛЬНОЙ КОМАНДЫ ВИРТУАЛЬНОГО ПРОЦЕССА

ОБЛАСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение относится к компьютерным системам и, более конкретно, к командной функциональности процессора компьютерной системы.

ПРЕДПОСЫЛКИ ИЗОБРЕТЕНИЯ

Торговые марки: IBM® является зарегистрированной торговой маркой корпорации International Business Machines, Армонк, штат Нью-Йорк, США. S/390, Z900, 7.990, z10 и другие названия изделий могут быть зарегистрированными торговыми марками или названиями изделий корпорации International Business Machines или других компаний.

IBM создала трудом многих высококвалифицированных инженеров, начиная с машин, известных как IBM® System 360 в 1960-х до настоящего времени, особую архитектуру, которая, из-за ее существенной природы для вычислительной системы, стала известна как "мейнфрейм", принципы работы которого устанавливают архитектуру машины описанием команд, которые могут выполняться на реализации команд "мейнфрейма", которые были изобретены изобретателями IBM и приняты, из-за их значительного вклада в улучшение состояния вычислительной машины, представленной "мейнфреймом", как значительные вклады по включению в Принципы работы IBM, как установлено за все эти годы. Восьмое издание IBM® z/Architecture® Principles of Operation (Принципы работы IBM® z/Architecture®), которое было опубликовано в феврале 2009, стало стандартным опубликованным справочником как SA22-7832-07 и включено в серверы-мейнфреймы IBM's z10®, включая серверы IBM System z10® Enterprise Class.

Согласно ФИГ.1А, изображены представительные компоненты системы Основного Компьютера 50 из уровня техники. Также в компьютерной системе могут применяться другие конфигурации компонентов, которые хорошо известны из уровня техники. Представительный основной компьютер 50 содержит одно или более ЦПУ 1 в связи с главным запоминающим устройством (компьютерная память 2), а также интерфейсы ввода-вывода к устройствам хранения 11 и сетям 10 для связи с другими компьютерами или SAN и тому подобным. ЦПУ 1 соответствует архитектуре, имеющей разработанный набор команд и разработанную функциональность. ЦПУ 1 может иметь динамическую трансляцию адресов (Dynamic Address Translation, DAT) 3 для преобразования программных адресов (виртуальных адресов) в реальный адрес в памяти. DAT обычно включает буфер динамической трансляции адресов (Translation Lookaside Buffer, TLB) 7 для кэширования трансляций, так что последующие обращения к блоку компьютерной памяти 2 не требуют задержки на трансляцию адреса. Обычно применяется кэш 9 между компьютерной памятью 2 и процессором 1. Кэш 9 может быть иерархическим, имеющим большой кэш, доступный для более чем одного ЦПУ, и меньшие, более быстрые кэши (низшего уровня) между большим кэшем и каждым ЦПУ. В некоторых реализациях кэши низшего уровня разделены, чтобы обеспечить отдельные низкоуровневые кэши для считывания команд и обращений к данным. В варианте реализации, команда считывается из памяти 2 устройством считывания команд 4 через кэш 9. Команда декодируется в устройстве декодирования команд 6 и передается (с другими командами в некоторых реализациях) устройствам выполнения команд 8. Обычно применяется несколько устройств выполнения 8, например, арифметическое устройство выполнения, устройство выполнения с плавающей точкой и устройство выполнения команд ветвления. Команда выполняется устройством выполнения, обращаясь к операндам из заданных командой регистров или памяти, по необходимости. Если следует обратиться (загрузить или сохранить) к операнду из памяти 2, устройство загрузки-сохранения 5 обычно обрабатывает обращение под управлением команды, которая выполняется. Команды могут выполняться в аппаратных схемах или во внутреннем микрокоде (микропрограмме), или сочетанием их обоих.

На ФИГ.1Б предоставлена эмулируемая основная компьютерная система 21 из уровня техники, которая эмулирует основную компьютерную систему 50 с основной архитектурой. В эмулируемой основной компьютерной системе 21, основной процессор (ЦПУ) 1 является эмулируемым основным процессором (или виртуальным основным процессором) и содержит эмуляционный процессор 27, имеющий иную архитектуру набора собственных команд, чем процессор 1 основного компьютера 50. Эмулируемая основная компьютерная система 21 имеет память 22, доступную эмуляционному процессору 27. В примере реализации, память 2 разделена на часть памяти основного компьютера 2 и часть подпрограмм эмуляции 23. Память основного компьютера 2 доступна программам эмулируемого основного компьютера 21 согласно архитектуре основного компьютера. Эмуляционный процессор 27 выполняет собственные команды разработанного набора команд архитектуры, отличной от архитектуры эмулируемого процессора 1, собственные команды получены из памяти подпрограмм эмуляции 23, и могут получить доступ к команде основной машины для выполнения из программы в памяти основного компьютера 2 с применением одной или более команд, полученных в последовательности, и подпрограммы доступа/декодирования, которая может декодировать команды основной машины, к которым получен доступ, чтобы определить подпрограмму выполнения собственной команды для эмулирования функции команды основной машины, к которой получен доступ. Другие средства, которые определены для архитектуры основной компьютерной системы 50, могут быть эмулированы подпрограммами разработанных средств, включая такие средства, как регистры общего назначения, управляющие регистры, динамическая трансляция адресов, и поддержка подсистемы ввода-вывода и кэш процессора, к примеру. Подпрограммы эмуляции также могут использовать преимущества функций, доступных в эмуляционном процессоре 27 (таких как регистры общего назначения и динамическая трансляция виртуальных адресов) для улучшения производительности подпрограмм эмуляции. Также могут предоставляться специальные аппаратные и разгрузочные устройства для содействия процессору 27 в эмулировании функций основного компьютера 50.

На мейнфрейме разработанные машинные команды используются программистами, сейчас обычно программистами на "С", часто с применением компилятора. Эти команды, хранящиеся в запоминающем устройстве, могут выполняться собственно на сервере z/Architecture IBM, или же на машинах, выполняющих другие архитектуры. Они могут эмулироваться на существующих или будущих серверах-мейнфреймах IBM и на других машинах IBM (напр. серверах pSeries® и серверах xSeries®). Они могут выполняться на машинах с запущенным Linux на множестве машин, использующих аппаратное обеспечение производства IBM®, Intel®, AMD™, Sun Microsystems и других. Кроме выполнения на этом аппаратном обеспечении под z/Architecture®, Linux может также использоваться на машинах, которые используют эмуляцию, как описано на http://www.turbohercules.com, http://www.hercules-390.org и http://www.funsoft.com. В режиме эмуляции, эмуляционное программное обеспечение выполняется собственным процессором для эмулирования архитектуры эмулируемого процессора.

Собственный процессор 27 обычно выполняет эмуляционное программное обеспечение 23. содержащее либо микропрограмму, либо собственную операционную систему для осуществления эмуляции эмулируемого процессора. Эмуляционное программное обеспечение 23 отвечает за считывание и выполнение команд эмулируемой архитектуры процессора. Эмуляционное программное обеспечение 23 поддерживает эмулируемый программный счетчик для отслеживания границ команды. Эмуляционное программное обеспечение 23 может считывать одну или более эмулируемых машинных команд за раз и преобразовывать одну или более эмулируемых машинных команд в соответствующую группу собственных машинных команд для выполнения собственным процессором 27. Эти преобразованные команды могут быть кэшированы, так что можно достичь более быстрого преобразования. Тем не менее, эмуляционное программное обеспечение должно поддерживать архитектурные правила эмулируемой архитектуры процессора для обеспечения корректной работы операционных систем и приложений, написанных для эмулируемого процессора. Более того, эмуляционное программное обеспечение должно предоставлять ресурсы, идентифицируемые архитектурой эмулируемого процессора 1, включая, но не ограничиваясь, управляющие регистры, регистры общего назначения, регистры с плавающей точкой, функцию динамической трансляции адресов, включающую, например, таблицы сегментов и таблицы страниц, механизмы прерывания, механизмы контекстного переключения, часы истинного времени (Time of Day, TOD) и разработанные интерфейсы к подсистемам ввода-вывода, так что операционная система или прикладная программа, предназначенная для запуска на эмулируемом процессоре, может запускаться на собственном процессоре, имеющем эмуляционное программное обеспечение.

Конкретная команда, которая выполняется, декодируется, и вызывается подпрограмма для осуществления функции отдельной команды. Функция эмуляционного программного обеспечения 23, эмулирующая функцию эмулируемого процессора 1, реализуется, например, в подпрограмме на "С" или драйвере, или другом способе предоставления драйвера для специфического аппаратного обеспечения, в пределах квалификации специалистов из уровня техники после понимания описания предпочтительного варианта реализации. Различные патенты касательно программной и аппаратной эмуляции включают, но не ограничиваются, патент США 5551013 "Мультипроцессор для аппаратной эмуляции" авторства Beausoleil и др., патент США S6009261 "Предварительная обработка сохраненных целевых подпрограмм для эмулирования несовместимых команд на целевом процессоре" авторства Scalzi и др;

патент США 5574873 "Декодирование гостевых команд для прямого доступа к подпрограммам эмуляции, которые эмулируют гостевые команды" авторства Davidian и др, патент США 6308255 "Симметричная многопроцессорная шина и набор микросхем, использующиеся для поддержки сопроцессора, позволяющей запуск несобственного кода на системе" авторства Gorishek и др., патент США 6463582 "Динамический оптимизирующий транслятор объектного кода для эмуляции архитектуры и метод динамической оптимизирующей трансляции объектного кода" авторства Lethin и др., и патент США 5790825 "Метод эмулирования гостевых команд на основном компьютере посредством динамической рекомпиляции команд основной машины" авторства Eric Traut. Эти ссылки иллюстрируют множество известных способов достижения эмуляции формата команд, разработанного для другой машины, на целевой машине, известных специалистам из уровня техники, а также промышленные программные методики, используемые вышеупомянутыми.

В публикации США № US 2009/0222814 A1, опубликованной 3 сентября 2009, Astrand, "Выборочное предоставление функциональности устройства USB виртуальной машине" приложение виртуальной машины (VM) может запускать гостевую операционную систему (OS) и разрешать гостевой OS соединяться с устройствами USB, подключенными к компьютеру. Программа VM может фильтровать функции, связанные с устройством USB, так что только некоторые из функций устройства USB предоставляются гостевой OS.

Опубликованная патентная заявка США US 2005/0188171 A1 описывает программный загрузчик внутри доверенной вычислительной базы, который переназначает коды операций в коде при помощи карты кодов операции перед загрузкой кодов операции в конвейер выполнения для процессора. Вредоносный код, который попытается выполниться напрямую на процессоре, а не посредством загрузчика, не получит переназначенные коды операций, и таким образом не выполнится корректно.

Опубликованная заявка РСТ WO 00/67115 A1 описывает микроконтроллер, в котором бит статуса проверяется механизмом блокировки/деблокировки для определения, блокирована команда или нет. Или же, деблокиратор сравнивает команды с предопределенным списком специальных команд, поддерживаемых деблокиратором.

Публикация Advanced Micro Devices: "Live Migration with AMD-V Extended Migration Technology", ("Динамическая миграция с помощью технологии расширенной миграции AMD-V"), 30 апреля 2008 (2008-04-30), страницы 1-17, излагает управление при помощи монитора виртуальной машины (Virtual Machine Monitor, VMM) информацией, возвращаемой гостевому программному обеспечению как результат команды CPUID. Такая виртуализация с аппаратной поддержкой при помощи VMM может использовать перехват CPUID, чтобы возвращать соответствующие биты каждый раз, когда гостевое программное обеспечение выполняет команду CPUID. Это реализуется при помощи модель-специфичных регистров (Model Specific Registers, MSR), предоставляющих функцию замены функции CPUID для определения подмножества информации, которую возвращает команда CPUID. Это показывает потребность в способе для выключения новых команд, пока во всех процессорах ресурсного пула процессоров не будут реализованы новые команды. Это предполагает, что AMD может поддерживать биты отключения особенностей для выключения некоторых команд или наборов команд.

КРАТКОЕ ИЗЛОЖЕНИЕ ИЗОБРЕТЕНИЯ

В соответствии с изобретением предусмотрено блокирование определенных команд от выполнения логическим процессором, выполняющим виртуальную машину, т.е. блокирование выполнения команд логическим процессором. Устанавливается значение блокировки команд, определенное для виртуальной машины, для блокировки выполнения команды. Команда считывается логическим процессором для выполнения процессором, команда содержит код операции и определяет код функции из множества кодов функций, код функции настроен на обозначение функции для выполнения командой, команда поддерживается одним или более процессоров. Определяется значение блокировки команд для считанной команды, имеющей код функции, посредством сопоставления значения блокировки команд, определенного для виртуальной машины, с кодом операции считанной команды. В зависимости от значения блокировки команд, разрешающего выполнение команды, имеющей код функции, считанная команда выполняется процессором. В зависимости от значения блокировки команд, не разрешающего выполнение команды, выполнение считанной команды блокируется и вызывается событие программного исключения (например, программное исключение).

В варианте реализации значение блокировки команд определено для виртуальной машины для блокировки выполнения команды, установка значения блокировки команд в зависимости от включения виртуальной машины для использования физического процессора; другое значение блокировки команд установлено, другое значение блокировки команд определено для другой виртуальной машины, имеющей другой логический процессор, установка другого значения блокировки команд в зависимости от включения другой виртуальной машины для использования физического процессора; и в зависимости от другого значения блокировки команд, разрешающего выполнение команды, разрешение выполнения команды другим логическим процессором; и в зависимости от другого значения блокировки команд, не разрешающего выполнение команды, не разрешение выполнения команды другим логическим процессором.

В варианте реализации команда является разрешенной командой, если команда применяет разрешенный код функции, тогда как команда является неразрешенной командой, если команда применяет неразрешенный код функции.

В варианте реализации выполняется определение, является ли команда разрешенной командой, посредством сопоставления кода операции команды со значением блокировки команд.

В варианте реализации считанная команда определяет функцию для выполнения, код операции используется для индексирования в таблице для нахождения значения блокировки команд, значение блокировки команд содержит поле допуска, поле допуска используется для определения разрешенных функций. Если функция является разрешенной функцией, разрешение выполнения команды, а если функция является неразрешенной функцией, неразрешение выполнения команды.

Вышесказанное, а также дополнительные задачи, особенности и преимущества станут понятны из следующего описания.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Варианты реализации изобретения теперь будут описаны, лишь для примера, с помощью сопроводительных чертежей, в которых:

На ФИГ.1а изображена схема примерной основной компьютерной системы;

На ФИГ.1Б изображена схема примерной эмуляционной основной компьютерной системы;

На ФИГ.1В изображена схема примерной компьютерной системы;

На ФИГ.2 изображена схема примерной компьютерной сети;

На ФИГ.3 изображена схема примерных элементов компьютерной системы;

На ФИГ.4А изображена схема примерного устройства выполнения;

На ФИГ.4Б изображена схема примерного устройства ветвления;

На ФИГ.4В изображена схема примерного устройства загрузки/сохранения;

На ФИГ.5 изображена схема примерного логического разбиения;

На ФИГ.6 изображена схема примерных элементов логического разбиения;

На ФИГ.7 изображена схема примерных элементов логического разбиения;

На ФИГ.8 изображена схема примерной таблицы кодов операции;

На ФИГ.9 изображена схема примерной методики блокировки;

На ФИГ.10 изображена схема примерной методики блокировки;

На ФИГ.11 изображена схема примерной методики блокировки; и

На ФИГ.12-15 изображены схемы методик блокировки команд.

ПОДРОБНОЕ ОПИСАНИЕ

Варианты реализации могут осуществляться программным обеспечением (иногда называющимся лицензионным внутренним кодом, микропрограммой, микрокодом, милликодом, пикокодом и тому подобным, каждое из которых будет соответствовать изложенному здесь). Согласно ФИГ.1А, программная реализация программного кода обычно считывается процессором, также известным как ЦПУ (центральное процессорное устройство) 1 системы 50 из постоянного запоминающего устройства 11, такого как привод CD-ROM, ленточный накопитель или жесткий диск. Программный код программы может быть реализован в одном из множества известных носителей для использования с системой обработки данных, таком как дискета, жесткий диск или CD-ROM. Код может распространяться на таких носителях, или может распространяться к пользователям из компьютерной памяти 2 или запоминающего устройства одной компьютерной системы через сеть 10 к другим компьютерным системам для использования пользователями таких других систем.

Или же, программный код может быть реализован в памяти 2, и считываться процессором 1 при помощи процессорной шины. Такой программный код включает операционную систему, которая управляет функционированием и взаимодействием различных компонентов компьютера, и одну или больше прикладных программ. Программный код обычно постранично считывается из жесткого запоминающего устройства 11 в высокоскоростную память 2, где он доступен для обработки процессором 1. Методики и способы реализации программного кода программы в памяти, на физическом носителе, и/или распространения программного кода через сети хорошо известны и далее не будут здесь обсуждаться. Программный код, будучи создан и сохранен на физическом носителе (включая, но не ограничиваясь, электронные модули памяти (RAM), флэш-память, компакт-диски (CD), DVD, магнитную ленту и тому подобное) часто называются «компьютерным программным продуктом». Носитель компьютерного программного продукта обычно считывается обрабатывающей схемой предпочтительно в компьютерной системе для выполнения обрабатывающей схемой.

На ФИГ.1В изображена представительная аппаратная система рабочей станции или сервера. Система 100 на ФИГ.1В содержит представительную компьютерную систему 101, такую как персональный компьютер, рабочая станция или сервер, включая опциональные периферийные устройства. Рабочая станция 101 включает один или более процессоров 106 и шину, использующуюся для соединения и обеспечения связи между процессор(ами) 106 и другими компонентами системы 101 в соответствии с известными методиками. Шина соединяет процессор 106 с памятью 105 и постоянным запоминающим устройством 107, которое может включать жесткий накопитель (включая любой из магнитных носителей, CD, DVD и флэш-память, к примеру) или ленточный накопитель, к примеру. Система 101 также может включать адаптер пользовательского интерфейса, который соединяет микропроцессор 106 через шину с одним или более интерфейсных устройств, таких как клавиатура 104, мышь 103, принтер/сканер 110 и/или другие интерфейсные устройства, которые могут быть любым устройством пользовательского интерфейса, таким как сенсорный экран, графический планшет и т.п. Шина также соединяет устройство отображения 102, такое как жидкокристаллический экран или монитор, с микропроцессором 106 через видеоадаптер.

Система 101 может связываться с другими компьютерами или сетями компьютеров посредством сетевого адаптера, способного связываться 108 с сетью 109. Примерами сетевых адаптеров являются каналы связи, token ring, Ethernet или модемы. Или же, рабочая станция 101 может связываться с помощью беспроводного интерфейса, такого как карта передачи цифровых пакетных данных по сотовой связи (CDPD, cellular digital packet data). Рабочая станция 101 может быть связана с другими такими компьютерами в локальной сети (Local Area Network, LAN) или глобальной сети (Wide Area Network, WAN), или рабочая станция 101 может быть клиентом в конфигурации клиент/сервер с другим компьютером и т.д. Все эти конфигурации, а также соответствующее аппаратное и программное обеспечение связи, известны из уровня техники.

На ФИГ.2 изображена сеть обработки данных 200, в которой варианты могут быть реализованы. Сеть обработки данных 200 может включать множество индивидуальных сетей, таких как беспроводная сеть и проводная сеть, каждая из которых может включать множество индивидуальных рабочих станций 101 201 202 203 204. Дополнительно, как будет понятно специалистам из уровня техники, может быть включена одна или более LAN, где LAN может включать множество интеллектуальных рабочих станций, соединенных с основным процессором.

Согласно той же ФИГ. 2, сети могут также включать компьютеры-мейнфреймы или серверы, такие как машина-шлюз (клиент-сервер 206) или сервер приложений (удаленный сервер 208, который может обращаться к репозиторию данных, и к которому также можно обращаться напрямую с рабочей станции 205). Машина-шлюз 206 служит точкой входа в каждую сеть 207. Шлюз необходим при соединении одного сетевого протокола с другим. Шлюз 206 предпочтительно может соединяться с другой сетью (Интернет 207, к примеру) при помощи линии связи. Шлюз 206 также может соединяться напрямую с одной или более рабочих станций 101 201 202 203 204 при помощи линии связи. Машина-шлюз может быть реализована с использованием сервера IBM eServer™ zSeries® z9®, доступного от корп. IBM.

Программный код программы обычно считывается процессором 106 системы 101 из постоянного запоминающего устройства 107, такого как привод CD-ROM или жесткий диск. Программный код программы может быть реализован в одном из множества известных носителей для использования с системой обработки данных, таком как дискета, жесткий диск или CD-ROM. Код может распространяться на таких носителях, или может распространяться к пользователям 210 211 из памяти или запоминающего устройства одной компьютерной системы через сеть к другим компьютерным системам для использования пользователями таких других систем.

Или же, программный код 111 может быть реализован в памяти 105, и считываться процессором 106 при помощи процессорной шины. Такой программный код включает операционную систему, которая управляет функционированием и взаимодействием различных компонентов компьютера, и одну или больше прикладных программ 112. Программный код обычно постранично считывается из жесткого запоминающего устройства 107 в высокоскоростную память 105, где он доступен для обработки процессором 106. Методики и способы реализации программного кода программы в памяти, на физическом носителе, и/или распространения программного кода через сети хорошо известны и далее не будут здесь обсуждаться. Программный код, будучи создан и сохранен на физическом носителе (включая, но не ограничиваясь, электронные модули памяти (RAM), флэш-память, компакт-диски (CD), DVD, магнитную ленту и тому подобное) часто называются «компьютерным программным продуктом». Носитель компьютерного программного продукта обычно считывается обрабатывающей схемой предпочтительно в компьютерной системе для выполнения обрабатывающей схемой.

Кэш, который наиболее легкодоступен процессору (обычно быстрее и меньше, чем другие кэши процессора) является наинизшим кэшем (уровня один или L1), a главное запоминающее устройство (главная память) является кэшем наивысшего уровня (L3, если есть 3 уровня). Кэш наинизшего уровня часто делится на кэш команд (I-Cache), хранящий машинные команды для выполнения, и кэш данных (D-Cache), хранящий операнды данных.

Согласно ФИГ.3, изображена примерная реализация процессора для процессора 106. Обычно один или более уровней кэша 303 задействуются для буферизации блоков памяти, чтобы улучшить производительность процессора. Кэш 303 является высокоскоростным буфером, хранящим строки кэша данных из памяти, которые, вероятно, будут использоваться. Обычные строки кэша содержат 64, 128 или 256 байт данных из памяти. Отдельные кэши чаще используются для кэширования команд, чем для кэширования данных. Согласованность кэша (синхронизация копий строк в памяти и кэшах) часто обеспечивается различными алгоритмами слежения, хорошо известными из уровня техники. Главная память 105 процессорной системы часто называется кэшем. В процессорной системе, имеющей 4 уровня кэша 303, главная память 105 иногда называется кэшем уровня 5 (L5), поскольку она обычно более быстрая и хранит только часть постоянного запоминающего устройства (DASD, лента и т.п.), которое доступно компьютерной системе. Главная память 105 «кэширует» страницы данных, перемещаемые в и из главной памяти 105 операционной системой.

Программный счетчик (счетчик команд) 311 отслеживает адрес текущей команды для выполнения. Программный счетчик в процессоре z/Architecture 64-битный и может быть усечен до 31 или 24 бит для поддержки предыдущих границ адресации. Программный счетчик обычно встроен в слово статуса программы (PSW, program status word) компьютера, так что он сохраняется во время контекстного переключения. Таким образом, работающая программа, имеющая значение программного счетчика, может быть прервана, например, операционной системой (контекстное переключение из среды программы в среду операционной системы). PSW программы сохраняет значение программного счетчика, пока программа неактивна, а программный счетчик (в PSW) операционной системы используется, пока операционная система выполняется. Обычно программный счетчик увеличивается на величину, равную числу байт текущей команды. Команды архитектуры с сокращенным набором команд (RISC, Reduced Instruction Set Computing) обычно имеют постоянную длину, тогда как команды архитектуры с полным набором команд (CISC, Complex Instruction Set Computing) обычно имеют переменную длину. Команды архитектуры IBM z/Architecture являются командами CISC, имеющими длину 2, 4 или 6 байт. Программный счетчик 311 модифицируется либо операцией контекстного переключения, либо операцией выбора ветви команды ветвления, к примеру. В операции контекстного переключения текущее значение программного счетчика сохраняется в слове статуса программы (PSW) вместе с другой информацией о состоянии программы, которая выполняется, (такой как коды состояния), и загружается новое значение программного счетчика, указывающее на команду нового программного модуля для выполнения. Операция выбора ветви производится для того, чтобы позволить программе принимать решения или замыкать цикл внутри программы, загружая результат команды ветвления в программный счетчик 311.

Обычно устройство считывания команд 305 задействуется для считывания команд для процессора 106. Устройство считывания либо считывает «следующие команды в последовательности», целевые команды команд выбора ветви, либо первые команды программы вслед за контекстным переключением. Современные устройства считывания команд часто задействуют методики предварительного считывания для предположительного предварительного считывания команд на основе вероятности того, что предварительно считанные команды могут использоваться. Например, устройство считывания может считать 16 байт команды, которая включает следующую команду в последовательности и дополнительные байты дальнейших команд в последовательности.

Затем считанные команды выполняются процессором 106. В варианте реализации считанные команд(ы) проходят через устройство передачи 306 устройства считывания. Устройство передачи декодирует команд(ы) и направляет информацию о декодированных команд(ах) соответствующим устройствам 307, 308, 310. Устройство выполнения 307 обычно получит информацию о декодированных арифметических командах из устройства считывания команд 305 и выполнит арифметические операции над операндами в соответствии с кодом операции команды. Операнды предоставляются устройству выполнения 307 предпочтительно либо из памяти 105, архитектурных регистров 309, либо из непосредственного поля команды, которая выполняется. Результаты выполнения, если сохраняются, сохраняются либо в памяти 105, регистрах 309, либо в другом аппаратном обеспечении машины (таком как управляющие регистры, регистры PSW и тому подобное).

Согласно ФИГ.5, изображена примерная среда виртуальной машины (VM). Программа-гипервизор (которая может сама быть операционной системой (OS), такой как zVM от IBM) может быть запущена на многопроцессорном «аппаратном обеспечении», содержащем множество физических процессоров, физическую главную память и физические адаптеры для связи с периферийными устройствами ввода-вывода, включая запоминающие устройства, сети, дисплеи и тому подобное. Гипервизор создает образы VM (VM1, VM2 и VM3, например), так что программное обеспечение, включая OS и прикладные программы, может запускаться внутри виртуальной машины, используя виртуальные ресурсы. Программное обеспечение, запущенное в VM, не знает, что запущено в VM, и работает, используя виртуальные ресурсы, как если бы это были физические ресурсы. Операционная система zVM от IBM может создавать «гостевые» образы, каждый гостевой образ фактически является виртуальной машиной. Более того, любой гость zVM может сам запускать zVM OS, создающую «гостей второго уровня». Таким образом, виртуальная машина (гостевой образ) может быть вложена в иерархии виртуальных машин, а каждая zVM играет роль гипервизора для ее гостевых образов. С другой стороны, многопроцессорная платформа может быть «физически распределена», и каждому физическому разделу могут быть назначены ресурсы (процессоры, память, ввод-вывод). Каждый физический раздел является VM, так как программное обеспечение, запущенное в разделе, не знает о ресурсах машины, не назначенных разделу. Таким образом, ресурсы машины «виртуализуются». В другом варианте реализации логические разделы являются VM.

Термины «Гости», «Виртуальные Машины» (VM) и «Логические разделы» могут использоваться в данном контексте взаимозаменяемо, так как есть много способов, известных из уровня техники, для виртуализации образа компьютерной системы.

Виртуализация описана, например, в официальной документации VMware®, озаглавленной «Virtualization Overview» («Обзор виртуализации») и «VMware VMotion and CPU Compatibility» («VMware VMotion и совместимость ЦПУ») VMware® инфраструктуры 3 от VMware®. Далее, в патентной заявке США, публикация №2009/0070760 «Миграция виртуальных машин (VM) между архитектурами процессора» авторства Khatri и др., поданной 6 сентября 2007, обсуждается эмуляция набора некоторых особенностей для обеспечения миграции VM между одинаковыми пулами машин посредством маскировки выбранных бит регистра CPUID.

Согласно ФИГ.6, каждая VM может иметь различную OS и различные приложения. Например, OS1 может быть z/OS от IBM, a OS2 может быть zLinux от IBM, или все OS могут быть одинаковыми OS, такими как z/OS.

Гипервизор создает Логические Особенности, ресурсы и средства для каждой VM на основе физических особенностей, ресурсов и средств. В примерной системе части Физической Памяти могут быть выделены каждой VM посредством Динамической Трансляции Адресов, физические процессоры могут быть разделены во времени между VM, как и средства ввода-вывода.

Согласно ФИГ.7, каждый логический процессор может иметь доступ к регистрам физических особенностей посредством управляемой Гипервизором Маски Логических Особенностей. Таким образом, программное обеспечение, запущенное на логических процессорах, может создать видимость работы на общем уровне Архитектуры процессора, даже если действительные процессоры находятся на различных уровнях архитектуры. В примере, регистр Физических Особенностей может быть регистром Intel CPUID, который указывает уровень архитектуры процессора Intel, а также специфические особенности, которые доступны программисту. Маска Логических особенностей программируется для предоставления CPUID всех или подмножества физических процессоров программному обеспечению в Виртуальной Машине (VM), когда VM запрашивает CPUID соответствующего Логического процессора.

Архитектура процессора х86 от Intel®, «Intel® Itanium® Architecture Software Developer's Manual» (Руководство разработчика программного обеспечения для архитектуры Intel® Itanium®), том 2, редакция 2.2, январь 2006, предоставляет регистры CPUID для идентификации особенностей, поддерживаемых процессором. Регистры CPUID непривилегированны и доступны при помощи косвенной команды перемещения (из). Все регистры за пределами номера регистра CPUID зарезервированы и выдают ошибку Зарезервированного Регистра/Поля, если к ним обращаются. Запись не разрешена и не существует команды для такой операции. Информация о поставщике располагается в регистрах CPUID 0 и 1 и указывает название поставщика в ASCII, для реализации процессора. Все байты после конца строки вплоть до 16-го байта равны нулю. Первые символы ASCII располагаются в регистрах с низшим номером и в разрядах с низшим номером. Регистр CPUID 4 предоставляет общие сведения уровня приложения об особенностях процессора. Он содержит набор бит флага, использующихся для обозначения того, что данная особенность поддерживается в модели процессора. Если бит равен единице, особенность поддерживается; если 0, особенность не поддерживается. Так как добавляются (или удаляются) новые особенности в будущих моделях процессоров, присутствие (или удаление) новых особенностей будет обозначаться новыми битами особенностей. Регистр CPUID 4 логически разбит на две половинки, каждая из которых содержит общие сведения об особенностях и возможностях, но каждая имеет различные модели использования и возможности доступа; эти сведения отображают статус любых включенных и выключенных особенностей. Как нижняя, так и верхняя половины регистра CPUID 4 доступны через команду перемещения косвенного регистра; в зависимости от реализации, латентность для такого доступа может быть большой, и этот способ доступа не подходит для низколатентного управления версиями кода с использованием самостоятельного выбора. Кроме того, верхняя половина регистра CPUID 4 также доступна при помощи команды проверки особенностей; латентность для этого доступа сравнима с таковой команды проверки бита, и этот способ доступа позволяет низколатентное управление версиями кода с использованием самостоятельного выбора.

z/Architecture Principles of Operation предоставляет команду расширенного сохранения списка средств (Store Facility List Extended, STFLE), которая, подобно регистру Intel CPUID, обеспечивает программное обеспечение сведениями об особенностях (или уровнях архитектуры) нижележащих центральных процессорных устройств (ЦПУ), или процессоров. Команда STFLE имеет формат, приведенный в Таблице 1 ниже.

Команда STFLE (Таблица 1) содержит биты поля Кода Операции (0-15), поле регистров B2 (16-19) и поле смещения (непосредственное) D2 (20-31). Выполнение команды STFLE машиной сохраняет список бит, предоставляющих информацию о средствах, в ячейку памяти программ, определенную прибавлением содержимого регистра, заданного полем В2 команды, к 12-битному непосредственному полю D2, ячейка памяти начинается с двойного слова (8 байт, слово равно 4 байтам), заданного адресом второго операнда ((B2)+D2). Адрес ячейки программной памяти в z/Architecture подвергается Динамической Трансляции Адресов (Dynamic Address Translation, DAT).

Зарезервированные биты являются битами, которые сейчас не предназначены для обозначения особенности. Для самых левых двойных слов, в которых назначены биты средства, зарезервированные биты сохраняются как нули. Двойные слова справа от двойного слова, в котором бит средства с наивысшим номером назначен для модели, могут сохраняться или не сохраняться. Исключения доступа и события PER не обнаруживаются для двойных слов, которые не сохраняются. Размер второго операнда в двойных словах на один больше, чем значение, заданное в битах 56-63 регистра общего назначения 0. Оставшиеся биты регистра общего назначения 0 не назначены и должны содержать нули; иначе, программа не сможет совместимо работать в будущем.

Если размер второго операнда достаточно большой, чтобы содержать все биты средств, назначенные для модели, то полный список средств сохраняется в ячейке первого операнда, биты 56-63 регистра общего назначения 0 обновляются так, чтобы содержать на один меньше, чем число двойных слов, необходимых, чтобы содержать все биты средств, назначенные для модели, и устанавливается код состояния 0.

Если размер второго операнда недостаточно большой, чтобы содержать все биты средств, назначенные для модели, то сохраняется только число двойных слов, заданных размером второго операнда, биты 56-63 регистра общего назначения 0 обновляются так, чтобы содержать на один меньше, чем число двойных слов, необходимых, чтобы содержать все биты средств, назначенные для модели, и устанавливается код состояния 3.

Выполнение команды приводит к установке значения Кода Состояния, где Код Состояния сохраняется во время контекстного переключения в Слове Статуса Программы (PSW).

Особые состояния:

Второй операнд должен быть упорядочен по границе двойного слова; иначе обнаруживается исключение определения.

Результирующий Код Состояния:

0 Сохранен полный список средств

1 -

2 -

3 Сохранен неполный список средств

Программные исключения:

- Доступ (запись, второй операнд)

- Операция (если средство расширенного сохранения списка средств не установлено)

- Определение

Примечания о программировании:

Производительность STORE FACILITY LIST EXTENDED может быть значительно ниже, чем таковая простой проверки байта в памяти. Программы, которые требуют частой проверки наличия средства, например, двухканальный код, в котором средство используется в одном канале, но не в другом, должны выполнять команду STORE FACILITY LIST EXTENDED один раз при инициализации. Впоследствии программа может проверять наличие средства, просматривая сохраненный результат при помощи команды, такой как TEST UNDER MASK (проверить по маске).

Если установлен код состояния 0, биты 56-63 регистра общего назначения О обновляются так, чтобы указывать число двойных слов, которые сохраняются. Если программа выбирает игнорировать результаты в регистре общего назначения 0, то она должна убедиться, что весь второй операнд в памяти установлен в нуль, перед выполнением команды STORE FACILITY LIST EXTENDED.

В Таблице 2 приведены биты STFLE, назначенные z/Architecture из уровня техники, и их значение. Бит устанавливается в единицу независимо от текущего архитектурного режима, если его значение истинно. Значение применяется к текущему архитектурному режиму, если не указано его применение к специфическому архитектурному режиму.

Неназначенные биты резервируются для обозначения новых средств; эти биты могут сохраняться как единицы в будущем.

Список средств z/Architecture из уровня техники определен, как показано в Таблице 2 ниже:

Команда может выполнять одиночную функцию в архитектуре, или, в некоторых случаях, множество выбираемых функций. Выбираемые функции, определенные для команды, могут быть различными от машины к машине. Например, многофункциональная команда, будучи впервые введена в набор разработанных команд, может иметь лишь несколько выбираемых функций. Позже разработанный набор команд может вводить больше выбираемых функций в ранее введенную многофункциональную команду. В варианте реализации VM может быть назначено подмножество выбираемых функций физического процессора, посредством которых команда, запущенная на логическом процессоре VM, может запросить список доступных функций логического процессора, и возвращаются только функции, назначенные VM, даже если процессор может выполнять больше выбираемых функций. В варианте реализации это достигается через Средство Перехвата Функции, Обозначающей Команду, (Function-Indicating-Instruction Interception Facility, FIIIF), которая заставляет гипервизор улавливать, или перехватывать, выполнение этой функции запроса гостем (виртуальной машиной), для того чтобы представить уменьшенный список доступных функций. В другом варианте реализации гипервизор определяет, например, при помощи битовой маски, набор команд, сообщаемых гостю, а функция запроса многофункциональной команды сообщает этот список. Более того, в варианте реализации команда, выполняющаяся на логическом процессоре, будет подвергнута программному исключению, если она попытается выполнить выбранную выбираемую функцию.

Примером команды, имеющей выбираемые функции, является команда CIPHER MESSAGE (зашифровать сообщение) z/Architecture.

Команда CIPHER MESSAGE (KM) может выполнять любую из множества функций шифрования сообщений. Одной из функций, предоставляемых командой CIPHER MESSAGE, является запрос у процессора списка битовых обозначений функций шифрования сообщений, поддерживаемых процессором.

Формат команды CIPHER MESSAGE (Таблица 3) следующий, где R1 обозначает первый регистр общего назначения, a R2 обозначает второй регистр общего назначения.

Выполнение команды CIPHER MESSAGE (Таблица 3) следующее:

Выполняется функция, заданная кодом функции в неявном регистре общего назначения 0.

Биты 16-23 команды игнорируются.

Битовые разряды 57-63 регистра общего назначения 0 содержат код функции.

Текущие назначенные коды функций для CIPHER MESSAGE и CIPHER MESSAGE WITH CHAINING (зашифровать сообщение со сцеплением), соответственно (0-3 и 18-20), показаны в Таблице 4. Все другие коды функций не назначены. Для функций шифрования, бит 56 является битом модификации, который определяет, следует выполнить операцию зашифровки или расшифровки. Бит модификатора игнорируется для всех других функций. Все другие биты регистра общего назначения О игнорируются.

Неявный регистр общего назначения 1 содержит логический адрес самого левого байта блока параметров в памяти. В режиме 24-битной адресации содержимое битовых разрядов 40-63 регистра общего назначения 1 составляет адрес, а содержимое битовых разрядов 0-39 игнорируется. В режиме 31-битной адресации содержимое битовых разрядов 33-63 регистра общего назначения 1 составляет адрес, а содержимое битовых разрядов 0-32 игнорируется. В режиме 64-битной адресации содержимое битовых разрядов 0-63 регистра общего назначения 1 составляет адрес.

Функция запроса предоставляет средства обозначения доступности других функций. Содержимое регистров общего назначения, заданных полями команды (R1, R2), и R2+1 игнорируется для функции запроса.

Для всех других функций второй операнд (заданный R2) шифруется, как определено кодом функции, при помощи криптографического ключа в блоке параметров, а результат помещается в ячейку первого операнда.

Для CIPHER MESSAGE WITH CHAINING шифрование также использует начальное значение сцепления в блоке параметров, и значение сцепления обновляется как часть операции. Использование регистра для 24-битной адресации показано в Таблице 5.

Поле R1 определяет регистр общего назначения и должно определять регистр с четным номером; иначе обнаруживается исключение определения.

Поле R2 определяет четно-нечетную пару регистров общего назначения и должно определять регистр с четным номером; иначе обнаруживается исключение определения.

Положение самого левого байта первого и второго операндов определяется содержимым регистров общего назначения R1 и R2, соответственно. Число байт в ячейке второго операнда задается в регистре общего назначения R2+1. Первый операнд имеет такую же длину, как и второй операнд.

Как часть операции, адреса в регистрах общего назначения R1 и R2 увеличиваются на число байт, которые обрабатываются, а длина в регистре общего назначения R2+1 уменьшается на то же число. Создание и обновление адресов и длины зависит от режима адресации.

В режиме 24-битной адресации содержимое битовых разрядов 40-63 регистров общего назначения R1 и R2 составляет адреса первого и второго операндов соответственно, а содержимое битовых разрядов 0-39 игнорируется; биты 40-63 обновленных адресов замещают соответствующие биты в регистрах общего назначения R1 и R2, переносы из битового разряда 40 обновленных адресов игнорируются, а содержимое битовых разрядов 32-39 регистров общего назначения R1 и R2 устанавливается в нули. В режиме 31-битной адресации содержимое битовых разрядов 33-63 регистров общего назначения R1 и R2 составляет адреса первого и второго операндов соответственно, а содержимое битовых разрядов 0-32 игнорируется; биты 33-63 обновленных адресов замещают соответствующие биты в регистрах общего назначения R1 и R2, переносы из битового разряда 33 обновленных адресов игнорируются, а содержимое битового разряда 32 регистров общего назначения R1 и R2 устанавливается в нуль. В режиме 64-битной адресации содержимое битовых разрядов 0-63 регистров общего назначения R1 и R2 составляет адреса первого и второго операндов соответственно; биты 0-63 обновленных адресов замещают содержимое регистров общего назначения R1 и R2, а переносы из битового разряда 0 игнорируются.

В режимах как 24-битной, так и 31-битной адресации содержимое битовых разрядов 32-63 регистра общего назначения R2+1 образует 32-битное беззнаковое двоичное целое, которое определяет число байт в первом и втором операндах, а содержимое битовых разрядов 0-31 игнорируется; биты 32-63 обновленного значения замещают соответствующие биты в регистре общего назначения R2+1. В режиме 64-битной адресации содержимое битовых разрядов 0-63 регистра общего назначения R2+1 образует 64-битное беззнаковое двоичное целое, которое определяет число байт в первом и втором операндах; а обновленное значение замещает содержимое регистра общего назначения R2+1.

В режиме 24-битной или 31-битной адресации содержимое битовых разрядов 0-31 регистров общего назначения R1, R2 и R2+1 всегда остается неизменным. В Таблице 5 изображено содержимое только что описанных регистров общего назначения.

В режиме регистра доступа регистры доступа 1, R1 и R2 определяют адресные пространства, содержащие блок параметров, первый и второй операнды соответственно.

Результат получается, как если бы обработка начиналась с левого конца первого и второго операндов и продвигалась вправо блок за блоком. Операция заканчивается, когда число байт во втором операнде, как определено в регистре общего назначения R2+1, обработано и помещено в ячейку первого операнда (называется нормальным завершением), или когда определенное ЦПУ число блоков, которое меньше, чем длина второго операнда, обработано (называется частичным завершением). Определенное ЦПУ число блоков зависит от модели, и может быть различным числом каждый раз, когда команда выполняется. Определенное ЦПУ число блоков обычно не равно нулю. В некоторых необычных ситуациях это число может быть нулем, и может быть установлен код состояния 3 без какого-либо продвижения. Однако, ЦПУ защищает против бесконечного повтора этого случая без продвижения.

Результаты в ячейке первого операнда и поле значения сцепления непредсказуемы, если случается какая-либо из следующих ситуаций:

Поле криптографического ключа перекрывает какую-либо часть первого операнда.

Поле значения сцепления перекрывает какую-либо часть первого операнда или второго операнда.

Первый и второй операнды перекрываются деструктивно. Говорят, что операнды перекрываются деструктивно, когда ячейка первого операнда должна использоваться как источник после того, как в нее будут перемещены данные, подразумевая, что обработка осуществляется слева направо по одному байту за раз.

Если операция заканчивается из-за нормального завершения, устанавливается код состояния 0, а результирующее значение в R2+1 равно нулю. Если операция заканчивается из-за частичного завершения, устанавливается код состояния 3, а результирующее значение в R2+1 не равно нулю.

Если обнаруживается событие PER изменения памяти, меньше чем 4К дополнительных байт сохраняется в ячейки первого операнда перед тем, как о событии сообщается.

Если длина второго операнда изначально нуль, блок параметров, первый и второй операнды не затрагиваются, регистры общего назначения R1, R2 и R2+1 не изменяются, и устанавливается код состояния 0.

Если содержимое полей R1 и R2 одинаково, содержимое назначенных регистров изменяется только на число байт, которые обрабатываются, а не на двойное число байт, которые обрабатываются.

С точки зрения других ЦПУ и канальных программ, ссылки на блок параметров и операнды памяти могут быть ссылками множественного доступа, обращения к этим ячейкам памяти не обязательно блочно-параллельны, а последовательность этих обращений или ссылок не определена.

В некоторых необычных ситуациях выполнение команды может завершиться установкой кода состояния 3 без обновления регистров и значения сцепления, чтобы отобразить последний модуль первого и второго операндов, которые обрабатываются. Размер модуля, обработанного в этом случае, зависит от ситуации и модели, но ограничен так, чтобы часть первого и второго операндов, которая была обработана и не сообщена, не перекрывались в памяти. Во всех случаях, устанавливаются биты изменения, и события PER изменения памяти сообщаются, если применимо, для всех ячеек первого операнда, которые обрабатываются.

Исключения доступа могут сообщаться для большей части операнда, которая обрабатывается однократным выполнением команды; однако, исключения доступа не обнаруживаются ни для ячеек за пределами длины операнда, ни для ячеек, удаленных более чем на 4 кбайта от текущей ячейки, которая обрабатывается.

Коды функций для CIPHER MESSAGE являются следующими

Используя команду CIPHER MESSAGE как пример, примерная машина может реализовать функции CIPHER MESSAGE. В примерном варианте реализации основные процессоры могут реализовать все из показанных функций (код функции 0-3 и 18-20). Основная операционная система (OS) (или гипервизор) может создать одну или более виртуальных машин для гостевых OS. Одна виртуальная машина может быть определена для архитектуры предыдущего уровня, не имеющего команд CIPHER MESSAGE.

Согласно варианту реализации, если средство блокировки команд было установлено, а команды CIPHER MESSAGE были определены как блокированные команды для VM, виртуальная машина не будет разрешать выполнение команды CIPHER MESSAGE программами, запущенными в виртуальной машине, даже если бы нижележащая основная машина поддерживала команды CIPHER MESSAGE. Попытка выполнить команду CIPHER MESSAGE в VM приведет к программной проверке (программному исключению).

Согласно другому варианту реализации, если средство блокировки команд было установлено, и только подмножество функций CIPHER MESSAGE (коды функций 0-3, например) было разрешено в VM, виртуальная машина будет разрешать выполнение CIPHER MESSAGE, но не будет разрешать выполнение команды CIPHER MESSAGE команд CIPHER MESSAGE, имеющих код функции, отличный от 0-3, программами, запущенными в виртуальной машине, даже если бы нижележащая основная машина поддерживала команды CIPHER MESSAGE, поддерживающая коды функций (0-3 и 18-20). Попытка выполнить команду CIPHER MESSAGE, имеющую коды функций, отличные от 0-3, такие как любой из 18-20, приведет к программной проверке (программному исключению).

В еще одном варианте реализации, если средство проверки/запроса функций было установлено, и только подмножество функций CIPHER MESSAGE (коды функций 0-3, например) было разрешено в VM, выполнение запроса CIPHER MESSAGE функций CIPHER MESSAGE будет возвращать только коды функций 0-3, даже если бы нижележащая основная машина поддерживала коды функций 0-3 и 18-20.

Средство блокировки команд:

Согласно ФИГ.8, изображено функционирование средства блокировки команд виртуального уровня архитектуры (Virtual Architecture Level, VAL) в VM. Каждая команда, которая должна выполняться в VM (как показано в столбце Команды в памяти), включает код операции. В некоторых реализациях код операции является одним полем в команде 901 902 903 904. В других реализациях коды операций могут распределяться по более чем одному полю команды 905 (код операции||код операции) 906 (код операции||код операции). Предпочтительно, чтобы схемы, микрокод или их комбинация, определили, на основе кода операции, поддерживалась бы команда для выполнения текущей виртуальной машиной или нет. Если бы не поддерживалась, указывалось бы программное прерывание, например, программное исключение, а команда подавлялась.

В реализации код операции команды для выполнения использовался бы для индексирования в таблице кода операции 907 для нахождения элемента, связанного с кодом операции. Элемент, который найден, включал бы код, указывающий машинный уровень (ML), поддерживаемый кодом операции. В другой реализации каждая виртуальная машина имела бы таблицу кодов операций, а элемент в таблице указывал бы, поддерживался ли код виртуальной машиной.

Согласно ФИГ.9, код (машинный уровень (ML)) 1002, полученный из таблицы 907, сравнивался бы 1005 с элементом описания состояния (IBC) 1008 таблицы описания состояния 1004 виртуальной машины, а если бы код машинного уровня 1002 был больше, чем элемент описания состояния IBC 1008, команда выполнялась бы нормально 1007, иначе, попытка выполнения вела бы к программному исключению 1006. В еще одном варианте реализации поля команды, дополнительные или отличные от поля кода операции, могут использоваться для индексирования в таблице кодов операции 907. Например, код операции может иметь зарезервированные поля (равные 0 или игнорируемые) в предыдущей машинной архитектуре, которые применяются на новых архитектурных уровнях для обеспечения новой функции. Вариант реализации будет включать эти биты с кодом операции для индексирования в таблице кодов операций 907. В еще одном варианте реализации таблица кодов операций 907 может иметь поля дополнительно к полю ML, использующиеся для указания разрешенного использования зарезервированных бит в соответствующей команде. Например, если команда имеет 4 резервных бита, таблица ML может содержать 0000, если все биты должны быть 0, или 1 в выбранных битах, где 1 указывает, что соответствующие ранее зарезервированные биты поля могут быть 0 или 1 (разрешая нововведенную функцию команды для VM).

Средство проверки/запроса команд:

Если средство блокировки команд средства проверки/запроса команд установлено (ФИГ.10), элемент таблицы кодов операций 1001 может, в варианте реализации, дополнительно включать поле кода функции (FCx) 1003 (или указатель на таблицу кодов функций 1108). Поле кода функции 1003 (или элемент 1107 таблицы кодов функций 1108) сравнивается 1103 с кодом функции, которая должна быть выполнена, 1102. Если код функции соответствует, команде разрешается 1105 использовать код функции, если код функции не соответствует 1103, выполнение команды вызывает программное прерывание, такое как программное исключение или исключение определения (программная проверка) 1104.

Согласно ФИГ.11, если средство проверки/запроса функций средства проверки/запроса команд установлено, если выполняется любая команда запроса 1109 для определения установленной функции команды, только коды функций, разрешенных виртуальной машиной, возвращаются 1105. В варианте реализации предоставляется таблица битовых обозначений 1108 для виртуальной машины, которая используется виртуальной машиной, чтобы отвечать на такие запросы. В другом варианте реализации виртуальной машине предоставляется маска (не показана) для логического И с установленными кодами функций основной машины для создания результата разрешенных кодов функций 1107 команды в VM.

Согласно ФИГ. 8, изображены примерные форматы команд z/Architecture. Формат 901 иллюстрирует 2-байтный формат, в котором код операции (Op) занимает байт высшего порядка, а поля регистров общего назначения R1 и R2 занимают соответственные 4 бита оставшегося байта. Формат 902 иллюстрирует 2-байтный формат команды только с кодом операции. Формат 903 иллюстрирует 4-байтную команду (слово), имеющую 1-байтный код операции (Op), сопровождающийся 3 полями регистров (R1, X2 и B2), а затем непосредственным полем, называемым полем смещения (D2). Формат 904 иллюстрирует 4-байтную команду, имеющую 4-байтный код операции (Op), сопровождающийся 4-битным полем регистра (B2), а затем непосредственным полем, называемым полем смещения (D2). Формат 905 иллюстрирует 4-байтную команду, имеющую 1-байтный код операции (Op), сопровождающийся 4-битной маской M1, сопровождающейся 4-битным расширением кода операции (Op) и зарезервированным 4-битным полем, сопровождающимся 12-битным непосредственным полем (12). Формат 906 иллюстрирует 4-байтную команду, имеющую 1-байтный код операции (Op), сопровождающийся 3 полями регистров (R1, X2 и B2), а затем непосредственным полем, называемым полем смещения (DL2), сопровождающимся 8-битным непосредственным полем (DH2) и 8-битным расширением кода операции (Op).

Согласно ФИГ.8 и 9, в варианте реализации, когда команда считывается для выполнения логическим процессором, выполняющим виртуальную машину, ищется таблица кодов операций 907 с использованием кода(ов) операции(й) команды в качестве аргумента поиска. Если элемент найден 1001 для команды, элемент включает информацию 1002 1003 для определения информации о разрешенности команды. В предпочтительном варианте реализации элемент включает поле 1002, которое определяет код (ML), указывающий машине уровень архитектуры, поддерживающий команду. Описание состояния 1004 предоставляется для каждой VM. Описание состояния включает поле (IBC) 1008, которое представляет машинный уровень архитектуры, которую VM должна симулировать. Если 1005, машинный уровень архитектуры, поддерживающей команду (ML) выше, чем машинный уровень архитектуры, которую VM должна симулировать (IBC), сигнализируется программное исключение (программная проверка), и, в варианте реализации, выполнение команды может быть подавлено. С другой стороны, если машинный уровень архитектуры, поддерживающей команду (ML) не выше, чем машинный уровень архитектуры, которую VM должна симулировать (IBC), команде разрешается выполняться.

В некоторых средах предоставляются команды, которые способны выполнять любую из множества функций (такие как команда CIPHER MESSAGE, описанная выше). Выбор функции командой может производиться посредством задания кода функции (FC), представляющего функцию. Код функции может быть косвенно задан командой или явно задан битами или полями команды, к примеру. В некоторых случаях некоторые коды функций могут быть изначально реализованы (0-3, к примеру) на уровне машинной архитектуры, а дополнительный коды функций могут добавляться на более поздних уровнях машинной архитектуры. VM может предоставляться способность разрешать выполнять только коды функций более старого уровня архитектуры, и блокировать (предотвращать) выполнение функций более нового уровня архитектуры.

Согласно ФИГ.10, этого можно достичь, имея поле кода функции (FCx) 1003 в элементе таблицы кодов операций 1001. Когда команда близится к выполнению, поле FCx 1003 определяет список разрешенных кодов функций для возврата вместо действительных кодов функций, поддерживаемых основным процессором. В варианте реализации поле FCx 1003 элемента таблицы кодов операций соединяется с полем IBC 1008 для индексирования 1006 в таблице FCx 1108 для нахождения элемента, который содержит разрешенные коды функций (FC) 1107. Разрешенные FC 1107 сравниваются с FC, заданным командой 1102 (в команде Cipher Message, биты 1102 регистра общего назначения 0 1101 содержат заданный FC 1102). Если 1103 значение FC разрешено 1105, разрешается нормальное выполнение функции, представленной битами FC. Если 1103 значение FC не разрешено 1104, производится программное исключение, такое как событие исключения определения (программной проверки). Аналогично, при выполнении операции запроса/проверки функции 1109 (такой как операция запроса команды CIPHER MESSAGE), биты FCX элемента таблицы кодов операции 1003 соединяются 1106 с битами IBC 1008 для индексирования в таблице FCX 1108 для нахождения разрешенных FC 1107 для команды, код операции которой находится в элементе таблицы кодов операции 1001. Затем разрешенные FC возвращаются 1105 в место, заданное операцией запроса/проверки функции.

В варианте реализации, если биты FCX равны 0, не производится никакого обращения к таблице FCx 1108, а любой код функции, указанный соответствующей командой, используется без трансляции.

В варианте реализации, другие архитектурные модификации команд могут использовать тот же механизм, что и описанный для кодов функций. В этом случае, например, команда 905 на архитектурном уровне имеет зарезервированные (0000) биты между полем расширения кода операции и полем 12. Предпочтительно зарезервированные биты проверяются на равенство 0, чтобы убедиться, что команда будет выполняться должным образом в среде, в которой ненулевые биты поддерживают еще неподдерживаемую функцию. Более новая архитектура внедряет новую функцию, использующую один или более зарезервированных бит для идентификации новой функции. К примеру, эти 4 зарезервированных бита (Res) могут индексировать в таблице FCx 1108 для того, чтобы определить, поддерживаются ли они, как показано для бит FC 1103 на ФИГ.10. В этом случае, соединение было бы 0||IBC||FCx для кодов функций, и 1||IBC||FCx для проверки разрешенности новой функции 1103. Вместо сравнения FC 1102 с разрешенными FC 1107, поле Res команды 905 сопоставлялось бы с разрешенными битами FCS 1107 для определения 1103, разрешена ли функция.

В другом варианте реализации поле Res команды 905 могло бы соединяться как если бы это было третьим расширением кода операции кодов операций 905 для индексирования в таблице кодов операций 907, чтобы определить, разрешена ли функция, вводящаяся полем.

Как часть, или вслед за, считыванием команды ЦПУ может определить некоторые атрибуты команды, например, число операндов, тип операндов (память или регистр), требования к выравниванию операндов и требования авторизации. В эмуляционной среде это определение может быть результатом простого табличного поиска с использованием кода операции как индекса; в высокопроизводительной реализации аппаратного обеспечения ЦПУ определение может быть встроено в схему декодирования команд процессора. Таким образом, когда команда декодируется, машинный уровень для этой команды может сравниваться с программируемым значением, указывающим машинный уровень, который разрешен. Команда, которая декодируется, имеющая высший машинный уровень, чем разрешенное значение, будет блокирована от передачи, выполнения либо завершения в зависимости от реализации, и может генерироваться машинно-зависимое исключение для неразрешенного кода операции.

Средство виртуального архитектурного уровня может вводить дополнительный атрибут, связанный с каждой командой: машинный уровень, на котором команда была впервые введена в архитектуру. Машинный уровень может быть кодирован числовой точкой на континууме (например, 10.2, что означает машину 10 поколения на втором уровне микропрограммы), или может просто быть значением относительно самого последнего машинного уровня (например, 2 [или -2], что означает, что команда была введена за два машинных поколения до текущей машины).

Согласно ФИГ.12, в варианте реализации определенные команды 1258 блокируются от выполнения процессором. Установлено значение блокировки команды 1251. Команда считывается 1252 для выполнения процессором, команда содержит код операции, команда поддерживается процессором. Когда команда должна выполняться, производится сравнение значения блокировки команд с командой (или кодом операции команды), чтобы определить, разрешено ли выполнение. В зависимости 1254 от значения блокировки команды, разрешающего выполнение команды, выполнение 1255 считанной команды процессором; и в зависимости 1254 от значения блокировки команды, не разрешающего выполнение 1256 команды, блокировка выполнения считанной команды и вызов события программного исключения.

Согласно ФИГ.13, в варианте реализации процессор является логическим процессором, выполняющим виртуальную машину, в которой считывание осуществляется логическим процессором. Выполняется определение 1254 значения блокировки команд виртуальной машины, в котором значение блокировки команд устанавливается в логическом процессоре, имеющем один или более физических процессоров, в котором команда поддерживается одним или более физических процессоров, в котором в зависимости от значения блокировки команды, разрешающего выполнение команды, выполнение осуществляется 1352 логическим процессором. Если команда блокируется 1256, сообщается событие программного исключения.

Согласно ФИГ.14, в варианте реализации процессор является одним или более физическими процессорами логического процессора, выполняющего виртуальную машину, в которой значение блокировки команд установлено 1451 в одном или более физических процессоров, в которой считывание осуществляется одним или более физических процессоров. Физический процессор сравнивает 1452 значение блокировки команд с командой для выполнения, чтобы определить, должна ли команда быть блокирована, и физический процессор либо выполняет команду 1454, либо вызывает событие программного исключения 1455.

Согласно ФИГ.15, в варианте реализации значение блокировки команд определено для виртуальной машины для блокировки выполнения команды, установка 1551 значения блокировки команд в зависимости от включения виртуальной машины для использования физического процессора 1553; другое значение блокировки команд установлено 1552, другое значение блокировки команд определено для другой виртуальной машины, имеющей другой логический процессор, установка другого значения блокировки команд в зависимости от включения другой виртуальной машины для использования физического процессора 1553; и в зависимости от другого значения блокировки команд, разрешающего 1254 выполнение команды, разрешение выполнения 1255 команды другим логическим процессором; и в зависимости от другого значения блокировки команд, не разрешающего 1254 выполнение команды, не разрешение выполнения 1256 команды другим логическим процессором.

В варианте реализации значение блокировки команд определено для виртуальной машины для блокировки выполнения команды, установка значения блокировки команд в зависимости от включения виртуальной машины для использования физического процессора, другое значение блокировки команд установлено, другое значение блокировки команд определено для другой виртуальной машины, имеющей другой логический процессор, установка другого значения блокировки команд в зависимости от включения другой виртуальной машины для использования физического процессора; и в зависимости от другого значения блокировки команд, разрешающего выполнение команды, разрешение выполнения команды физическим процессором, пока другая виртуальная машина включена для использования физического процессора; и в зависимости от другого значения блокировки команд, не разрешающего выполнение команды, не разрешение выполнения команды физическим процессором, пока другая виртуальная машина включена для использования физического процессора.

Согласно ФИГ.12, в варианте реализации команда 1258 является разрешенной командой, если команда 1258 применяет разрешенный код функции, связанный с выбранной функцией 1259 множества выбираемых функций, тогда как команда является неразрешенной командой, если команда применяет неразрешенный код функции, где коды функций задаются командой.

В варианте реализации выполняется определение, является ли команда разрешенной командой, посредством сопоставления кода операции команды со значением блокировки команд.

Вышеизложенное может быть полезно для понимания терминологии и структуры одного варианта реализации компьютерной системы. Варианты реализации не могут ограничиваться архитектурой z/Architecture или приведенным ее описанием. Варианты реализации могут с успехом применяться к другим компьютерным архитектурам других производителей компьютеров с изложенным здесь.