Перезапускаемые транслированные команды

Перезапускаемые транслированные команды

Иллюстрации

Показать все

Реферат

Данное изобретение относится к области обрабатывающих данные систем. Конкретнее, данное изобретение относится к обрабатывающим данные системам с процессорным ядром, способным выполнять команды из первого набора команд, и с транслятором, способным транслировать команды из второго набора команд в вид, пригодный для выполнения процессорным ядром.

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

Одна из таких проблем состоит в том, как обращаться с сигналами прерываний. Желательно, чтобы обрабатывающая система реагировала на сигналы прерываний как можно быстрее. Это особенно важно в системах, управляющих операциями в реальном времени. Запаздывание прерывания может быть критическим характеристическим параметром и оценивается с помощью наихудшей ситуации. Соответственно, известным является выполнение собственных команд организовывать так, чтобы реакция на сигнал прерываний происходила по завершении текущей выполняемой собственной команды.

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

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

Примеры известных систем для трансляции между наборами команд и другой фоновой информацией можно найти в следующих источниках: патенты США №№5805895, 3955180, 5970242, 5619665, 5826089, 5925123, 5875336, 5937193, 5953520, 6021469, 5568646, 5758115, 5367685; IBM Technical Disclosure Bulletin, March 1988, pp. 308-309, "System/370 Emulator Assist Processor For a Reduced Instruction Set Computer"; IBM Technical Disclosure Bulletin, July 1986, pp. 548-549, "Full Function Series/I Instruction Set Emulator"; IBM Technical Disclosure Bulletin, March 1994, pp. 605-606, "Real-Time CISC Architecture HW Emulator On A RISC Processor"; IBM Technical Disclosure Bulletin, March 1998, p. 272, "Performance Improvement Using An EMULATION Control Block"; IBM Technical Disclosure Bulletin, January 1995, pp. 537-540, "Fast Instruction Decode For Code Emulation on Reduced Instruction Set Computer/Cycles Systems"; IBM Technical Disclosure Bulletin, February 1993, pp. 231-234, "High Performance Dual Architecture Processor"; IBM Technical Disclosure Bulletin, August 1989, pp. 40-43, "System/370 I/O Channel Program Channel Command Word Prefetch"; IBM Technical Disclosure Bulletin, June 1985, pp. 305-306, "Fully Microcode-Controlled Emulation Architecture"; IBM Technical Disclosure Bulletin, March 1972, pp. 3074-3076, "Op Code and Status Handling For Emulation"; IBM Technical Disclosure Bulletin, August 1982, pp. 954-956, "On-Chip Microcoding of a Microprocessor With Most Frequently Used Instructions of Large System and Primitives Suitable for Coding Remaining Instructions"; IBM Technical Disclosure Bulletin, April 1983, pp. 5576-5577, "Emulation Instruction"; the book ARM System Architecture by S. Furber; the book Computer Architecture: A Quantitative Approach by Hennessy and Patterson; и книга The Java Virtual Machine Specification by Tim Lindholm and Frank Yellin 1^st and 2^nd Editions.

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

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

процессорное ядро, способное выполнять операции, определенные командами из первого набора команд;

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

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

логическую схему перезапуска для перезапуска выполнения после упомянутого прерывания; при этом

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

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

(i) если упомянутое прерывание появляется до начала выполнения конечной операции в упомянутой последовательности, то упомянутая логическая схема перезапуска повторно запускает выполнение с первой операции в упомянутой последовательности;

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

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

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

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

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

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

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

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

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

выполнение операций, как они определяются командами из первого набора команд;

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

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

перезапуск выполнения после упомянутого прерывания, при этом

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

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

(i) если упомянутое прерывание появляется до начала выполнения конечной операции в упомянутой последовательности, то повторно запускают выполнение с первой операции в упомянутой последовательности;

(ii) если упомянутое прерывание появляется после начала выполнения конечной операции в упомянутой последовательности, то повторно запускают выполнение со следующей команды, следующей за упомянутой последовательностью.

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

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

Фиг.1 и 2 схематически представляют примерные структуры конвейеров команд;

Фиг.3 иллюстрирует более подробно структуру ступени выборки;

Фиг.4 схематически иллюстрирует считывание несобственных команд переменной длины из слов буферизованной команды на ступени выборки;

Фиг.5 схематически иллюстрирует систему обработки данных для выполнения как собственных команд процессорного ядра, так и команд, требующих трансляции;

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

Фиг.7 схематически иллюстрирует выполнение несобственной команды как последовательности собственных команд;

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

