Запоминание операндов стека в регистре

Запоминание операндов стека в регистре

Иллюстрации

Показать все

Реферат

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

Известны системы обработки данных, поддерживающие наборы множественных команд. Примерами таких систем являются процессоры, дающие возможность использовать набор команд Thumb, производимые компанией ARM лимитед, Кембридж, Англия, которые могут выполнять как команды Thumb 16 бит, так и команды ARM 32 бит. Как команды Thumb, так и команды ARM выполняют операции (такие как математические обработки, загрузки, сохранения и т.д.) над операндами, хранимыми в регистрах процессорного ядра, заданных полями регистров в командах. Значительные усилия тратятся на разработку компиляторов, которые могут эффективно использовать ресурсы регистров процессорного ядра для того, чтобы создавать потоки команд, которые выполняются быстро.

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

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

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

Примеры известных систем для трансляции между множествами команд и другой фоновой информацией могут быть найдены в следующих патентах и работах: патент США 5805895; патент США 3955180; патент США 5970242; патент США 5619655; патент США 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, рр. 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"; книга S. Furber ARM System Architecture; книга Hennessy and Patterson Computer Architecture: A Quantitative Approach; и книга Tim Lindholm и Frank Yellin "The Java Virtual Machine Specification", 1-ое и 2-ое издания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг.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-битных регистров общего назначения, четыре из которых выделяются для использования при хранении операндов стека, т.е. набором регистров для хранения операндов стека являются регистры RO, Rl, R2 и R3.

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

Таблица 1
состояние 00000
R0=пустой
R1=пустой
R2=пустой
R3=пустой
состояние 00100	сстояние 01000
R0=ВС (вершина стека, TOS)	R0=ВС
R1=пустой	R1=пустой
R2=пустой	R2=пустой
R3=пустой	R3=ВС-1
состояние 01100	состояние 10000
R0=ВС	R0=ВС
R1=пустой	R1=ВС-3
R2=ВС-2	R2=ВС-2
R3=ВС-1	R3=ВС-1
состояние 00101	состояние 01001
R0=пустой	R0=ВС-1
R1=ВС	R1=ВС
R2=пустой	R2=пустой
R3=пустой	R3=пустой
состояние 01101	состояние 10001
R0=ВС-1	R0=ВС-1
R1=ВС	R1=ВС
R2=пустой	R2=ВС-3
R3=ВС-2	R3=ВС-2

состояние 00110	состояние 01010
R0=пустой	R0=пустой
R1=пустой	R1=ВС-1
R2=ВС	R2=ВС
R3=пустой	R3=пустой
состояние 01110	состояние 10010
R0=ВС-2	R0=ВС-2
R1=ВС-1	R1=ВС-1
R2=ВС	R2=ВС
R3=пустой	R3=ВС-3
состояние 00111	состояние 01011
R0=пустой	R0=пустой
R1=пустой	R1=пустой
R2=пустой	R2=ВС-1
R3=ВС	R3=ВС
состояние 01111	состояние 10011
R0=пустой	R0=ВС-3
R1=ВС-2	R1=ВС-2
R2=ВС-1	R2=ВС-1
R3=ВС	R3=ВС

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

Как проиллюстрировано на фиг.5, поток байт-кодов J1, J2, J3 Java подается в транслятор 108 команд из системы адресуемой памяти. Транслятор 108 команд затем выводит поток команд ARM (или эквивалентные управляющие сигналы, возможно расширенные) в зависимости от входных байт-кодов Java и мгновенного состояния отображения транслятора 108 команд, а также других переменных. Проиллюстрированный пример изображает байт-код J1 Java, отображаемый в команды А¹1 и A¹2 ARM. Байт-код J2 Java

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

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

Таблица 2
Начальное состояние	"Требуемые заполненными"	Конечное состояние	Действия
00000	>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 таким же образом иллюстрирует зависимость между начальным состоянием, значением "требуемые пустыми", конечным состоянием и связанной командой ARM для освобождения регистра в наборе регистров, для того, чтобы переходить между начальным состоянием и конечным состоянием, если значение "требуемые пустыми" конкретного байт-кода Java указывает, что необходимо данное начальное состояние перед тем, как байт-код Java будет выполнен. Конкретные значения регистров, освобождаемые в адресуемую память с помощью команды STR (сохранить), будут изменяться в зависимости от того, какой из регистров содержит текущий операнд вершины стека.

Таблица 3
Начальное состояние	"Требуемые пустыми"	Конечное состояние	Действия
00100	>3	00000	STR R0, [Rstack], #4
01001	>2	00101	STR R0, [Rstack], #4
01110	>1	01010	STR R0, [Rstack], #4
10011	>0	01111	STR R0, [Rstack], #4
10000	>0	01100	STR R1, [Rstack], #4
10001	>0	01101	STR R2, [Rstack], #4
10010	>0	01110	STR R3, [Rstack], #4
01111	>1	01011	STR R1, [Rstack], #4
01100	>1	01000	STR R2, [Rstack], #4
01101	>1	01001	STR R3, [Rstack], #4
01010	>2	00110	STR R1, [Rstack], #4
01011	>2	00111	STR R2, [Rstack], #4
01000	>2	00100	STR R3, [Rstack], #4
00110	>3	00000	STR R2, [Rstack], #4
00111	>3	00000	STR R3, [Rstack], #4
00101	>3	00000	STR R1, [Rstack], #4

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

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