Трансформация прерывистых спецификаторов команд в непрерывные спецификаторы команд

Трансформация прерывистых спецификаторов команд в непрерывные спецификаторы команд

Иллюстрации

Показать все

Реферат

Предпосылки создания изобретения

[001] Аспект изобретения относится, в общем, к эмуляции внутри вычислительной среды и, в частности, к эмуляции спецификаторов внутри команд.

[002] Эмуляция имитирует функции на архитектуре компьютера, называемой целевой архитектурой. Целевая архитектура отличается от архитектуры компьютера, называемой исходной архитектурой, для которой функции были определены. Например, команда, написанная для z/Architecture, предоставленной корпорацией International Business Machines, Армонк, штат Нью-Йорк, может быть транслирована и представлена в виде одной или более команд на другой архитектуре, такой как PowerPC, также предложенной корпорацией International Business Machines, или другой архитектуре, предложенной корпорацией International Business Machines или другой компанией. Эти транслированные команды выполняют ту же или подобную функцию, что и команда, которая транслируется.

[003] Существуют различные типы эмуляции, включая интерпретацию и трансляцию. При интерпретации считываются данные, представляющие команду, и как только каждая команда декодируется, она выполняется. Каждая команда выполняется каждый раз, когда на нее ссылаются. Однако, при трансляции, называемой также двоичной трансляцией или рекомпиляцией, последовательности команд транслируются из набора команд одной архитектуры компьютера в набор команд другой архитектуры компьютера.

[004] Существуют различные типы трансляции, включая статическую трансляцию и динамическую трансляцию. При статической трансляции код команды одной архитектуры конвертируется в код, который запускается на другой архитектуре без предварительного выполнения кода. Напротив, при динамической трансляции по меньшей мере часть кода выполняется и транслируется, а результат помещается в кэш для последующего выполнения процессором целевой архитектуры компьютера.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

[005] Для устранения недостатков уровня техники предложен реализованный в машиночитаемом носителе данных способ трансформирования спецификаторов команд вычислительной среды, включающий получение из первой команды, определенной для первой архитектуры компьютера, прерывистого спецификатора, имеющего первую часть и вторую часть, причем первую часть получают из первого поля первой команды, а вторую часть получают из второго поля первой команды, отделенного от первого поля; создание непрерывного спецификатора с использованием первой части и второй части, полученных из первой команды, причем для создания непрерывного спецификатора используют одно или более правил, основанных на коде операции первой команды; использование непрерывного спецификатора, как если бы в первой команде вместо прерывистого спецификатора был задан прерывистый спецификатор, для указания ресурса для использования при выполнении второй команды, причем вторая команда определена для второй архитектуры компьютера, отличной от первой архитектуры компьютера, и эмулирует функцию первой команды; и выполнение второй команды для эмуляции функции первой команды с использованием ресурса, указываемого непрерывным спецификатором, созданным с использованием первойчасти и второй части, полученных из первой команды, причем непрерывный спецификатор используют как если бы прерывистый спецификатор не задавался.

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

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

[007] Объектом изобретения является также собственно способ трансформирования спецификаторов команд вычислительной среды, описанный выше.

КРАТКОЕ ОПИСАНИЕ И НЕСКОЛЬКО ПРЕДСТАВЛЕНИЙ ЧЕРТЕЖЕЙ

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

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

На ФИГ. 2 изображены дальнейшие подробности памяти согласно ФИГ. 1 в соответствии с аспектом данного изобретения.

На ФИГ. 3 изображен один из вариантов воплощения общего вида процесса эмуляции, который задействует одну или более интерпретаций и трансляций.

На ФИГ. 4 изображен один из примеров логики, связанной с блоком интерпретации, указанным на ФИГ. 3.

На ФИГ. 5 изображен один из примеров логики, связанной с блоком трансляции, указанным на ФИГ. 3.

На ФИГ. 6 изображен другой вариант воплощения общего вида процесса эмуляции, который задействует одну или более интерпретаций и трансляций, модифицированных в соответствии с аспектом данного изобретения.

На ФИГ.7А изображен один из примеров логики, связанной с блоком интерпретации, указанным на ФИГ.6, в соответствии с аспектом данного изобретения.