Фиг.9 схематически иллюстрирует трансляцию Java-байт-кодов в операционные коды ARM с помощью программных и аппаратных методов;

Фиг.10 схематически иллюстрирует поток управления между аппаратным транслятором, программным интерпретатором и программным планировщиком;

Фиг.11 и 12 иллюстрируют другой способ управления операциями планировщика с помощью подхода, основанного на таймере;

Фиг.13 представляет собой диаграмму сигналов, иллюстрирующую работу схемы по фиг.12.

Фиг.1 показывает первый примерный конвейер 30 команд типа, пригодного для использования в системе, основанной на ARM-процессоре. Конвейер 30 команд включает в себя ступень 32 выборки, ступень 34 декодирования собственных команд (ARM-команды/движок), ступень 36 выполнения, ступень 38 доступа к памяти и ступень 40 отложенной записи. Ступень 36 выполнения, ступень 38 доступа к памяти и ступень 40 отложенной записи являются по существу обычными. После ступени 32 выборки и перед ступенью 34 декодирования собственных команд предусматривается ступень 42 транслятора команд. Эта ступень 42 транслятора команд представляет собой конечный автомат, который транслирует Java-байт-коды переменной длины в собственные АРМ-команды. Ступень 42 транслятора команд способна к многошаговой (многоэтапной) работе, благодаря чему единственный Java-байт-код может генерировать последовательность ARM-команд, которые подаются по остальной части командного конвейера 30, чтобы выполнять операцию, определенную этим Java-байт-кодом. Простые команды Java-байт-кода могут потребовать только единственной ARM-команды для выполнения своих операций, тогда как для более сложных команд Java-байт-кода или в обстоятельствах, когда это диктуется состоянием окружающей системы, может потребоваться несколько ARM-команд для обеспечения операции, определенной командой Java-байт-кода. Эта многошаговая работа имеет место после ступени 32 выборки и, соответственно, мощность не расходуется при выборке множества транслированных ARM-команд или Java-байт-кодов из системной памяти. Команды Java-байт-кода хранятся в системной памяти обычным образом, так что на системную память не налагается дополнительных ограничений, чтобы поддерживать работу по трансляции Java-байт-кода.

Как показано, ступень 42 транслятора предусмотрена с обходным трактом. При работе не в режиме трансляции команд конвейер 30 команд может обходить ступень 42 транслятора команд и работать по существу неизменным образом, чтобы обеспечить декодирование собственных команд.

В конвейере 30 команд ступень 42 транслятора команд показана генерирующей выходные сигналы транслятора, которые полностью представляют соответствующие ARM-команды и поступают через мультиплексор на декодер 34 собственных команд. Транслятор 42 команд генерирует также некоторые добавочные управляющие сигналы, которые поступают на декодер 34 собственных команд. Ограничения битового пространства при кодировании собственных команд могут налагать ограничения на диапазон операндов, которые могут определяться собственными командами. Эти ограничения не обязательно также используются и несобственными командами. Добавочные управляющие сигналы предусматриваются для пропускания определяющих дополнительные команды сигналов, выделенных из несобственных команд, которые было бы невозможно определить в собственных командах, хранящихся в памяти. В качестве примера собственная команда может обеспечивать лишь относительно малое число битов для использования в качестве поля непосредственного операнда в собственной команде, тогда как несобственная команда может допускать расширенный диапазон, и это можно использовать с помощью добавочных управляющих сигналов для поступления расширенной части непосредственного операнда в декодер 42 собственных команд вне транслированной собственной команды, которая также проходит в декодер 42 собственных команд.

Фиг.2 иллюстрирует еще один конвейер 44 команд. В этом примере система снабжена двумя декодерами 46, 48 собственных команд, а также декодером 50 несобственных команд. Этот декодер 50 несобственных команд ограничен в операциях, которые он может определять, ступенью 52 выполнения, ступенью 54 памяти и ступенью 56 отложенной записи, которые предусмотрены для поддержки собственных команд. Соответственно, декодер 50 несобственных команд должен эффективно транслировать несобственные команды в собственные операции (которые могут быть единственной собственной операцией или последовательностью собственных операций), а затем выдавать соответствующие управляющие сигналы на ступень 52 выполнения, чтобы выполнять эти одну или более собственных операций. Следует отметить, что в этом случае декодер несобственных команд вырабатывает не сигналы, которые формируют собственную команду, а управляющие сигналы, которые определяют операции собственной команды (или расширенной собственной команды). Эти генерируемые управляющие сигналы могут не совпадать с управляющими сигналами, генерируемыми декодерами 46, 48 собственных команд.

