Настоящее изобретение относится к области систем обработки данных. Более конкретно, это изобретение относится к системам обработки данных, имеющим процессорное ядро с банком регистров, выполняющее команды из первого множества команд, используемое вместе с транслятором команд, действующим для того, чтобы транслировать команды из второго множества команд в команды первого множества команд.
Известны системы обработки данных, поддерживающие наборы множественных команд. Примерами таких систем являются процессоры, дающие возможность использовать набор команд 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 можно видеть, что первые три бит значения состояния указывают число непустых регистров в наборе регистров. Последние два бит значения состояния указывают номер регистра регистра, хранящего операнд вершины стека. Таким образом, значение состояния может быть легко использовано для управления работой аппаратного транслятора или программного транслятора для того, чтобы учитывать занятость набора регистров и текущую позицию операнда вершины стека.
Как проиллюстрировано на фиг.5, поток байт-кодов J1, J2, J3 Java подается в транслятор 108 команд из системы адресуемой памяти. Транслятор 108 команд затем выводит поток команд ARM (или эквивалентные управляющие сигналы, возможно расширенные) в зависимости от входных байт-кодов Java и мгновенного состояния отображения транслятора 108 команд, а также других переменных. Проиллюстрированный пример изображает байт-код J1 Java, отображаемый в команды А11 и A12 ARM. Байт-код J2 Java
отображается в команды А21, A22 и А23 ARM. Наконец, байт-код J3 Java отображается в команду A31 ARM. Каждый из байт-кодов Java может требовать одного или более стековых операндов в качестве входов и может создавать один или более операндов стека в качестве выхода. При условии, что процессорное ядро 104 в этом примере является процессорным ядром ARM, имеющим архитектуру загрузки/хранения, посредством которой можно манипулировать только значениями данных, хранимыми в регистрах, транслятор 108 команд устроен так, чтобы генерировать команды ARM, которые, когда необходимо, выбирают любые необходимые стековые операнды в набор регистров перед тем, как ими манипулируют или они сохраняются в адресуемой памяти любых хранимых в текущий момент операндов стека в наборе регистров для того, чтобы освободить место для результирующих операндов стека, которые могут быть сформированы. Понятно, что каждый байт-код Java может рассматриваться как имеющий связанное "требуемые заполненными" значение, указывающее число операндов стека, которые должны присутствовать в множестве регистров перед их выполнением, вместе с "требуемые пустыми" значением, указывающим число пустых регистров в множестве регистров, которые должны иметь место перед выполнением команд ARM, представляющих код операции Java.
Таблица 2 иллюстрирует зависимость между значениями начального состояния отображения, "требуемые заполненными" значениями, значениями конечного состояния и связанными командами ARM. Значения начального состояния и значения конечного состояния соответствуют состояниям отображения, проиллюстрированным в таблице 1. Транслятор 108 команд определяет "требуемые заполненными" значение, связанное с конкретным байт-кодом (кодом операции) Java, который он транслирует. Транслятор 108 команд в зависимости от начального состояния отображения, которое он имеет, определяет, требуется ли или нет загрузить еще операнды стека в набор регистров перед выполнением байт-кода Java. Таблица 1 изображает начальные состояния вместе с проверками, применяемыми к значению "требуемые заполненными" байт-кода Java, которые вместе применяются для того, чтобы определить, требуется ли загрузить операнд стека в набор регистров с использованием связанной команды ARM (команды LDR (загрузить)), а также конечное состояние отображения, которое будет принято после такой операции загрузки стека в кэш. На практике, если требуется загрузить более одного стекового операнда в набор регистров перед выполнением байт-кода Java, будут происходить множественные переходы состояний отображения, каждый со связанной командой ARM, загружающей стековый операнд в один из регистров из набора регистров. В различных осуществлениях может быть возможно загружать множественные стековые операнды в одном переходе состояния и, таким образом, выполнять изменения состояний отображения, кроме тех, которые проиллюстрированы в таблице 2.
Как можно видеть из таблицы 2, новый стековый операнд, загруженный в набор регистров, хранящих стековые операнды, будет формировать новый операнд вершины стека, и он будет загружен в конкретный один из регистров в наборе регистров в зависимости от начального состояния.
Таблица 3 таким же образом иллюстрирует зависимость между начальным состоянием, значением "требуемые пустыми", конечным состоянием и связанной командой ARM для освобождения регистра в наборе регистров, для того, чтобы переходить между начальным состоянием и конечным состоянием, если значение "требуемые пустыми" конкретного байт-кода Java указывает, что необходимо данное начальное состояние перед тем, как байт-код Java будет выполнен. Конкретные значения регистров, освобождаемые в адресуемую память с помощью команды STR (сохранить), будут изменяться в зависимости от того, какой из регистров содержит текущий операнд вершины стека.
Понятно, что в вышеописанной примерной системе условия "требуемые заполненными" и "требуемые пустыми" являются взаимно исключающими, то есть только одно из условий "требуемые заполненными" и "требуемые пустыми" может быть истинным в любое данное время для конкретного байт-кода Java, который транслятор команд пытается транслировать. Шаблоны команд, используемые транслятором 108 команд, вместе с командами, которые он выбирает для того, чтобы поддерживать с помощью аппаратного транслятора 108 команд, выбираются так, чтобы удовлетворялось это взаимно исключающее требование. Если это требование не имело бы места, тогда могла бы возникнуть ситуация, в которой конкретный байт-код Java требовал ряда входных операндов стека, присутствующих в наборе регистров, которые не дали бы возможности достаточному количеству свободных регистров быть доступными после выполнения команды, представляющей байт-код Java, для того, чтобы дать возможность результатам выполнения храниться в регистрах, когда требуется.
Понятно, что данный байт-код Java будет иметь общее конечное действие, представляющее баланс между числом потребляемых стековых операндов и числом сгенерированных стековых операндов после выполнения этого байт-кода Java. Так как число потребляемых стековых операндов представляет требование перед выполнением, а число сгенерированных стековых операндов представляет требование после выполнения, значения "требуемые заполненными" и "требуемые пустыми", связанные с каждым байт-кодом Java, должны удовлетворяться перед выполнением этого байт-кода, даже если конечное общее действие само бы удовлетворялось. Таблица 4 иллюстрирует зависимость между начальным состоянием, общим действием над стеком, конечным состоянием и изменением в использовании регистра и относительной позицией операнда вершины стека (TOS). Может быть необходимо один или более переходов состояний, проиллюстрированных в таблице 2 или таблице 3, выполнить перед выполнением переходов состояний, проиллюстрированных в таблице 4, для того, чтобы установить предварительные условия для данного байт-кода Java в зависимости от значений "требуемые заполненными" и "требуемые пустыми" байт-кода Java.
Понятно, что зависимости между состояниями и условиями, проиллюстрированные в таблице 2, таблице 3 и таблице 4, могут быть объединены в одну таблицу переходов состояний или диаграмму состояния, но они изображены отдельно выше для ясности.
Зависимости между различными состояниями, условиями и конечными действиями могут быть использованы для того, чтобы определить аппаратный автомат состояний (в виде конечного автомата) для управления этим аспектом работы транслятора 108 команд. Альтернативно эти зависимости могли бы быть смоделированы с помощью программного обеспечения или сочетания аппаратного обеспечения и программного обеспечения.
Ниже следует пример подмножества возможных байт-кодов Java, который указывает для каждого байт-кода Java подмножества связанные значения "требуемые заполненными", "требуемые пустыми" и действия над стеком для этого байт-кода, который может быть использован вместе с таблицами 2, 3 и 4.
Также ниже приведены примерные шаблоны команд для каждой из команд байт-кодов Java, изложенных выше. Изображенные команды являются командами ARM, которые реализуют требуемое поведение каждого из байт-кодов Java. Поле регистра "TOS-3", "TOS-2", "TOS-1", "TOS", "TOS+1" и "TOS+2" может быть заменено подходящим спецификатором, как считанным из таблицы 1, в зависимости от выбранного в текущий момент режима отображения. Обозначение "TOS+n" указывает N-ый регистр выше регистра, хранящего в текущий момент операнд вершины стека, начиная с регистра, хранящего операнд вершины стека. и отсчитывая вверх в значении регистра до достижения конца набора регистров, в котором делается точка возврата в первый регистр из набора регистров.
Примерная последовательность выполнения проиллюстрирована ниже для одного байт-кода Java, выполняемого устройством 108 аппаратной трансляции в соответствии со способами, описанными выше. Последовательность выполнения изображена в терминах начального состояния, продвижения вперед через последовательность состояний в зависимости от выполняемых команд, генерирования последовательности команд ARM в результате действий, выполняемых в каждом переходе состояния, причем все имеет результат трансляции байт-кода Java в последовательность команд ARM.
Фиг.6 иллюстрирует другим способом выполнение ряда дополнительных команд байт-кодов Java. Верхняя часть фиг.6 иллюстрирует последовательность команд ARM и изменения состояний отображения и содержимое регистров, которое появляется после выполнения команды байт-кода Java iadd. Начальное состояние отображения равно 00000, соответствуя пустому состоянию всех регистров в наборе регистров. Первые две сгенерированные команды ARM служат для выталкивания двух операндов стека в регистры, хранящие операнды стека с регистром вершины стека "TOS", являющимся RO. Третья команда ARM фактически выполняет операцию сложения и записывает результат в регистр R3 (который теперь становится операндом вершины стека), в то же время используя операнд стека, который был ранее сохранен в регистре R1, таким образом, создавая общее действие над стеком -1.
Обработка затем переходит к выполнению двух байт-кодов Java, причем каждый представляет длинную загрузку двух операндов стека. Условие "требуемые пустыми" 2 для первого байт-кода Java немедленно удовлетворяется, и, таким образом, две команды ARM LDR (загрузить) могут быть выданы и выполнены. Состояние отображения после выполнения первого байт-кода длинной загрузки Java равно 01101. В этом состоянии набор регистров содержит только один пустой регистр. Следующая команда байт-кода Java длинной загрузки имеет значение "требуемые пустыми" 2, которое не удовлетворяется, и, таким образом, первым требуемым действием является поместить операнд стека в адресуемую память с использованием команды ARM STR. Это освобождает регистр в наборе регистров для использования новым операндом стека, который может быть затем загружен как часть двух следующих команд LDR. Как упомянуто ранее, трансляция команд может выполняться с помощью аппаратного обеспечения, программного обеспечения или их сочетания. Ниже приведен подсегмент примерного программного интерпретатора, сгенерированный в соответствии с вышеописанными способами.
Фиг.7 иллюстрирует команду байт-кода Java "laload", которая имеет функцию считывания двух слов данных из массива данных, определенного двумя словами данных, начиная с вершины позиции стека. Два слова, считанные из массива данных, затем заменяются двумя словами, которые определили их позиции, и так, чтобы сформировать самые верхние элементы стека.
Для того, чтобы команда "laload" имела достаточно места регистра для временного хранения операндов стека, выбираемых из массива, без перезаписи входных операндов стека, которые определяют массив и позицию в массиве данных, команда байт-кода Java определяется как имеющая значение "требуемые пустыми" 2, т.е. два регистра в банке регистров, выделенные для хранения операндов стека, должны быть освобождены перед выполнением команд ARM, эмулирующих команду "laload". Если не имеется двух пустых регистров, когда встречается этот байт-код Java, тогда операции сохранения (STR) могут быть выполнены для того, чтобы поместить операнды стека, хранящиеся в текущий момент в регистрах, из памяти так, чтобы обеспечить необходимое место для временного запоминания и удовлетворить значение "требуемые пустыми" для команды.
Команда также имеет значение "требуемые пустыми" 2, так как позиция данных определена местоположением массива, и индекс в этом массиве, в качестве двух отдельных операндов стека. Чертеж иллюстрирует первое состояние, как уже удовлетворяющее условиям "требуемые заполненными" и "требуемые пустыми", и имеющее состояние отображения "01001". Команда "laload" разбивается на три команды ARM. Первая из них загружает начало массива в свободный рабочий регистр вне набора регистров, выступающий в качестве кэш-регистра операндов стека. Вторая команда затем использует это начало массива вместе со значением индекса в массиве для того, чтобы выбрать первое слово массива, которое записано в один из пустых регистров, выделенных для хранения операндов стека. Важно заметить, что после выполнения первых двух команд ARM состояние отображения системы не изменяется, и указатель вершины стека остается, где он начинался, с регистрами, определенными как пустые, по-прежнему являющимися так определенными.
Последняя команда в последовательности команд ARM загружает второе слово массива в набор регистров для хранения операндов стека. Так как это последняя команда, если во время нее не происходит прерывание, тогда она не будет обслуживаться до тех пор, пока не будет завершена команда, и таким образом безопасно изменить входное состояние с помощью этой команды с помощью изменения на состояние отображения регистров, хранящих операнды стека. В этом примере состояние отображения изменяется на "01011", которое помещает новый указатель вершины стека во втором слове массива и указывает, что входные переменные начала массива и значение индекса теперь являются пустыми регистрами, т.е. отметка регистров в качестве пустых эквивалентна удалению значений, которые они хранят, из стека.
Будет замечено, что в то время как общее действие над стеком команды "laload" не изменило число операндов стека, хранящихся в регистрах, тем не менее, произошел обмен состояния отображения. Изменение состояния отображения, выполненное после выполнения последней операции, передается с помощью аппаратных средств в транслятор команд как функция транслируемого байт-кода Java и указывается с помощью параметра "обмен", изображенного как характеристика команды "laload".
Несмотря на то, что пример на этом чертеже является одной специфической командой, понятно, что изложенные принципы могут быть расширены на множество других команд байт-кода Java, которые эмулируются как команды ARM или другие типы команд.
Фиг.8 - блок-схема последовательности операций, схематически иллюстрирующая вышеупомянутый способ. На этапе 10 байт-код Java выбирается из памяти. На этапе 12 исследуются значения "требуемые заполненными" и "требуемые пустыми" для этого байт-кода Java. Если любое из условий "требуемые заполненными" или "требуемые пустыми" не удовлетворяется, тогда соответствующие операции вытолкнуть и поместить операнды стека (возможно, множественные операнды стека) могут быть выполнены с помощью этапов 14 и 16. Следует заметить, что эта конкретная система не позволяет одновременно не выполняться условиям "требуемые пустыми" и "требуемые заполненными". Множество выполнении этапов 14 и 16 могут требоваться до тех пор, пока не будет удовлетворяться это условие на этапе 12.
На этапе 18 выбирается первая команда ARM, определенная в шаблоне трансляции рассматриваемого байт-кода ARM. На этапе 20 выполняется проверка относительно того, является ли выбранная команда ARM последней командой, выполняемой при эмуляции байт-кода Java, выбранного на этапе 10. Если выполняемая команда ARM является последней командой, тогда этап 21 служит для того, чтобы обновить значение программного счетчика для того, чтобы указать на следующий байт-код Java в последовательности выполняемых команд. Понятно, что, если команда ARM является последней командой, тогда она завершает свое выполнение независимо от того, происходит или нет теперь прерывание и, таким образом, безопасно обновить значение программного счетчика для следующего байт-кода Java, и повторно запустить выполнение с этой точки, так как состояние системы достигнет этого согласования нормально, без прерывания, полное выполнение байт-кода Java. Если проверка на этапе 20 указывает, что последний байт-код не достигнут, тогда обновление значения программного счетчика обходится.
Этап 22 выполняет текущую команду ARM. На этапе 24 выполняется проверка относительно того, имеются или нет еще команды ARM, которые требуют выполнения в качестве части шаблона. Если имеются еще команды ARM, тогда следующая из них выбирается на этапе 26, и обработка возвращается на этап 20. Если больше не имеется команд, тогда обработка переходит на этап 28, на котором выполняется любое изменение/обмен отображения, определенное для рассматриваемого байт-кода Java, для того, чтобы отразить желаемое местоположение вершины стека и статус полный/пустой различных регистров, хранящих операнды стека.
Фиг.8 также схематически иллюстрирует точки, в которых прерывание, если защищено, обслуживается, а затем обработка возобновляется после прерывания. Прерывание начинает обслуживаться после выполнения команды ARM, продвигающейся вперед в текущий момент, на этапе 22 с любым текущим значением программного счетчика, хранимым в качестве точки возврата с последовательностью байт-кода. Если текущая выполняемая команда ARM является последней командой в последовательности шаблонов, тогда на этапе 21 обновится только значение программного счетчика и, таким образом, он будет указывать на следующий байт-код Java (или команду ARM, если переключение множества команд только что инициализировано). Если выполняемая в текущий момент команда ARM является какой-то другой, а не последней командой в последовательности, тогда значение программного счетчика будет по-прежнему тем же самым, что и значение, указанное в начале выполнения рассматриваемого байт-кода Java, и, таким образом, когда выполняется возврат, весь байт-код Java будет повторно выполняться.
Фиг.9 иллюстрирует устройство 68 трансляции байт-кодов Java, которое принимает поток байт-кодов Java и выводит оттранслированный поток команд ARM (или соответствующих управляющих сигналов) для того, чтобы управлять работой процессорного ядра. Как описано ранее, транслятор 68 байт-кода Java транслирует простые байт-коды Java с использованием шаблонов команд в команды ARM или последовательность команд ARM. Когда каждый байт-код Java выполнен, тогда значение счетчика в управляющих логических схемах 70 планирования уменьшается. Когда это значение счетчика достигает 0, тогда устройство 68 трансляции байт-кода Java выдает команду ARM перехода к коду планирования, который управляет планированием между потоками или задачами соответствующим образом.
В то время как простые байт-коды Java обрабатываются самим устройством 68 трансляции байт-кода Java, обеспечивающим выполнение с высокой скоростью этих байт-кодов на основе аппаратного обеспечения, байт-коды, требующие более сложных операций обработки, посылаются в интерпретатор программного обеспечения, обеспеченный в виде набора подпрограмм интерпретации (примеры выбора таких подпрограмм даны выше в этом описании). Более конкретно, устройство 68 трансляции байт-кодов Java может определить, что байт-код, который оно приняло, не является байт-кодом, поддерживаемым аппаратной трансляцией, и, таким образом, может быть сделан переход по адресу, зависящему от байт-кода Java, где находится или указывается ссылкой подпрограмма программного обеспечения для интерпретации этого байт-кода. Этот механизм может быть также использован, когда логические схемы 70 планирования указывают, что требуется операция планирования для того, чтобы выдать переход в программу планирования.
Фиг.10 иллюстрирует работу варианта осуществления, изображенного на фиг.9, более подробно, и разделение задач между аппаратным обеспечением и программным обеспечением. Все байт-коды Java принимаются устройством 68 трансляции байт-кодов Java и заставляют счетчик увеличиваться на этапе 72. На этапе 74 выполняется проверка относительно того, достигло ли значение счетчика 0. Если значение счетчика достигло 0 (отсчитывая назад либо от заранее определенного значения, аппаратно реализованного в системе, либо от значения, которое может управляться/программироваться пользователем), тогда выполняется переход к программе планирования на этапе 76. Когда программа планирования завершена на этапе 76, управление возвращается к аппаратному обеспечению, и обработка переходит на этап 72, где выбирается следующий байт-код Java, и счетчик опять уменьшается. Так как счетчик достиг 0, тогда он будет теперь снова возвращен в новое, ненулевое значение. Альтернативно, новое значение может быть принудительно введено в счетчик, как часть выхода из процесса планирования на этапе 76.
Если проверка на этапе 74 показала, что счетчик не равен 0, тогда на этапе 78 выбирают байт-код. На этапе 80 выполняется определение относительно того, является ли выбранный байт-код простым байт-кодом, который может быть выполнен трансляцией с помощью аппаратного обеспечения на этапе 82, или требует более сложной обработки и, таким образом, должен быть передан для программной интерпретации на этапе 84. Если обработка передана для программной интерпретации, тогда, после ее завершения, управление возвращается к аппаратному обеспечению, где этап 72 определяет счетчик опять для того, чтобы учесть выборку следующего байт-кода Java.
Фиг.11 иллюстрирует альтернативное управляющее устройство. В начале обработки на этапе 86 сбрасывается сигнал команды (сигнал планирования). На этапе 88 выбранный байт-код Java исследуется для того, чтобы выяснить, является ли он простым байт-кодом, для которого поддерживается трансляция с помощью аппаратного обеспечения. Если аппаратная трансляция не поддерживается, тогда управление передается в интерпретирующее программное обеспечение на этапе 90, которое затем выполняет подпрограмму команд ARM для того, чтобы интерпретировать байт-код Java. Если байт-код является простым байт-кодом, для которого поддерживается аппаратная трансляция, тогда обработка выполняется в соответствии с этапом 92, на котором выдаются последовательно одна или более команд ARM устройством 68 трансляции байт-кода Java, действующим как вид многоциклового конечного автомата. Когда байт-код Java соответствующим образом обработан, либо на этапе 90, либо на этапе 92, тогда обработка переходит на этап 94, на котором сигнал команды устанавливается в течение короткого периода, перед тем как сбрасывается на этапе 86. Установка сигнала команды указывает внешним схемам, что соответствующая безопасная точка достигнута, в которой основанное на таймере планирование прерывания могло бы иметь место без риска потери целостности данных из-за частичного выполнения интерпретированной или оттранслированной команды.
Фиг.12 иллюстрирует примерные схемы, которые могут использоваться для того, чтобы реагировать на сигнал команды, генерируемый на фиг.11. Таймер 96 периодически генерирует сигнал таймера после истечения данного периода времени. Этот сигнал таймера запоминается в схеме-защелке 98 до тех пор, пока он не сбрасывается с помощью сигнала прерывания сбрасывания таймера. Выходной сигнал схемы-защелки 98 логически объединяется с помощью логической схемы 100 "И" с сигналом команды, установленным на этапе 94. Когда схема-защелка установлена и сигнал команды установлен, тогда генерируется прерывание как выходной сигнал логической схемы 100 "И" и используется для того, чтобы запустить прерывание, которое выполняет операции планирования с использованием механизма обработки прерываний, обеспечиваемого в системе для обработки стандартных прерываний. Когда сигнал прерывания сгенерирован, он, в свою очередь, инициирует формирование сигнала прерывания сброса таймера, который сбрасывает схему-защелку 98 до тех пор, пока не появится следующий выходной импульс таймера.
Фиг.13 - сигнальная диаграмма, иллюстрирующая работу схемы фиг.12. Тактовые сигналы процессорного ядра появляются с регулярной частотой. Таймер 96 генерирует сигналы таймера в заранее определенные периоды для того, чтобы указывать, что, когда безопасно, должна быть инициализирована операция планирования. Сигналы таймера являются фиксируемыми. Сигналы команд генерируются в моменты времени, разделенные интервалами, которые зависят от того, как быстро был выполнен конкретный байт-код Java. Простой байт-код Java может выполняться в одном тактовом цикле процессорного ядра или чаще, в двух или трех, тогда как сложный байт-код Java, обеспечивающий функцию высокого уровня управления, который может требовать несколько сотен тактовых циклов процессора перед своим выполнением, выполняется программным интерпретатором. В любом случае ожидаемый установленный фиксируемый сигнал таймера не действует на инициирование операции планирования до тех пор, пока не будет выдан сигнал команды, указывающий, что можно безопасно начинать операцию планирования. Одновременное появление фиксируемого сигнала таймера и сигнала команды инициирует генерирование сигнала прерывания, за которым непосредственно следует сигнал сброса, который сбрасывает схему-защелку 98.
Изобретение относится к области систем обработки данных. Техническим результатом является повышение быстродействия системы. Устройство обработки данных включает в себя процессорное ядро, имеющее банк регистров, который включает в себя набор регистров, которые используются для хранения стековых операндов. Команды из второго набора команд, определяющие стековые операнды, транслируются транслятором команд в команды первого набора команд или управляющие сигналы, соответствующие этим командам и определяющие регистровые операнды. Эти оттранслированные команды затем выполняются процессорным ядром. Транслятор команд имеет множественные состояния отображения для управления, какие регистры соответствуют каким стековым операндам в стеке. Изменения между состояниями отображения выполняются в зависимости от стековых операндов, добавляемых в набор регистров или удаляемых из него. 3 н. и 12 з.п. ф-лы, 4 табл., 13 ил. 
процессорное ядро, имеющее банк регистров, содержащий множество регистров, и выполненное с возможностью выполнения операций над регистровыми операндами, хранимыми в упомянутых регистрах, как определено в командах первого набора команд; и
транслятор команд, транслирующий команды второго набора команд в выходные сигналы транслятора, соответствующие командам упомянутого первого набора команд, причем команды упомянутого второго набора команд задают операции, подлежащие выполнению над стековыми операндами, хранимыми в стеке; в котором
упомянутый транслятор команд выполнен с возможностью назначать набор регистров в упомянутом банке регистров для того, чтобы хранить стековые операнды из части упомянутого стека;
упомянутый транслятор команд имеет множество состояний отображения, в которых различные регистры в упомянутом наборе регистров хранят соответствующие стековые операнды из различных позиций в упомянутой части упомянутого стека;
упомянутый транслятор команд выполнен с возможностью изменения между состояниями отображения в зависимости от операций, которые добавляют или удаляют стековые операнды, хранимые в упомянутом наборе регистров, и в котором упомянутый транслятор команд использует множество шаблонов команд для трансляции команд из упомянутого второго набора команд в команды из упомянутого первого набора команд, и команда из упомянутого второго набора команд, включающая в себя один или более стековых операндов, имеет шаблон команды, содержащий одну или более команд из упомянутого набора команд, в котором регистровые операнды отображаются в упомянутые стековые операнды в зависимости от текущего принятого состояния отображения упомянутого транслятора команд.
логических схем аппаратной трансляции;
программного кода интерпретации команд, управляющего компьютерным устройством;
программного кода компиляции команд, управляющего компьютерным устройством; и
логических схем аппаратной компиляции.
транслируют команды второго набора команд в выходные сигналы транслятора, соответствующие командам упомянутого первого набора команд, используя множество шаблонов команд, причем команды упомянутого второго набора команд задают операции, подлежащие выполнению над стековыми операндами, хранимыми в стеке;
назначают набор регистров в упомянутом банке регистров для того, чтобы хранить стековые операнды из части упомянутого стека;
переводят в одно из множества состояний отображения, в которых различные регистры в упомянутом наборе регистров хранят соответствующие стековые операнды из различных позиций в упомянутой части упомянутого стека, причем команды из упомянутого второго набора команд, включающие в себя один или более стековых операндов, имеют шаблон команд, содержащий одну или более команд из упомянутого первого набора команд, в котором регистровые операнды отображаются в упомянутые стековые операнды в зависимости от текущего принятого состояния отображения упомянутого транслятора команд; и осуществляют изменения между состояниями отображения в зависимости от операций, которые добавляют или удаляют стековые операнды, хранимые в упомянутом наборе регистров.
| RU 98110069 A, 27.09.1999.RU 2147378 C1, 10.04.2000.WO 00/34844 A2, 15.06.2000.US 5898885 A, 27.04.1999. |