На ФИГ.7Б изображен один из вариантов логики для трансформации прерывистого спецификатора в непрерывный спецификатор в соответствии с аспектом данного изобретения.

На ФИГ.8 изображен один из примеров логики, связанной с блоком трансляции, указанным на ФИГ.6, в соответствии с аспектом данного изобретения.

На ФИГ.9А изображен один из вариантов трансформации прерывистого спецификатора команды Vector Load (загрузить вектор) одной архитектуры компьютера в непрерывный спецификатор в команде Load Vector Indexed (загрузить вектор с нумерацией) другой архитектуры компьютера в соответствии с аспектом данного изобретения.

На ФИГ.9Б изображен другой пример трансформации согласно ФИГ.9А, включающий выделение отдельного регистра непрерывному спецификатору в соответствии с аспектом данного изобретения.

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

На ФИГ.11 изображен пример трансформации прерывистого спецификатора в непрерывный спецификатор с размещением в памяти при эмуляции в соответствии с аспектом данного изобретения.

На ФИГ.12 изображена одна из реализации компьютерного программного продукта, включающего один или более аспектов данного изобретения.

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

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

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

На ФИГ.16 изображена одна из реализации различных элементов компьютерной системы, включающей и использующей один или более аспектов данного изобретения.

На ФИГ.17А изображена одна из реализации исполнительного устройства компьютерной системы согласно ФИГ.16, включающего и использующего один или более аспектов данного изобретении.

На ФИГ.17Б изображена одна из реализации устройства ветвления компьютерной системы согласно ФИГ.16, включающего и использующего один или более аспектов данного изобретения.

На ФИГ.17В изображена одна из реализации устройства загрузки/сохранения компьютерной системы согласно ФИГ.16, включающего и использующего один или более аспектов данного изобретения.

На ФИГ.18 изображена одна из реализации эмулируемой хост-компьютерной системы, включающей и использующей один или более аспектов данного изобретения.

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

[009] В соответствии с аспектом данного изобретения предоставляется методика для облегчения эмуляции команд, которые включают прерывистые спецификаторы. Прерывистый спецификатор задает ресурс команды, такой как регистр, используя несколько полей команды. К примеру, несколько полей команды (напр., два поля) содержат биты, которые вместе обозначают конкретный регистр, который будет использоваться командой.

[0010] В отдельном аспекте изобретения предоставляется методика для трансформации прерывистых спецификаторов команд, определенных для одной архитектуры компьютерной системы (напр., z/Architecture, предложенной корпорацией International Business Machines), в непрерывные спецификаторы, используемые командами, определенными для другой архитектуры компьютерной системы (напр., архитектуры PowerPC, предложенной корпорацией International Business Machines). Команды, определенные для другой архитектуры компьютерной системы, эмулируют команды, определенные для одной архитектуры компьютерной системы.

[0011] Одна из реализации вычислительной среды, обеспечивающей эмуляцию, описана при помощи ФИГ.1. В одном из примеров вычислительная среда 100 включает, например, собственное центральное процессорное устройство 102, память 104 и одно или более устройств ввода-вывода и/или интерфейсов 106, соединенных между собой посредством, например, одной или более шин 108 и/или других соединений. Как примеры, вычислительная среда 100 может включать процессор PowerPC, сервер pSeries или сервер xSeries, предлагаемые корпорацией International Business Machines, Армонк, штат Нью-Йорк; HP Superdome с процессорами Intel Itanium II, предлагаемый компанией Hewlett Packard Co., Пало-Альто, штат Калифорния; и/или другие машины на основе архитектур, предлагаемых корпорациями International Business Machines, Hewlett Packard, Intel, Oracle или другими.

[0012] Собственное центральное процессорное устройство 102 содержит один или более собственных регистров 110, таких как один или более регистров общего назначения и/или один или более регистров специального назначения, использующихся при обработке внутри среды. Эти регистры содержат сведения, которые представляют состояние среды в любой отдельный момент времени.