В процессе работы команда, выбранная ступенью 58 выборки, селективно (выборочно) подается на один из декодеров 46, 48 или 50 команд в зависимости от конкретного режима обработки с помощью показанного демультиплексора.

Фиг.3 схематически иллюстрирует ступень выборки командного конвейера более подробно. Логическая схема 60 выборки выбирает командные слова фиксированной длины из системной памяти и подает их в буфер 62 командных слов. Этот буфер 62 командных слов представляет собой переключающийся буфер с двумя частями, так что он может хранить как текущее командное слово, так и следующее командное слово. Каждый раз, когда текущее командное слово полностью декодировано и декодирование переносится на следующее командное слово, логическая схема 60 выборки служит для замещения предыдущего командного слова следующим командным словом, подлежащим выборке из памяти, т.е. каждая часть переключающегося буфера будет поочередно увеличиваться на два командные слова, которые хранятся друг за другом.

В показанном примере максимальная длина команды Java-байт-кода составляет три байта. Соответственно, предусмотрены три мультиплексора, которые позволяют выбирать любые три соседних байта в каждой части буфера 62 слов и подавать их на транслятор 64 команд. Буфер 62 слов и транслятор 64 команд также снабжены обходным трактом 66 для использования, когда выбираются и декодируются собственные команды.

Видно, что каждое командное слово выбирается из памяти один раз и сохраняется в буфере 62 слов. Единственное командное слово может иметь множество Java-байт-кодов, считанных из него, по мере того как транслятор 64 команд выполняет трансляцию Java-байт-кодов в ARM-команды. Транслированные последовательности переменной длины собственных команд могут генерироваться без требования считывать запоминающую систему много раз и без потребления ресурсов памяти или наложения иных ограничений на запоминающую систему, т.к. операции трансляции команд ограничены в конвейере команд.

Значение программного счетчика связано с каждым Java-байт-кодом, транслируемым в данный момент. Это значение программного счетчика передается по ступеням конвейера так, что каждая ступень, если это необходимо, способна использовать информацию, относящуюся к конкретному Java-байт-коду, который она обрабатывает. Значение программного счетчика для Java-байт-кода, который транслируется в последовательность из множества операций ARM, не получает приращений до тех пор, пока не начнется выполнение конечной операции ARM-команды в этой последовательности. Сохранение значения программного счетчика таким образом, чтобы непосредственно указывать на команду в памяти, которая находится в процессе выполнения, существенно упрощает другие аспекты системы, такие как отладка и вычисления переходов.

Фиг.4 схематически иллюстрирует считывание команд Java-байт-кода переменной длины из буфера 62 команд. На первой стадии команда Java-байт-кода длиной в один байт считывается и декодируется. Следующую стадию образует команда Java-байт-кода, которая имеет длину три байта и охватывает два смежных командных слова, которые считываются из памяти. Оба этих командных слова присутствуют в буфере 62 команд, так что декодирование и обработка команд не задерживаются из-за такого распределения команды переменной длины между считываемыми командными словами. После считывания этих трех Java-байт-кодов из буфера 62 команд повторное заполнение ранее выбранного из командных слов может начинаться, пока продолжается последующая обработка по декодированию Java-байт-кодов из следующего командного слова, которое уже присутствует.

Последняя стадия, показанная на фиг.4, иллюстрирует вторую считываемую трех-байт-кодовую команду. Она снова распределена между командными словами. Если предшествующее командное слово еще не завершило свое заполнение, то считывание команды может задержаться остановкой конвейера до тех пор, пока соответствующее командное слово не будет записано в буфер 62 команд. В некоторых вариантах выполнения тактирование может быть таким, что конвейер никогда не останавливается из-за этого типа поведения. Следует понимать, что этот частный пример является относительно редким явлением, т.к. большинство Java-байт-кодов короче, чем проиллюстрированные примеры и, соответственно, два следующих друг за другом кода, когда оба они распределены по командным словам, достаточно редки. Сигнал достоверности может быть связан с каждым из командных слов в буфере 62 команд так, чтобы он был способен сигнализировать, заполнено ли должным образом командное слово, перед тем как Java-байт-код считывается из этого буфера.

