Перезапускаемые транслированные команды
Изобретение относится к вычислительной технике. Его использование при обработке данных процессорным ядром позволяет транслировать команды в пригодный для процессорного ядра вид с минимальным запаздыванием прерываний. Устройство для обработки данных содержит процессорное ядро, выполняющее команды из первого набора, транслятор команд для генерирования выходных сигналов, соответствующих командам из первого набора, чтобы эмулировать команды из второго набора, и блок обработки прерываний, обслуживающий прерывания после выполнения операции команд из первого набора. Технический результат достигается благодаря тому, что последовательности команд транслируются таким образом, что входное состояние не изменяется до тех пор, пока не будет выполнена конечная команда, а после прерывания при выполнении этой последовательности обработка перезапускается либо повторной полной эмуляцией, если конечная команда не начиналась, когда произошло прерывание, либо выполнением следующей команды из второго набора команд, если конечная операция началась, когда произошло прерывание. 3 н. и 14 з.п. ф-лы, 13 ил.
Данное изобретение относится к области обрабатывающих данные систем. Конкретнее, данное изобретение относится к обрабатывающим данные системам с процессорным ядром, способным выполнять команды из первого набора команд, и с транслятором, способным транслировать команды из второго набора команд в вид, пригодный для выполнения процессорным ядром.
Известны трансляторы команд, которые могут работать совместно с процессорным ядром, имеющим набор собственных команд для трансляции несобственных команд в собственные команды для выполнения процессорным ядром. Хотя такой подход и является привлекательным для расширения возможностей обрабатывающей данные системы, он приводит к некоторым трудностям и сложностям.
Одна из таких проблем состоит в том, как обращаться с сигналами прерываний. Желательно, чтобы обрабатывающая система реагировала на сигналы прерываний как можно быстрее. Это особенно важно в системах, управляющих операциями в реальном времени. Запаздывание прерывания может быть критическим характеристическим параметром и оценивается с помощью наихудшей ситуации. Соответственно, известным является выполнение собственных команд организовывать так, чтобы реакция на сигнал прерываний происходила по завершении текущей выполняемой собственной команды.
В контексте систем, в которых несобственные команды транслируются в собственные команды, часто возникает необходимость, чтобы единственная несобственная команда могла транслироваться в более чем одну собственную команду. Соответственно, если прерывание принимается во время выполнения последовательности собственных команд, представляющих единственную несобственную команду, то эта несобственная команда может быть завершена лишь частично, и состояние обрабатывающей системы может быть неопределенным. Один способ действий в этом случае может заключаться в обеспечении дополнительной аппаратуры, которая запускалась бы при приеме сигнала прерываний, чтобы сохранять текущее состояние обрабатывающей системы, так чтобы это состояние могло быть восстановлено до перезапуска после прерывания и тем самым любая частично завершенная несобственная команда могла бы выполняться далее до завершения. Однако такой подход имеет недостаток из-за наличия дополнительных расходов на аппаратное обеспечение, в значительной дополнительной сложности и может сам по себе ухудшить характеристики прерывания из-за необходимости сохранять состояние обрабатывающей системы перед обслуживанием прерывания.
Альтернативным подходом может быть управление системой так, чтобы с несобственными командами обходились как с неделимыми, т.е. прерывание не обслуживалось бы до тех пор, пока не было бы полностью завершено выполнение несобственной команды. Этот подход опять-таки неблагоприятно влияет на запаздывание прерывания.
Примеры известных систем для трансляции между наборами команд и другой фоновой информацией можно найти в следующих источниках: патенты США №№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 1st and 2nd 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-команды А11 и А12. Java-байт-код J2 отображается в АРМ-команды А21, А22 и А23. Наконец, Java-байт-код J3 отображается в АРМ-команду А31. Каждый из 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, могут комбинироваться в единственную таблицу переходов состояний или диаграмму состояний, но они показаны выше раздельно, чтобы способствовать ясности.
Соотношения между различными состояниями, условиями и полными действиями могут использоваться для определения аппаратной машины состояний (в виде конечного автомата) для управления этим аспектом работы транслятора 108 команд. Альтернативно эти соотношения могут моделироваться программным обеспечением или комбинацией аппаратного и программного обеспечения.
Ниже дается пример поднабора возможных Java-байт-кодов, который указывает для каждого Java-байт-кода из поднабора связанные потребное полное, потребное пустое значения и значение стекового действия для этого байт-кода, который можно использовать совместно с Таблицами 2, 3 и 4.
Ниже следует пример шаблонов команд для каждой команды Java-байт-кода, заданных выше. Эти показанные команды являются АРМ-командами, которые воплощают требуемое поведение каждого из Java-байт-кодов. Поле регистра "ВСО-3", "ВСО-2", "ВСО-1", "ВСО", "ВСО+1" и "ВСО+2" может быть заменено соответствующим описателем, который считывается из Таблицы 1 в зависимости от принятого в настоящий момент состояния отображения. Обозначение "ВСО+n " указывает n-й регистр над регистром, хранящим в настоящий момент верхний из стековых операндов, начиная с регистра, хранящего верхний из стековых операндов, и отсчитывая регистровое значение вверх до тех пор, пока не будет достигнут конец набора регистров, и в этой точке делается возврат к первому регистру в наборе регистров.
Пример последовательности выполнения иллюстрируется ниже для единственного Java-байт-кода, выполненного аппаратным блоком 108 транслятора в соответствии с методами, описанными выше. Последовательность выполнения показана в терминах начального состояния, изменяющегося через последовательность состояний в зависимости от выполняемых команд, с генерированием последовательности ARM-команд как результат действий, выполняемых на каждом переходе состояний, причем все в целом имеет эффект трансляции Java-байт-кода в последовательность АРМ-команд.
Фиг.6 иллюстрирует выполнение нескольких дальнейших команд Java-байт-кода иным образом. Верхняя часть фиг.6 иллюстрирует последовательность ARM-команд и изменения состояния отображения и содержимое регистров, которое получается по выполнении команды iadd Java-байт-кода. Начальное состояние отображения есть 00000, соответствующее тому, что все регистры в наборе регистров пусты. Первые две генерируемые АРМ-команды служат для помещения (POP) двух стековых операндов в регистры, хранящие стековые операнды, причем верхним из стека "ВСО" является регистр R0. Третья ARM-команда фактически выполняет операцию добавления и записывает результат в регистр R3 (который теперь становится верхним из стековых операндов), используя в то же время стековый операнд, который перед этим хранился в регистре R1, тем самым производя полное стековое действие -1.
Процесс обработки затем переходит к выполнению двух Java-байт-кодов, каждый из которых представляет длинную загрузку двух стековых операндов. Условие потребного пустого, равного 2, для первого Java-байт-кода удовлетворяется немедленно и соответственно две АРМ-команды LDR могут выдаваться и выполняться. Состояние отображения после выполнения первого Java-байт-кода длинной загрузки равно 01101. В этом состоянии набор регистров содержит лишь единственный пустой регистр. Следующая команда длинной загрузки Java-байт-кода имеет потребное пустое значение, равное 2, которое не удовлетворяется, и соответственно первым требуемым действием является выталкивание (PUSH) стекового операнда в адресуемую память с помощью АРМ-команды STR. Это освобождает регистр в наборе регистров для использования новым стековым операндом, который можно затем загрузить как часть двух следующих команд LDR. Как упомянуто ранее, трансляция команд может достигаться аппаратным образом, программным образом или их комбинацией. Ниже дается подсекция примера программного интерпретатора, генерируемого в соответствии с вышеописанными методами.
Фиг.7 иллюстрирует команду Java-байт-кода "laload", которая имеет функцию считывания двух слов данных из матрицы данных, определенной двумя словами данных, начиная с верхнего из стековых операндов. Эти два слова, считанные из матрицы данных, заменяют затем два слова, которые определяли их положение, и формируют самые верхние стековые записи.
Для того чтобы команда "laload" имела достаточное регистровое пространство для временного хранения стековых операндов, выбираемых из матрицы без перезаписи входных стековых операндов, которые определяют матрицу и положение в матрице данных, команда Java-байт-кода определяется как имеющая потребное пустое значение, равное 2, т.е. два из регистров в банке регистров, назначенном для хранения стековых операндов, должны быть пустыми до выполнения ARM-команд, эмулирующих команду "laload". Если двух пустых регистров нет, то этот Java-байт-код приостанавливается, а затем могут выполняться операции сохранения (STR), чтобы вытолкнуть стековые операнды, хранящиеся в текущий момент в регистрах, в память, чтобы получить пространство, для нужного временного хранения и удовлетворить потребному пустому значению для команды.
Команда также имеет потребное полное значение, равное 2, т.к. положение данных определяется местоположением в матрице и указателем в этой матрице в виде двух отдельных стековых операндов. Чертеж иллюстрирует первое состояние как уже отвечающее потребному полному и потребному пустому условиям и имеющее состояние отображения "01001". Команда "laload" разделяется на три ARM-команды. Первая из них загружает ссылку на матрицу в запасной рабочий регистр вне набора регистров, действующий как регистровый кэш стековых операндов. Вторая команда затем использует эту ссылку на матрицу вместе со значением указателя в матрице, чтобы обратиться к первому матричному слову, которое записывается в один из пустых регистров, назначенных для хранения стековых операндов.
Важно отметить, что после выполнения первых двух ARM-команд состояние отображения системы не изменяется и верхний из стековых указателей остается таким, каким он был в начале с регистрами, определенными как пустые, оставаясь определенными точно так же.
Конечная команда в последовательности АРМ-команд загружает второе матричное слово в набор регистров для хранения стековых операндов. Поскольку это конечная команда, то, если на нее не приходится прерывание, она не будет обслуживаться до тех пор, пока не завершится команда, и потому она сохраняется для изменения входного состояния этой командой путем изменения состояния отображения регистров, хранящих стековые операнды. В этом примере состояние отображения меняется на "01011", которое помещает новый верхний из стековых указателей на второе матричное слово и указывает, что входными переменными матричной ссылки и значением указателя являются теперь новые пустые регистры, т.е. пометка регистров как пустых эквивалентна удалению хранимых ими значений из стека.
Следует отметить, что хотя полное стековое действие команды "laload" не меняет числа стековых операндов, хранящихся в регистрах, обмен состояний отображения тем не менее происходит. Смена состояния отображения, произведенная по выполнении конечной операции, аппаратно встроена в транслятор команд как функция транслируемого Java-байт-кода и указывается параметром "swap", показанным как характеристика команды "laload".
Хотя примером этого чертежа является одна конкретная команда, следует понимать, что представленные принципы могут быть расширены на много различных команд Java-байт-кодов, которые эмулируются как ARM-команды или иные виды команд.
Фиг.8 представляет собой блок-схему алгоритма, схематически иллюстрирующую вышеописанный метод. На этапе 10 Java-байт-код выбирается из памяти. На этапе 12 проверяются потребное полное и потребное пустое значения для этого Java-байт-кода. Если любое из потребного пустого или потребного полного условий не удовлетворяются, то соответствующие операции выталкивания (PUSH) и помещения (POP) стековых операндов (возможно, множества стековых операндов) могут выполняться на этапах 14 и 16. Следует отметить, что эта конкретная система не позволяет одновременно удовлетворять потребное пустое и потребное полное условия. Может потребоваться множество выполнении этапов 14 и 16 до тех пор, пока не будет удовлетворено условие этапа 12.
На этапе 18 выбирается первая ARM-команда, определенная в шаблоне трансляции для рассматриваемого Java-байт-кода. На этапе 20 производится проверка, является ли выбранная ARM-команда конечной командой, подлежащей выполнению при эмуляции Java-байт-кода, выбранного на этапе 10. Если выполняемая АРМ-команда является конечной командой, то этап 21 служит для обновления значения программного счетчика, чтобы он указывал на следующий Java-байт-код в последовательности подлежащих выполнению команд. Следует понимать, что если ARM-команда является конечной командой, то она завершит свое выполнение безотносительно к тому, происходит ли теперь прерывание, и соответственно она сохраняется для обновления значения программного счетчика на следующий Java-байт-код и вновь начинает выполнение с этой точки, когда состояние системы достигнет этого согласованного нормального непрерываемого полного выполнения Java-байт-кода. Если проверка на этапе 20 указывает, что конечный Java-байт-код не достигнут, то обновление значения программного счетчика обходится.
Этап 22 выполняет текущую ARM-команду. На этапе 24 производится проверка того, имеются ли какие-либо еще ARM-команды, которые требуют выполнения в качестве части шаблона. Если еще есть такие АКМ-команды, то следующая из них выбирается на этапе 26, и обработка возвращается на этап 20. Если команд больше нет, то обработка переходит к этапу 28, на котором любое изменение/смена отображения, определенного для рассматриваемого Java-байт-кода, выполняется для того, чтобы отразить требуемое верхнее из стековых местоположений и полный/пустой статус разных регистров, хранящих стековые операнды.
Фиг.8 также схематически иллюстрирует моменты времени, в которых обслуживается прерывание, если оно предполагается, а затем обработка начинается вновь после прерывания. Прерывание начинается для обслуживания после выполнения АРМ-команды, протекающей в данный момент на этапе 22, каким бы ни было текущее значение программного счетчика, хранящегося в качестве точки возврата последовательностью байт-кода. Если выполняемая текущая ARM-команда является конечной командой в шаблонной последовательности, то этап 21 будет сразу обновлять значение программного счетчика и, соответственно, это укажет на следующий Java-байт-код (или АРМ-команда должна быть только что инициированным переключателем набора команд). Если выполняемая в настоящий момент 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 (при счете обратно от любого заранее заданного значения, встроенного аппаратно в систему, или от значения, которое может управляться/программироваться пользователем), затем производится ответвление на код планировщика на этапе 76. По завершении кода планировщика на этапе 76 управление возвращается к аппаратному обеспечению и обработка переходит к этапу 72, где выбирается следующий Java-байт-код и счетчик снова уменьшается. Когда счетчик достигнет 0, он будет установлен равным новому ненулевому значению. Альтернативно новое значение может быть введено в счетчик как часть выполнения процесса планировщика на этапе 76.
Если проверка на этапе 74 показала, что счетчик не равен 0, то на этапе 78 выбирают Java-байт-код. На этапе 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.
1. Устройство для обработки данных, содержащее процессорное ядро, способное выполнять операции, определенные командами из первого набора команд; транслятор команд, способный транслировать команды из второго набора команд в выходные сигналы транслятора, соответствующие упомянутому первому набору команд, причем по меньшей мере одна команда из упомянутого второго набора команд определяет операцию, подлежащую выполнению с помощью одной или более входных переменных; блок обработки прерываний, реагирующий на сигнал прерываний для прерывания выполнения операций, соответствующих командам из упомянутого первого набора команд, после завершения выполнения текущей выполняемой операции; и логическую схему перезапуска для перезапуска выполнения после упомянутого прерывания; при этом упомянутый транслятор команд способен генерировать последовательность из одного или более наборов выходных сигналов транслятора, соответствующих командам из упомянутого первого набора команд, для представления упомянутой по меньшей мере одной команды из упомянутого второго набора команд, причем каждая последовательность такова, что не производится никаких изменений в упомянутых одной или более переменных до тех пор, пока не будет выполнена конечная операция в упомянутой последовательности; и после появления прерывания во время выполнения последовательности операций, представляющей упомянутую по меньшей мере одну из упомянутого второго набора команд: (i) если упомянутое прерывание появляется до начала выполнения конечной операции в упомянутой последовательности, то упомянутая логическая схема перезапуска повторно запускает выполнение с первой операции в упомянутой последовательности; и (ii) если упомянутое прерывание появляется после начала выполнения конечной операции в упомянутой последовательности, то упомянутая логическая схема перезапуска повторно запускает выполнение со следующей команды, следующей за упомянутой последовательностью.
2. Устройство по п.1, в котором упомянутый транслятор выдает сигналы, включающие в себя сигналы, формирующие команду из упомянутого первого набора команд.
3. Устройство по любому из пп.1 и 2, в котором упомянутые выходные сигналы транслятора включают в себя управляющие сигналы, которые управляют работой упомянутого процессорного ядра, и сигналы управления согласованием, вырабатываемые при декодировании команд из упомянутого первого набора команд.
4. Устройство по любому из пп.1, 2 и 3, в котором упомянутые выходные сигналы транслятора включают в себя управляющие сигналы, которые управляют работой упомянутого процессорного ядра и определяют параметры, не определенные управляющими сигналами, выработанными при декодировании команд из упомянутого первого набора команд.
5. Устройство по любому из предшествующих пунктов, в котором упомянутая логическая схема перезапуска является частью упомянутого транслятора команд.
6. Устройство по любому из предшествующих пунктов, в котором упомянутая логическая схема перезапуска сохраняет указатель на местоположение перезапуска в командах из упомянутого второго набора команд, которые транслируются, причем упомянутый указатель продвигается после выполнения упомянутой конечной операции.
7. Устройство по п.6, в котором упомянутый указатель является значением программного счетчика, указывающего на адрес в памяти для местоположения в памяти, хранящего команду из упомянутого второго набора команд, транслируемого в настоящий момент.
8. Устройство по любому из предшествующих пунктов, в котором команды из упомянутого второго набора команд определяют операции, подлежащие выполнению после сохранения стековых операндов в стеке, и упомянутые входные переменные включают в себя входные стековые операнды.
9. Устройство по п.8, в котором любые стековые операнды, удаленные из упомянутого стека по выполнении упомянутой по меньшей мере одной команды из упомянутого второго набора команд, не удаляются до тех пор, пока не начнется выполнение упомянутой конечной операции.
10. Устройство по любому из пп.8 и 9, в котором любые стековые операнды, добавленные в упомянутый стек выполнением упомянутой по меньшей мере одной команды из упомянутого второго набора команд, не добавляются до тех пор, пока не начнется выполнение упомянутой конечной операции.
11. Устройство по любому из предшествующих пунктов, в котором упомянутые входные переменные включают в себя переменные системных состояний, не определенные в упомянутой второй команде.
12. Устройство по любому из предшествующих пунктов, в котором упомянутый процессор имеет банк регистров, содержащий множество регистров, а команды из упомянутого первого набора команд выполняют операции после сохранения регистровых операндов в упомянутых регистрах.
13. Устройство по п.12, в котором набор регистров в упомянутом банке регистров сохраняет стековые операнды от верхней позиции упомянутого стека.
14. Устройство по п.13, в котором упомянутый транслятор команд имеет множество состояний отображения, в которых различные регистры в упомянутом наборе регистров сохраняют соответствующие стековые операнды из различных позиций упомянутого стека, причем упомянутый транслятор команд способен осуществлять переход между состояниями отображения, когда выполняется упомянутая конечная операция, чтобы обновить упомянутые входные переменные.
15. Устройство по любому из предшествующих пунктов, в котором упомянутые команды из упомянутого второго набора команд являются командами виртуальной машины Java.
16. Способ обработки данных, содержащий следующие этапы: выполнение операций как они определяются командами из первого набора команд; трансляция команд из второго набора команд в выходные сигналы транслятора, соответствующие командам из упомянутого первого набора команд, причем по меньшей мере одна команда из упомянутого второго набора команд определяет операцию, подлежащую выполнению с помощью одной или более входных переменных; в ответ на сигнал прерывания прерывание выполнения операций, соответствующих командам из упомянутого первого набора команд, после завершения выполнения текущей выполняемой операции; и перезапуск выполнения после упомянутого прерывания, при этом на упомянутом этапе трансляции генерируют последовательность из одного или более наборов выходных сигналов транслятора, соответствующих командам из упомянутого первого набора команд, чтобы представлять упомянутую по меньшей мере одну команду из упомянутого второго набора команд, причем каждая последовательность такова, что в упомянутые одну или более входных переменных не вносится никаких изменений до тех пор, пока не будет выполнена конечная операция; и после появления прерывания во время выполнения последовательности операций, представляющей упомянутую по меньшей мере одну из упомянутого второго набора команд: (i) если упомянутое прерывание появляется до начала выполнения конечной операции в упомянутой последовательности, то повторно запускают выполнение с первой операции в упомянутой последовательности; и (ii) если упомянутое прерывание появляется после начала выполнения конечной операции в упомянутой последовательности, то повторно запускают выполнение со следующей команды, следующей за упомянутой последовательностью.
17. Компьютерный программный продукт, содержащий компьютерную программу для управления компьютером, чтобы выполнять способ по п.16.