[0013] Кроме того, собственное центральное процессорное устройство 102 выполняет команды и код, хранящиеся в памяти 104. В отдельном примере центральное процессорное устройство выполняет код эмулятора 112, хранящийся в памяти 104. Этот код задействует вычислительную среду, настроенную на одной архитектуре для эмуляции другой архитектуры. Например, код эмулятора 112 позволяет машинам, основанным на архитектурах, отличных от z/Architecture, таких так процессоры PowerPC, серверы pSeries, серверы xSeries, серверы HP Superdome или другие, эмулировать z/Architecture и выполнять программное обеспечение и команды, разработанные на основе z/Architecture.

[0014] Дальнейшие подробности касательно кода эмулятора 112 описаны при помощи ФИГ.2. Гостевые команды 200 включают программные команды (напр., машинные команды), которые были разработаны для выполнения в архитектуре иной, нежели таковая собственного ЦПУ 102. Например, гостевые команды 200 могли быть разработаны для выполнения на процессоре z/Architecture, но вместо этого эмулируются на собственном ЦПУ 102, которое может быть, например, процессором PowerPC или процессором другого типа. В одном из примеров код эмулятора 112 включает модуль считывания команд 202 для получения одной или более гостевых команд 200 из памяти 104 и опционального обеспечения локальной буферизации полученных команд. Он включает также программу трансляции команд 204 для определения типа гостевой команды, которая была получена, и для трансляции гостевой команды в одну или более соответствующих собственных команд 206. Эта трансляция включает, например, идентификацию функции для выполнения гостевой командой (напр., через код операции) и выбор собственной команды (команд), выполняющих эту функцию.

[0015] Далее, эмулятор 112 включает программу управления эмуляцией 210, заставляющую собственные команды выполняться. Программа управления эмуляцией 210 может заставить собственное ЦПУ 102 выполнить программу собственных команд, которые эмулируют одну или более ранее полученных гостевых команд, и по завершению этого выполнения вернуть управление программе считывания команд для эмуляции получения следующей гостевой команды или группы гостевых команд. Выполнение собственных команд 206 может включать загрузку данных в регистр из памяти 104; запись данных обратно в память из регистра; или выполнение некоторого типа арифметической или логической операции, как определено программой трансляции.

[0016] Каждая программа, например, реализована в программном обеспечении, которое хранится в памяти и выполняется собственным центральным процессорным устройством 102. В других примерах одна или более программ или операций могут быть реализованы в микропрограммном, аппаратном, программном обеспечении или в некоторой их комбинации. Регистры эмулируемого процессора могут быть эмулироваться с помощью регистров 110 собственного ЦПУ или с помощью ячеек в памяти 104. В вариантах реализации гостевые команды 200, собственные команды 206 и код эмулятора 112 могут находиться в одной памяти или могут быть рассредоточены по различным запоминающим устройствам.

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

[0018] В одном примере гостевая команда 200, которая считывается, транслируется и выполняется, является одной или более из команд, описываемых здесь. Команда одной архитектуры (напр., для z/Architecture) считывается из памяти, транслируется и представляется в виде последовательности собственных команд 206 другой архитектуры (напр., PowerPC, pSeries, xSeries, Intel и т.п.). Затем эти собственные команды выполняются.

[0019] Дальнейшие подробности касательно эмуляции описаны при помощи ФИГ.3-5. В частности, на ФИГ.3 изображен один из вариантов общего вида процесса эмуляции, который задействует одну или более интерпретаций и трансляций; на ФИГ.4 изображена одна из реализации логики, связанной с интерпретацией, обозначенной на ФИГ.3 (Методика 2000); а на ФИГ.5 изображена одна из реализации логики, связанной с двоичной трансляцией, обозначенной на ФИГ.3 (Методика 3000). В этом частном примере команды, написанные для z/Architecture, транслируются в команды PowerPC. Тем не менее, те же методики применимы для эмуляции z/Architecture на других целевых архитектурах; других исходных архитектур на архитектуре PowerPC; и/или другой исходной архитектуры на других целевых архитектурах.