Фиг.5 показывает систему 102 обработки данных, включающую в себя процессорное ядро 104 и банк 106 регистров. В командном тракте предусмотрен транслятор 108 команд для трансляции команд виртуальной машины Java в собственные ARM-команды (или соответствующие им управляющие сигналы), которые затем можно подавать на процессорное ядро 104. Транслятор 108 команд можно обходить, когда из адресуемой памяти выбираются собственные ARM-команды. Адресуемая память может быть системной памятью, такой как быстродействующая буферная память (кэш-память) с дополнительной вне-микросхемной оперативной памятью. Размещение транслятора 108 команд после запоминающей системы и, в частности, кэш-памяти, позволяет эффективно использовать емкость памяти запоминающей системы, поскольку плотные команды, которые требуют трансляции, могут храниться в запоминающей системе и лишь расширяться в собственные команды непосредственно перед передачей на процессорное ядро 104.

Банк 106 регистров в этом примере содержит шестнадцать универсальных 32-битовых регистра, четыре из которых назначены для использования при запоминании стековых операндов, т.е. набором регистров для запоминания стековых операндов являются регистры R0, R1, R2 и R3.

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

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

Как иллюстрируется на фиг.5, поток Java-байт-кодов J1, J2, J3 подается в транслятор 108 команд из адресуемой запоминающей системы. Транслятор 108 команд выводит затем поток АРМ-команд (или эквивалентных управляющих сигналов, возможно расширенных) в зависимости от входных Java-байт-кодов и мгновенное состояние отображения транслятора 108 команд, а также другие переменные. Показанный пример иллюстрирует отображение Java-байт-кода J1 в ARM-команды А¹1 и А¹2. Java-байт-код J2 отображается в АРМ-команды А²1, А²2 и А²3. Наконец, Java-байт-код J3 отображается в АРМ-команду А³1. Каждый из Java-байт-кодов может потребовать один или более стековых операндов в качестве входов и может вырабатывать один или более стековых операндов в качестве выхода. При условии, что процессорное ядро 104 в этом примере является АРМ-процессорным ядром, имеющим архитектуру загрузки/хранения, благодаря чему можно манипулировать только хранящимися в регистрах значения данных, транслятор 108 команд выполнен с возможностью генерировать АРМ-команды, которые при необходимости выбирают любые требуемые стековые операнды в набор регистров перед тем, как ими манипулируют, или сохраняют в адресуемой памяти любые стековые операнды, хранящиеся в настоящий момент в наборе регистров, чтобы приготовить место для результирующих стековых операндов, которые могут быть сгенерированы. Следует понимать, что каждый Java-байт-код может рассматриваться как имеющий связанное "потребное полное" значение, указывающее число стековых операндов, которые должны присутствовать в наборе регистров до его выполнения вместе с "потребным пустым" значением, указывающим число пустых регистров в наборе регистров, которые должны быть доступны до выполнения ARM-команд, представляющих операционный код Java.

Таблица 2 иллюстрирует соотношение между значениями начальных состояний отображения, потребными полными значениями, значениями конечных состояний и связанными АРМ-командами. Значения начальных состояний и значения конечных состояний соответствуют состояниям отображения, показанным в Таблице 1. Транслятор 108 команд определяет потребное полное значение, связанное с конкретным Java-байт-кодом (операционным кодом), который он транслирует. Транслятор (108) команд в зависимости от начального состояния отображения, в котором он находится, определяет, нужно ли загрузить больше стековых операндов в набор регистров до выполнения этого Java-байт-кода. Таблица 2 показывает начальные состояния вместе с тестами, применяемыми к потребному полному значению Java-байт-кода, которые совместно применяются, чтобы определить нужно ли загружать стековый операнд в набор регистров с помощью связанной АРМ-команды (команды LDR), а также конечное состояние отображения, которое будет иметь место после такой операции загрузки стекового кэша. На практике, если в набор регистров необходимо загрузить более одного стекового операнда до выполнения Java-байт-кода, то появится множество переходов состояний отображения, каждый из которых со связанной АВМ-командой загружает стековый операнд в один из регистров в наборе регистров. В иных вариантах выполнения возможно загружать множество стековых операндов в единственном переходе состояний и соответственно осуществлять изменения состояний отображения помимо тех, которые проиллюстрированы в Таблице 2.