[0020] Согласно ФИГ.3, при эмуляции команда, обозначаемая как команда X, считывается и интерпретируется как описано более подробно с помощью ФИГ.4, ШАГ 300. Обновляются различные статистические данные, касающиеся интерпретируемой команды, ШАГ 302, а затем обработка переходит к следующей команде, которая становится командой Х в логике, ШАГ 304. Выполняется определение того, имеет ли эта следующая команда ранее транслированную точку входа, ЗАПРОС 306. Если нет, далее выполняется определение, появлялась ли эта следующая команда N (напр., 15) раз, ЗАПРОС 308. То есть появлялась ли эта команда достаточно часто для того чтобы оптимизировать ее выполнение при помощи, например, осуществления динамической компиляции (ЛТ) кода, которое предоставляет точку входа для последующего использования. Если эта команда не появлялась N раз, например 15 раз, то обработка продолжается с ШАГА 300. Иначе обработка продолжается с создания группы команд и трансляции группы команд с одной архитектуры на другую архитектуру, ШАГ 310. Один из вариантов осуществления этой трансляции описан при помощи ФИГ.5. Вслед за созданием и трансляцией группы, группа выполняется, ШАГ 312, и обработка продолжается с ШАГА 304.

[0021] Возвращаясь к ЗАПРОСУ 306, если есть существующая транслированная точка входа для команды, обработка продолжается с выполнения группы в точке входа, ШАГ 312.

[0022] Дальнейшие подробности касательно интерпретации команды (Методика 2000) описаны при помощи ФИГ.4. Сначала считывается команда при следующем адресе программного счетчика (PC), ШАГ 400. Эта команда анализируется, и извлекаются поля кода операции, регистра и непосредственное, ШАГ 402. Затем осуществляется ветвление к коду, который эмулирует поведение, соответствующее извлеченному коду операции, ШАГ 404. Затем эмулируемый код выполняется, ШАГ 406.

[0023] Дальнейшие подробности касательно трансляции команд внутри группы (Методика 3000) описаны при помощи ФИГ.5. Сначала считывается команда в предопределенной группе команд, ШАГ 500. В одном из примеров группа может создаваться с помощью множества способов. В соответствии с одним вариантом реализации, создается группа, охватывающая единый путь выполнения вдоль наиболее вероятного пути. В другом варианте реализации создается группа, охватывающая один из последних предшествующих путей выполнения или текущий путь выполнения, на основе состояния эмулируемой архитектуры. В ином варианте реализации все ветви считаются не выбранными. В еще одном варианте реализации множественные пути включаются в группу, например, все пути, начинающиеся с начальной точки группы. В другом варианте реализации все команды вплоть до и включая первую ветвь, добавляются в группу (т.е. группа соответствует прямолинейному участку кода, общеизвестному также как “базовый элемент”). В каждом из вариантов реализации следует принять решение, где и когда закончить группу. В одном варианте группа заканчивается после фиксированного числа команд. В другом варианте группа заканчивается после снижения накопленной вероятности достижения команды ниже заданного порога. В некоторых вариантах группа останавливается немедленно после достижения условия остановки. В другом ряду вариантов реализации группа останавливается только в четко определенной “точке остановки”, напр., при определенной команде, в сочетании, характерном для начала группы, или в других условиях.

[0024] Потом команда анализируется, и поля кода операции, регистра и непосредственное извлекаются из команды, ШАГ 502. Далее, обеспечивается внутреннее представление извлеченных сведений, ШАГ 504. Это внутренне представление представляет собой формат извлеченных сведений, который используется процессором (напр., компилятором или транслятором) для оптимизации декодирования, выделения регистров и/или других задач, связанных с трансляцией команды.

[0025] Далее, выполняется определение, есть ли другая команда в группе, предназначенной для трансляции, ЗАПРОС 506. Если так, то обработка продолжается с ШАГА 500. Иначе обработка продолжается с оптимизации внутреннего представления, ШАГ 508, выделения одного или более регистров для группы команд, ШАГ 510, и создания кода, который эмулирует команды в группе, ШАГ 512.[0026] В то время как вышеизложенные процедуры интерпретации и трансляции обеспечивают эмуляцию команды, определенной для одной архитектуры, одной или более команд, определенных для другой архитектуры, можно усовершенствовать эмуляцию команд, которые используют прерывистые спецификаторы. Например, в соответствии с аспектом данного изобретения, предоставляются улучшения в методиках эмуляции для обработки ситуации, в которой регистровый операнд команды задан несколькими полями команды.

[0027] Одним из типов команд, использующих прерывистые спецификаторы, являются векторные команды, которые являются частью векторного средства, предоставляемого в соответствии с аспектом данного изобретения. Во многих векторных командах поле регистра содержит не все биты, необходимые для определения регистра для использования командой, а вместо этого для определения регистра, кроме поля регистра, используется другое поле. Это другое поле называется здесь полем RXB, также называемое битом расширения регистра (register extension bit).

[0028] Поле RXB представляет собой, например, четырехбитное поле (биты 0-3), которое содержит самые старшие биты для каждого из заданных векторным регистром операндов векторной команды. Биты для обозначений регистров, не заданных командой, должны быть зарезервированы и установлены в нуль.

[0029] В одном из примеров биты RXB определены следующим образом:

[0030] 0 - самый старший бит для обозначения первого векторного регистра в команде.

[0031] 1 - самый старший бит для обозначения второго векторного регистра в команде, если таковой имеется.

[0032] 2 - самый старший бит для обозначения третьего векторного регистра в команде, если таковой имеется.

[0033] 3 - самый старший бит для обозначения четвертого векторного регистра в команде, если таковой имеется.

[0034] Каждый бит устанавливается в нуль или единицу, например, ассемблером в зависимости от количества регистров. Например, для регистров 0-15 бит устанавливается в 0; для регистров 16-31 бит устанавливается в 1 и т.п.

[0035] В одном из вариантов реализации каждый бит RXB является битом расширения для отдельной ячейки в команде, которая включает один или более векторных регистров. Например, в одной или более векторных команд бит 0 поля RXB является битом расширения для ячейки 8-11, которая закреплена за, напр., V₁; бит 1 поля RXB является битом расширения для ячейки 12-15, которая закреплена за, напр., V₂ и так далее.

[0036] В другом варианте реализации поле RXB содержит дополнительные биты, и в качестве расширения для каждого вектора или ячейки используется более чем один бит.

[0037] В соответствии с аспектом данного изобретения предоставляются методики для трансформации прерывистых спецификаторов операндов в непрерывные спецификаторы. Будучи единожды трансформированы, непрерывные спецификаторы используются безотносительно к прерывистым спецификаторам.

[0038] Один из вариантов логики для эмуляции команд, использующих прерывистые спецификаторы, описан при помощи ФИГ.6-8. В частности, на ФИГ.6 изображен общий вид процесса эмуляции, включающего одну или более интерпретаций и трансляций команд, содержащих прерывистые спецификаторы; на ФИГ.7А изображена одна из реализации интерпретации (Методика 6000), включающая интерпретацию прерывистых спецификаторов; на ФИГ.7Б изображена одна из реализации трансформации прерывистого спецификатора в непрерывный спецификатор; а на ФИГ.8 изображена одна из реализации трансляции (Методика 7000), включающая трансляцию прерывистых спецификаторов.

[0039] Сначала, согласно ФИГ.6 предоставляется общий вид процесса эмуляции. Этот общий вид похож на общий вид, представленный на ФИГ.3, за исключением того, что ШАГ 600 использует Методику 6000, описанную при помощи ФИГ.7А, вместо Методики 2000, указанной в ШАГЕ 300; а ШАГ 610 использует Методику 7000, описанную при помощи ФИГ.8, вместо Методики 3000, указанной в ШАГЕ 310. Поскольку общий вид описан выше при помощи ФИГ.3, он не повторяется здесь; вместо этого обсуждение переходит к логике ФИГ.7А.

[0040] Согласно ФИГ.7А ШАГИ 700, 702, 704 и 706 подобны ШАГАМ 400, 402, 404 и 406 соответственно, из ФИГ.4, и поэтому не описываются снова; тем не менее, ШАГИ 703 и 705 описываются. В ШАГЕ 703, в соответствии с аспектом данного изобретения, непрерывный спецификатор (называемый здесь также непрерывным индексом) создается из прерывистого спецификатора. Дальнейшие подробности касательно создания непрерывного спецификатора из прерывистого спецификатора описываются при помощи ФИГ.7Б.