Таблица 2
НАЧАЛЬНОЕ СОСТОЯНИЕ	ПОТРЕБНОЕ ПОЛНОЕ	КОНЕЧНОЕ СОСТОЯНИЕ	ДЕЙСТВИЯ
0000	>0	00100	LDR R0,	[Rstack,	#-4] !
00100	>1	01000	LDR R3,	[Rstack,	#-4] !
01001	>2	01101	LDR R3,	[Rstack,	#-4] !
01110	>3	10010	LDR R3,	[Rstack,	#-4] !
01111	>3	10011	LDR R0,	[Rstack,	#-4] !
01100	>3	10000	LDR R1,	[Rstack,	#-4] !
01101	>3	10001	LDR R2,	[Rstack,	#-4] !
01010	>2	01110	LDR R0,	[Rstack,	#-4] !
01011	>2	01111	LDR R1,	[Rstack,	#-4] !
01000	>2	01100	LDR R2,	[Rstack,	#-4] !
00110	>1	01010	LDR R1,	[Rstack,	#-4] !
00111	>1	01011	LDR R2,	[Rstack,	#-4] !
00101	>1	01001	LDR R0,	[Rstack,	#-4] !

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

Таблица 3 аналогичным образом иллюстрирует соотношение между начальным состоянием, потребным пустым состоянием, конечным состоянием и связанной АРМ-командой для опустошения регистра в наборе регистров, чтобы осуществлять переход между начальным состоянием и конечным состоянием, если потребное пустое значение конкретного Java-байт-кода указывает, что нужно задать начальное состояние перед тем, как выполняется этот Java-байт-код. Конкретные значения регистров, заносимые в адресуемую память командой STR, будут меняться в зависимости от того, какой из регистров в настоящий момент является верхним из стековых операндов.

Таблица 3
НАЧАЛЬНОЕ СОСТОЯНИЕ	ПОТРЕБНОЕ ПОЛНОЕ	КОНЕЧНОЕ СОСТОЯНИЕ	ДЕЙСТВИЯ
00100	>3	00000	STR R0,	[Rctack],	H
01001	>2	00101	STR R0,	[Rctack],	#4
01110	>1	01010	STR R0,	[Rctack],	#4
10011	>0	01111	STR R0,	[Rctack],	#4
10000	>0	01100	STR R1,	[Rctack],	#4
10001	>0	01101	STR R2,	[Rctack],	#4
10010	>0	01110	STR R3,	[Rctack],	#4
01111	>1	01011	STR R1,	[Rctack],	#4
01100	>1	01000	STR R2,	[Rctack],	#4
01101	>1	01001	STR R3,	[Rctack],	#4
01010	>2	00110	STR R1,	[Rctack],	#4
01011	>2	00111	STR R2,	[Rctack],	#4
01000	>2	00100	STR R3,	[Rctack],	#4
00110	>3	00000	STR R2,	[Rctack],	#4
00111	>3	00000	STR R3,	[Rctack],	#4
00101	>3	00000	STR R1,	[Rctack],	#4

Следует понимать, что в описанной выше примерной системе потребное полное и потребное пустое условия являются взаимоисключающими, иначе говоря, только одно из потребного полного или потребного пустого условий может быть истинным в любой данный момент времени для конкретного Java-байт-кода, который пытается транслировать транслятор команд. Шаблоны команд, используемые транслятором 108 команд вместе с командами, которые он выбирает для подачи в аппаратный транслятор 108 команд, выбираются так, чтобы можно было удовлетворить этому взаимоисключающему требованию. Если бы это требование не имело места, то могла бы возникнуть ситуация, в которой конкретный Java-байт-код требовал бы, чтобы несколько входных стековых операндов присутствовали в наборе регистров, что позволило бы иметь достаточно пустых регистров, доступных после выполнения команды, представляющей Java-байт-код, чтобы дать возможность результатам выполнения сохраняться в регистрах, как это нужно.

Следует понимать, что данный Java-байт-код будет иметь в целом действие всего стека, представляющее баланс между числом израсходованных стековых операндов и числом стековых операндов, генерируемых по выполнении этого Java-байт-кода. Поскольку число израсходованных стековых операндов представляет собой требование до выполнения, а число генерируемых стековых операндов представляет собой требование после выполнения, потребное полное и потребное пустое значения, связанные с каждым Java-байт-кодом, должны удовлетворяться до выполнения этого байт-кода, даже если все в целом действие само по себе и отвечало бы условиям. Таблица 4 иллюстрирует соотношение между начальным состоянием, всем стековым действием, конечным состоянием и изменением в использовании регистров и относительным положением верхнего из стековых операндов (ВСО). Может оказаться, что один или более переходов состояний, показанных в Таблице 2 или Таблице 3, должен выполняться до выполнения переходов состояний, показанных в Таблице 4, чтобы установить предварительные условия для данного Java-байт-кода в зависимости от потребного полного и потребного пустого значений Java-байт-кода.

Следует понимать, что соотношения между состояниями и условиями, представленными в Таблице 2, Таблице 3 и Таблице 4, могут комбинироваться в единственную таблицу переходов состояний или диаграмму состояний, но они показаны выше раздельно, чтобы способствовать ясности.

Соотношения между различными