[0041] Согласно ФИГ.7Б в одном из вариантов воплощения сначала считывается прерывистый спецификатор, ШАГ 750. Это включает, например, определение из кода операции, что команда имеет прерывистый спецификатор, и определение, какие поля команды используются для указания прерывистого спецификатора. Например, часть кода операции задает формат команды, а этот формат указывает процессору, что команда имеет по меньшей мере один прерывистый спецификатор, и далее определяет поля, используемые для указания прерывистого спецификатора. Затем эти поля считываются для получения данных (напр., бит) в этих полях. Например, во многих векторных командах ячейка 8-11 команды (напр., V₁) задает множество бит (напр., 4), используемых для определения векторного регистра, а поле RXB команды содержит один или более дополнительных бит, используемых для определения отдельного векторного регистра. Эти биты получаются на этом этапе.

[0042] Вслед за получением прерывистого спецификатора (напр., биты из поля регистра V₁ и бит(ы) из RXB) используется одно или более правил для соединения частей прерывистого спецификатора, чтобы создать непрерывный спецификатор, ШАГ 752. Одно или более правил зависит, например, от формата команды, как определено кодом операции команды. В частном примере, в котором код операции обозначает поле RXB, одно или более правил включают использование бит(а) RXB, связанных с регистровым операндом, в качестве самого старшего бит(а) для бит, заданных в поле регистра. Например, поле RXB имеет в одном варианте реализации 4 бита и каждый бит соответствует регистровому операнду. Например, бит 0 соответствует первому регистровому операнду, бит 1 соответствует второму регистровому операнду и так далее. Так, бит, соответствующий регистровому операнду, извлекается и используется для создания непрерывного спецификатора. Например, если в поле регистра первого операнда задано двоичное 0010, а в поле RXB задано двоичное 1000, значение бита, связанного с первым операндом, бита 0, в данном примере, составляется в 0010. Таким образом, непрерывный спецификатор равен 10010 (регистр 18) в данном примере.

[0043] Затем созданный непрерывный спецификатор используется, как если бы это был спецификатор, предусмотренный в команде, ШАГ 754.

[0044] После этого, возвращаясь к ФИГ.7А, выполняется ветвление к коду, который эмулирует поведение, соответствующее коду операции, ШАГ 704. Далее, непрерывный индекс используется для управления усредненным архитектурным ресурсом безотносительно к прерывистому спецификатору, ШАГ 705. То есть непрерывный регистровый спецификатор используется как если бы прерывистого спецификатора не было. Каждый непрерывный спецификатор обозначает регистр для использования кодом эмуляции. После этого эмулируемый код выполняется, ШАГ 706.

[0045] Дальнейшие подробности касательно трансляции, включая трансформацию прерывистых спецификаторов в непрерывные спецификаторы (обозначенную как Методика 7000), описаны при помощи ФИГ.8. В одном из вариантов реализации, ШАГИ 800, 802, 804, 806, 808, 810 и 812 подобны ШАГАМ 500, 502, 504, 506, 508, 510 и 512 соответственно, из ФИГ.5, и поэтому не описываются здесь при помощи ФИГ.8. Однако в соответствии с аспектом данного изобретения предпринимаются дальнейшие шаги для трансформации прерывистого спецификатора команды исходной архитектуры в непрерывный спецификатор команды целевой архитектуры. Команда целевой архитектуры эмулирует функцию команды исходной архитектуры.

[0046] Например, в ШАГЕ 803 непрерывный спецификатор создается из прерывистого спецификатора. Как описано выше при помощи ФИГ.7Б, это включает получение прерывистого спецификатора из команды, которая эмулируется, и использование одного или более правил для создания непрерывного спецификатора из прерывистого спецификатора. В одном из вариантов реализации код операции команды, которая имеет прерывистый спецификатор, указывает, по меньшей мере, неявно по своему формату, что команда содержит прерывистый спецификатор. Например, формат команды указывается посредством одного или более бит в коде операции (напр., первых двух бит), и на основе формата процессор (напр., компилятор, транслятор, эмулятор процессора) понимает, что эта команда содержит прерывистый спецификатор, в котором часть спецификатора ресурса, такого как регистр, содержится в одном поле команды, а одна или более других частей спецификатора расположены в одном или более других полей команды.

[0047] Код операции, к примеру, предоставляет также указание процессору одного или более правил, использующихся для создания непрерывного спецификатора из прерывистого спецификатора. Например, код операции может указывать, что данная команда является векторной регистровой командой, и поэтому содержит поле RXB. Таким образом, процессор получает сведения (напр., правила, хранящиеся в памяти или внешнем запоминающем устройстве), которые указывают на команду с полем RXB, a поле RXB предоставляет самый старший бит для соответствующего ему поля регистра. Правила определяют, например, что для создания непрерывного поля биты поля регистра комбинируются с одним или более бит поля RXB, связанных с данным регистровым операндом.

[0048] Вслед за созданием непрерывного спецификатора, непрерывный спецификатор используется безотносительно к прерывистому спецификатору. Например, в ШАГЕ 808 код оптимизируется при помощи непрерывного спецификатора безотносительно к прерывистому спецификатору. Аналогично, один или более регистров назначаются при помощи непрерывного спецификатора и безотносительно к прерывистому спецификатору, ШАГ 810. Более того, в ШАГЕ 812 эмулируемый код создается безотносительно к прерывистому спецификатору и использует назначение, произведенное в ШАГЕ 810. То есть, на этих этапах нет никаких указаний, что непрерывный спецификатор был создан из непрерывного спецификатора. Прерывистый спецификатор игнорируется.

[0049] Дальнейшие подробности касательно трансляции прерывистого спецификатора в непрерывный спецификатор описываются при помощи примеров согласно ФИГ.9А, 9Б и 11. Сначала согласно ФИГ.9А изображена команда Загрузка Вектора (Vector Load) (VL) 900. В одном примере команда Vector Load содержит поля кода операции 902а (напр., биты 0-7), 902b (напр., биты 40-47), обозначающие операцию загрузки вектора; поле векторного регистра 904 (напр., биты 8-11), использующееся для задания векторного регистра (V₁); индексное поле (Х₂) 906 (напр., биты 12-15); базовое поле (В₂) 908 (напр., биты 16-19); поле смещения (D₂) 910 (напр., биты 20-31); и поле RXB 912 (напр., биты 36-39). Каждое из полей 904-912 в одном примере отделено и независимо от поля (полей) кода операции. Далее, в одном варианте реализации они отделены и независимы друг от друга; однако в других вариантах более чем одно поле могут комбинироваться. Дальнейшие сведения об использовании этих полей описываются ниже.

[0050] В одном из примеров выбранные биты (напр., первые два биты кода операции, заданные полем кода операции 902а) определяют длину и формат команды. В этом частном примере длина равна трем полусловам, а формат является векторной регистрово-индексной операцией сохранения с расширенным полем кода операции. Векторное (V₁) поле вместе с соответствующим ему битом расширения, заданным RXB, определяет векторный регистр (т.е. прерывистый спецификатор). В частности, для векторных регистров регистр, содержащий операнд, определяется при помощи, например, четырехбитного поля регистрового поля с прибавлением его бита расширения регистра (RXB) в качестве самого старшего бита. Например, если четырехбитное поле в V₁ равно двоичному 0010, а бит расширения для этого операнда равен двоичному 1, то 5-битное поле равно двоичному 10010, обозначая регистр номер 18 (десятичный).

[0051] Нижний индекс, связанный с полем команды, обозначает операнд, к которому применяется поле. Например, нижний индекс 1, связанный с V₁, обозначает первый операнд и так далее. Это используется для определения, который бит поля RXB комбинируется с регистровым полем. Регистровый операнд равен одному регистру по длине, которая составляет, например, 128 байт. В одном примере, в команде операции векторного регистро-индексного сохранения, содержимое регистров общего назначения, определенное полями X₂ и В₂, прибавляется к содержимому поля D₂ для получения адреса второго операнда. Смещение D₂ для команды Vector Load рассматривается как 12-битное целое без знака, в одном примере.

[0052] В этом примере, поскольку V₁ является первым операндом, крайняя левая ячейка (напр., бит 0) поля RXB связана с этим операндом. Таким образом, значение, расположенное в крайней левой ячейке, комбинируется со значением в поле регистра V₁ для создания непрерывного спецификатора, как описано в этой заявке.

[0053] В соответствии с аспектом данного изобретения команда Vector Load 900, которая определена, например, для z/Architecture, эмулируется в команду Load Vector Indexed 950, определенную, например, для архитектуры PowerPC. Хотя в этом примере z/Architecture является исходной архитектурой, a PowerPC - целевой архитектурой, это лишь один из примеров. Многие другие архитектуры могут использоваться в качестве одной или обеих исходных и целевых архитектур.

[0054] Каждая архитектура связана с ее собственными регистрами, которые она может использовать. Например, в z/Architecture есть 32 векторных регистра, а другие типы регистров могут быть отображены на квадрант векторных регистров. К примеру, как изображено на ФИГ.10, если есть файл регистра 1000, который содержит 32 векторных регистра 1002, и каждый регистр имеет 128 бит в длину, то 16 регистров с плавающей точкой 1004, которые имеют 64 бит в длину, могут быть наложены на векторные регистры. Таким образом, к примеру, когда регистр с плавающей точкой 2 изменяется, то векторный регистр 2 также изменяется. Другие отображения для других типов регистров также возможны.

[0055] Аналогично, PowerPC или другая целевая архитектура имеет ряд регистров, определенных для нее. Этот ряд регистров может быть отличным или одинаковым с набором регистров, выделенных для исходной архитектуры. Целевой регистр может иметь больше или меньше регистров, доступных для конкретного типа команды. Например, в примере, изображенном на ФИГ.9А, команда Vector Load и команда Load Vector Indexed имеют 32 векторных регистра, доступных для них. Возможны также другие примеры.

[0056] Как отмечено в коде операции, команда Vector Load содержит прерывистый спецификатор, который в этом примере представлен в полях V₁ и RXB. Эти прерывистые поля комбинируются для создания непрерывного индекса в команде Load Vector Indexed 950. Этот непрерывный спецификатор обозначен в поле VRT 954 команды 950. В этом частном примере, как показано в коде VL v18, 0(0, gr5), векторный регистр, который задается, есть регистр 18. Этот регистр задается в команде прерывистым спецификатором, предоставленным полем V₁ и полем RXB. В данном примере поле V₁ содержит значение 2 (двоичное 0010), а поле RXB содержит значение 8 (двоичное 1000). На основе предопределенных правил, поскольку V₁ является первым операндом, крайний левый бит (1) 1000 составляется с битами в поле V₁ (0010), образуя непрерывный спецификатор 10010, который равен десятичному значению 18.

[0057] Как обозначено числом 956, представление 18 помещается в поле VRT команды Load Vector Indexed, которое соответствует полю регистра (V₁) команды Vector Load. Для полноты поля RA и RB команды 950 соответствуют полям Х₂ и B₂ соответственно команды 900. Поле D₂ команды 900 не имеет соответствующего поля в команде 950, а поля кода операции команды 900 соответствуют полям кода операции команды 950.

[0058] Другой пример изображен на ФИГ.9Б. В этом примере, так же как и в примере, изображенном на ФИГ.9А, прерывистый спецификатор (V₁, RXB) команды 900 трансформируется в непрерывный спецификатор (VRT) команды 950. Однако в этом примере регистр, выделенный для команды 950, имеет не тот же номер, что трансформированный непрерывный спецификатор; вместо этого непрерывный спецификатор отображается на другой регистр. Например, в примере согласно ФИГ.9А прерывистый спецификатор указывает на регистр 18, так же как и непрерывный спецификатор. То есть это отображение один к одному. Однако на ФИГ.9Б прерывистый спецификатор 18 трансформируется в непрерывный спецификатор 18, но затем 18 непрерывного спецификатора отображается на другой регистр, такой как регистр 7 (см. числовое обозначение 980). То есть регистр 18 в исходной архитектуре отображается на регистр 7 в целевой архитектуре, в этом частном примере. Такое отображение предопределено и доступно процессору.

[0059] Еще один пример изображен на ФИГ.11. В этом примере вместо выделения регистра во время эмуляции, как на ФИГ.9А и 9Б, выделяется память. В этом примере команда, VLR, используется для перемещения содержимого одного векторного регистра, VR 18, в другой векторный регистр, VR 24. Однако в этом примере допускается, что файл регистра недостаточно велик, чтобы включать эти векторные регист