Настоящее изобретение относится к области систем обработки данных. Более конкретно, данное изобретение относится к обработке необработанных операций в системах, поддерживающих множество наборов команд.
Известны системы обработки данных, которые поддерживают множество наборов команд. Примером таких систем являются Thumb-активируемые процессоры компании ARM Limited of Cambridge, England. Эти Thumb-активируемые процессоры поддерживают как выполнение 32-разрядных ARM-команд, так и выполнение 16-разрядных Thumb-команд.
В системе обработки данных иногда возникает ситуация, при которой программную команду невозможно обработать непосредственно системой обработки данных. Поэтому известно обеспечение средств для обработки таких необработанных операций. В качестве примера такой ситуации можно назвать преждевременные прекращения выполнения команды предварительной выборки. Известно, что при предварительной выборке команд в системе виртуальной памяти загрузка команды может пересечь границу страницы и может произойти преждевременное прекращение выполнения, так как новая страница еще не отображена соответствующим образом в системе виртуальной памяти. После этого можно правильно поместить отображение и повторно выдать предварительную выборку команды.
Еще одним примером такой ситуации является выполнение команд с плавающей точкой. Известно, что во время выполнения операций с плавающей точкой могут возникать ситуации, которые невозможно обработать непосредственно системой обработки данных. Это особенно касается систем с плавающей точкой, совместимых со спецификацией IEEE 754. Примеры таких ситуаций включают в себя деление на нуль, любые операции, связанные с NaN (Not a Number, «не число»), любые операции, связанные с бесконечностью, или некоторые операции, связанные с денормализованными числами.
Возникающая при этом проблема заключается в том, что при добавлении нового набора команд требуются значительные усилия и развитие, чтобы гарантировать, что будут обеспечены соответствующие средства для всех возможных преждевременных прекращений выполнения.
Особая проблема появляется при возникновении необработанной операции с плавающей точкой. В основе многих систем определение операции с плавающей точкой, которая не была обработана, осуществляется посредством анализа потока команд. При новом наборе команд эти системы необходимо переписать, чтобы принять во внимание новый набор команд. Кроме того, проблема возникает, когда новый набор команд может сформировать множество операций с плавающей точкой для одной команды нового набора команд. В этом случае система может оказаться неспособной определить, какая операция с плавающей точкой не была обработана при анализе потока команд, так как одна команда может породить более чем одну необработанную операцию с плавающей точкой.
Еще одна проблема возникает, когда необработанные операции с плавающей точкой неточные, то есть когда необработанная операция с плавающей точкой обнаруживается не в момент выполнения команды, породившей операцию с плавающей точкой, а несколько позже. Эта ситуация возникает из-за параллельного характера множества систем с плавающей точкой. Система обработки данных, встретив команду, задающую операцию с плавающей точкой, выдает операцию с плавающей точкой в подсистему обработки данных с плавающей точкой. После выдачи операции с плавающей точкой в подсистему обработки данных с плавающей точкой главная система обработки данных продолжает выполнять следующие команды в потоке команд. Многие команды можно выполнить до того, как подсистема обработки данных с плавающей точкой обнаружит необработанную операцию с плавающей точкой и подаст сигнал о состоянии «необработанная операция» в главную систему обработки данных. В этом случае причину необработанной операции с плавающей точкой невозможно определить посредством анализа потока команд. Известно, что в таких случаях система с плавающей точкой содержит регистр, который идентифицирует необработанную операцию с плавающей точкой, например векторную систему с плавающей точкой компании ARM Limited of Cambridge, England.
Во многих системах подсистема обработки данных с плавающей точкой не может подавать сигнал о необработанной операции в главную систему обработки данных в произвольный момент, напротив, она может подавать сигнал в главную систему обработки данных только в точно определенные моменты, когда главная система обработки данных выполняет квитирование с подсистемой обработки данных с плавающей точкой. Типично, такие квитирования выполняются только после выполнения команды, задающей операцию с плавающей точкой. В этом случае сигнал о необработанной операции с плавающей точкой не может быть передан в главную систему обработки данных до тех пор, пока главная система обработки данных не выполнит следующую команду, задающую операцию с плавающей точкой.
Введение нового набора команд, который может выполнять множество операций с плавающей точкой на одну команду вместе с неточными необработанными операциями с плавающей точкой, обуславливает возникновение очень сложных проблем или делает невозможным для системы обработать необработанную операцию с плавающей точкой. Система не может определить, какая команда вызвала необработанную операцию с плавающей точкой, а также не может определить, когда должно продолжиться выполнение в потоке команд после того, как будет обработана необработанная операция с плавающей точкой.
В работе Ludwig Claβen, Ulrich Weisner: 80286-Programmierung, 1990, VEB Verlag Technik, Berlin, ISBN 3-341-00867-5 раскрыта система, в которой в необязательном порядке присутствует математический сопроцессор. Конфигурационный флажок служит индикатором отсутствия математического сопроцессора. Если математический сопроцессор отсутствует, то выполняется эмуляция команд математического сопроцессора.
Согласно одному аспекту изобретения предложено устройство для обработки данных под управлением программных команд из первого набора команд и одного или нескольких дополнительных наборов команд, характеризуемое тем, что содержит:
детектор (238) необработанной операции, предназначенный для обнаружения необработанной операции, возникающей во время выполнения программной команды первого набора команд,
обработчик (250) необработанной операции, предназначенный, после обнаружения упомянутой необработанной операции, для запуска эмуляции упомянутой команды первого набора команд с использованием одной или нескольких команд из по меньшей мере одного из упомянутых одного или нескольких дополнительных наборов команд,
средство (236) обработки исключительных ситуаций, относящееся к упомянутым одному или нескольким дополнительным наборам команд и предназначенное для обработки любой последующей необработанной операции, возникающей во время эмуляции упомянутой команды первого набора команд.
В изобретении признается, что перечисленные выше проблемы можно существенно уменьшить, создав для систем возможность распознавания необработанных операций в первом наборе команд, но при этом не требуя обязательного исправления данной ситуации и повторного выполнения данной команды первого набора команд. Вместо этого, команда первого набора команд (или нового набора команд), которая вызвала появление необработанной операции, эмулируется одной или несколькими командами одного или нескольких дополнительных наборов команд (например, второго набора команд). В зависимости от типа возникшей необработанной операции существует возможность, что необработанная операция не повторится снова после эмуляции. Альтернативно, если необработанная операция возникает также и после эмуляции с использованием команд одного или нескольких дополнительных наборов команд, можно использовать существующие средства для работы с такими необработанными операциями одного или нескольких дополнительных наборов команд, чтобы преодолеть необработанную операцию.
Обработчик необработанной операции может выдавать команды для устранения состояния "необработанная операция" системы обработки данных. Некоторые системы обработки данных содержат один или несколько флажков, которые регистрируют, находится ли система обработки данных в состоянии "необработанная операция". Может потребоваться сброс этого флажка обработчиком необработанной операции до эмуляции упомянутой команды первого набора команд. Нужно ли снимать флажок, зависит от типа необработанной операции, а также от того, имеется ли в наличии флажок, связанный с данным типом необработанной операции.
Хотя предложенная методика может иметь самое широкое применение, она особенно хорошо подходит для систем, в которых первый набор команд является набором команд переменной длины, а один или более дополнительных наборов команд являются наборами команд фиксированной длины. При такой комбинации в наборе команд переменной длины могут возникать новые типы необработанной операции, которые невозможны в наборе команд фиксированной длины, и средства, разработанные для работы с этими необработанными операциями в одном или нескольких дополнительных наборах команд, невозможно легко адаптировать для работы с необработанной операцией, когда она возникает в связи с первым набором команд переменной длины как таковым.
Конкретная ситуация, в которой настоящая методика обеспечивает особые преимущества, касается преждевременного прекращения выборки команд переменной длины. В такой ситуации команда переменной длины может распространяться более чем на одно командное слово, и поэтому может быть неясно, выборка какой команды вызвала данную необработанную операцию. Это затрудняет правильную обработку необработанной операции.
Настоящая методика также особенно хорошо подходит для систем, содержащих систему или подсистему обработки данных с плавающей точкой, в которой одна команда первого набора команд может сформировать множество операций с плавающей точкой или в которой сигнализация о необработанных операциях с плавающей точкой является неточной.
Конкретная ситуация, в которой настоящая методика особенно предпочтительна, касается систем, в которых одна команда первого набора команд может сгенерировать множество операций с плавающей точкой вместе с неточной сигнализацией о необработанных операциях с плавающей точкой. В такой ситуации система, возможно, будет не способна определить, какая команда первого набора команд послужила причиной необработанной операции с плавающей точкой.
В предложенной методике эта ситуация преодолевается запуском эмуляции команды первого набора команд, которая выполнялась, когда была запущена необработанная операция с плавающей точкой, с использованием одной или нескольких команд одного или нескольких дополнительных наборов команд. Команда первого набора команд, которая выполнялась, когда была запущена необработанная операция с плавающей точкой, может быть или не быть командой, ставшей причиной данной необработанной операции с плавающей точкой. Независимо от того, вызвала ли или нет команда первого набора команд, которая выполнялась, когда была запущена необработанная операция с плавающей точкой, необработанную операцию с плавающей точкой, эмуляция команды первого набора команд, которая выполнялась, когда была запущена необработанная операция с плавающей точкой, вынудит применить существующие средства, предназначенные для обработки таких необработанных операций одного или нескольких дополнительных наборов команд, чтобы преодолеть необработанную операцию.
Перед эмуляцией команды первого набора команд с использованием команд одного или нескольких дополнительных наборов команд может потребоваться, чтобы обработчик необработанной операции с плавающей точкой удалил флажок необработанной операции с плавающей точкой, если таковой имеется.
Если команда первого набора команд, которая выполнялась, когда была запущена необработанная операция с плавающей точкой, была командой, которая вызвала данную необработанную операцию с плавающей точкой, то та же самая необработанная операция с плавающей точкой повторится при эмуляции команды, и существующие средства, предназначенные для обработки таких необработанных операций одного или нескольких дополнительных наборов команд, будут использованы для преодоления необработанной операции.
Если команда первого набора команд, которая выполнялась, когда была запущена необработанная операция с плавающей точкой, не была командой, которая вызвала необработанную операцию с плавающей точкой, потому что система обработки данных использует неточное обнаружение необработанной операции с плавающей точкой, то та же самая необработанная операция с плавающей точкой не повторится при эмуляции этой команды. В этом случае система обработки данных обычно имеет флажок необработанной операции с плавающей точкой или эквивалентное средство для регистрации того факта, что произошла необработанная операция с плавающей точкой. Кроме того, система обработки данных обычно регистрирует операцию с плавающей точкой, которая вызвала данную необработанную операцию с плавающей точкой.
Удаление флажка или другого средства, используемого для регистрации того факта, что произошла необработанная операция с плавающей точкой, обычно приводит к использованию существующих средств, предназначенных для работы с такими необработанными операциями одного или нескольких дополнительных наборов команд, чтобы преодолеть необработанную операцию.
В других системах может быть необходимым проверить флажок или другое средство, и если он указывает, что была зарегистрирована необработанная операция с плавающей точкой, то после этого прямо используются средства одного или нескольких дополнительных наборов команд, предназначенные для работы с необработанными операциями, перед сбросом флажка или другого средства. При использовании средств одного или нескольких наборов команд, предназначенных для работы с такими необработанными командами, сброс флажка или другого средства может также происходить автоматически, в этом случае нет необходимости, чтобы обработчик необработанной операции с плавающей точкой явным образом сбрасывал флажок или другое средство.
В следующих видах систем может отсутствовать необходимость проверки флажка или другого средства. Вместо этого может быть достаточным использовать средства одного или нескольких дополнительных наборов команд для работы с необработанной операцией. Этого может быть достаточно, потому что уже известно, что флажок или другое средство установлено в силу того факта, что система исполняет код в обработчике необработанной операции с плавающей точкой, или может возникнуть случай, при котором применение данных средств повлечет проверку и возможный последующий сброс флажка или другого средства в качестве неотъемлемой части применения таких средств.
Независимо от точных методик, применяемых в обработчике необработанной операции с плавающей точкой, которые могут быть разными в разных системах, если команда первого набора команд, которая выполнялась, когда была запущена необработанная операция с плавающей точкой, не была командой, которая вызвала необработанную операцию с плавающей точкой, то необработанная операция с плавающей точкой будет разрешена до эмуляции команды первого набора команд, которая запустила необработанную операцию с плавающей точкой. В этом случае эмуляция команды первого набора команд может стать или не стать причиной необработанной операции. Однако неизвестно, вызовет ли она необработанную операцию или нет, и поэтому невозможно просто возобновить выполнение, так как это может привести к возможному бесконечному циклу с многократным запуском необработанной операции с плавающей точкой и многократному повторному выполнению команды обработчиком необработанной операции с плавающей точкой. Поэтому необходимо эмулировать команду первого набора команд и возобновить выполнение на следующей команде.
Предложенный способ также особенно пригоден для ситуаций, в которых один или несколько дополнительных наборов команд являются собственным набором команд процессорного ядра, и при этом характерно наличие набора хорошо разработанных обработчиков преждевременного прекращения, и первый набор команд является интерпретированным набором команд такого типа, для которого может быть желательным добавить поддержку на более позднем этапе. Конкретным примером такого интерпретированного первого набора команд переменной длины могут служить команды Java-байт-кода.
Согласно другому аспекту настоящего изобретения предложен способ обработки данных под управлением программных команд из первого набора команд и одного или нескольких дополнительных наборов команд, заключающийся в том, что
обнаруживают (238) необработанную операцию, возникающую во время выполнения программной команды первого набора команд,
после обнаружения упомянутой необработанной операции запускают эмуляцию (250) упомянутой команды первого набора команд с использованием одной или более команд по меньшей мере одного из упомянутых одного или нескольких дополнительных наборов команд,
обрабатывают любую последующую необработанную операцию, возникающую во время эмуляции упомянутой команды первого набора команд, с использованием средства обработки исключительных ситуаций, относящегося к упомянутым одному или нескольким дополнительным наборам команд.
Согласно следующему аспекту изобретения предложен компьютерный программный продукт для управления устройством обработки данных, предназначенным для обработки данных под управлением программных команд из первого набора команд и одного или нескольких дополнительных наборов команд, характеризуемый тем, что содержит
логическое средство обработчика (250) необработанной операции, предназначенное, после обнаружения необработанной операции, возникающей во время выполнения команды первого набора команд, для запуска эмуляции упомянутой команды, которая вызвала упомянутую необработанную операцию, с использованием одной или нескольких команд по меньшей мере одного из упомянутых одного или нескольких дополнительных наборов команд,
логическое средство (236) обработки исключительных ситуаций, относящееся к упомянутым одному или нескольким дополнительным наборам команд и предназначенное для обработки любой последующей необработанной операции, возникающей во время эмуляции упомянутой команды первого набора команд.
Кроме представления в виде устройства и способа работы устройства настоящее изобретение может быть представлено в виде компьютерного вспомогательного кода, который служит в качестве обработчика необработанной операции. Этот вспомогательный код можно распространять на отдельных записываемых носителях, внедрять в качестве встроенных программ во встроенную систему обработки или какими-либо другими путями.
Далее исключительно в качестве примера будут описаны варианты осуществления изобретения со ссылкой на прилагаемые чертежи, на которых
фиг.1 иллюстрирует систему обработки данных, содержащую аппаратный транслятор байт-кодов,
фиг.2 схематически иллюстрирует программную интерпретацию команд байт-кодов,
фиг.3 изображает алгоритм работы кодового фрагмента в программном интерпретаторе команд, который заканчивается командой завершения последовательности,
фиг.4 изображает примерный кодовый фрагмент, исполняемый вместо байт-кода,
фиг.5 иллюстрирует примерный вариант системы обработки данных, которая не имеет аппаратной поддержки исполнения байт-кодов,
фиг.6 изображает алгоритм, иллюстрирующий работу программного интерпретатора команд при работе с системой, изображенной на фиг.5,
фиг.7 иллюстрирует отображение между Java-байт-кодами и операциями обработки,
фиг.8 иллюстрирует программируемую трансляционную таблицу в форме ассоциативной памяти,
фиг.9 иллюстрирует программируемую трансляционную таблицу в форме памяти с произвольным доступом,
фиг.10 изображает алгоритм, схематически иллюстрирующий инициализацию и программирование программируемой трансляционной таблицы,
фиг.11 изображает схематически часть конвейера обработки в системе, которая выполняет интерпретацию Java-байт-кодов,
фиг.12 схематически изображает команду переменной длины, распространяющуюся на два командных слова и две страницы виртуальной памяти,
фиг.13 схематически иллюстрирует часть конвейера системы обработки данных, включающую средство для работы с преждевременными прекращениями предварительной выборки такого типа, как показан на фиг.12,
фиг.14 представляет логическое выражение, показывающее один из путей, как можно обнаружить преждевременное прекращение предварительной выборки, такого типа, как показан на фиг.12,
фиг.15 схематически иллюстрирует комбинацию вспомогательного кода для обработки преждевременного прекращения и эмуляции команды,
фиг.16 изображает алгоритм, схематически иллюстрирующий обработку, выполняемую для преодоления преждевременных прекращений предварительной выборки команд байт-кода переменной длины,
фиг.17 иллюстрирует взаимосвязь между операционной системой и разными процессами, которыми она управляет,
фиг.18 иллюстрирует систему обработки, включающую процессорное ядро и Java-ускоритель,
фиг.19 изображает алгоритм, схематически иллюстрирующий операции операционной системы при управлении конфигурацией Java-ускорителя,
фиг.20 изображает алгоритм, схематически иллюстрирующий работу виртуальной машины Java в связи с механизмом ускорения Java, используемую при управлении конфигурацией механизма ускорения Java,
фиг.21 иллюстрирует систему обработки данных, содержащую аппаратный транслятор байт-кодов, как на фиг.1, дополнительно содержащую подсистему обработки данных с плавающей точкой,
фиг.22 иллюстрирует систему обработки данных, содержащую аппаратный транслятор байт-кодов, как на фиг.1, и подсистему обработки данных с плавающей точкой, как на фиг.21, а также дополнительно содержащую регистр операции с плавающей точкой и флажок состояния "необработанная операция",
фиг.23 изображает ARM-команды с плавающей точкой, сформированные для Java-команд с плавающей точкой,
фиг.24 изображает последовательность ARM-команд, которая может быть сгенерирована аппаратным Java-ускорителем для Java-команд "dmul" и "dcmpg",
фиг.25 изображает последовательность операций при выполнении команды "dmul", за которой следует команда "dcmpg", когда необработанная операция с плавающей точкой вызвана выполнением команды FCMPD, сгенерированной аппаратным Java-ускорителем для Java-команды "dmul", причем показана последовательность операций для системы с использованием неточного обнаружения необработанной операции, соответствующего фиг.22,
фиг.26 изображает состояние регистра операции с плавающей точкой и флажок состояния "необработанная операция" после исполнения команды FMULD на фиг.25,
фиг.27 изображает последовательность операций при выполнении команды "dmul", за которой следует команда "dcmpg", когда необработанная операция с плавающей точкой вызвана исполнением команды FCMPD, сгенерированной аппаратным Java-ускорителем для Java-команды "dcmpg", причем показана последовательность операций для системы с использованием неточного обнаружения необработанной операции, соответствующего фиг.22,
фиг.28 показывает состояние регистра операций с плавающей точкой и флажка состояния "необработанная операция" после выполнения команды FCMPD на фиг.27,
фиг.29 показывает последовательность операций при выполнении команды "dmul", за которой следует команда "dcmpg", когда необработанная операция с плавающей точкой вызвана выполнением команды FMULD, сгенерированной аппаратным Java-ускорителем для Java-команды "dmul", причем последовательность операций показана для системы с использованием точного обнаружения необработанной операции, соответствующего фиг.21,
фиг.30 показывает последовательность операций при выполнении команды "dmul", за которой следует команда "dcmpg", когда необработанная операция с плавающей точкой вызвана выполнением команды FCMPD, сгенерированной аппаратным Java-ускорителем для Java-команды "dcmpg", причем последовательность операций показана для системы с использованием точного обнаружения необработанной операции с плавающей точкой, соответствующего фиг.21.
На фиг.1 изображена система 2 обработки данных, которая содержит процессорное ядро 4, например процессор ARM, и аппаратный транслятор 6 байт-кодов (также именуемый Jazelle). Процессорное ядро 4 содержит банк 8 регистров, декодер 10 команд и информационный канал 12 для выполнения различных операций обработки данных после сохранения значений данных в регистрах банка 8 регистров. Предусмотрен регистр 18, который содержит флажок 20, контролирующий, включен ли в данный момент аппаратный транслятор 6 байт-кодов. Кроме того, предусмотрен регистр 19, который содержит флажок 21, указывающий, активен ли в данный момент аппаратный транслятор байт-кодов. Иными словами, флажок 21 указывает, выполняет ли в данный момент система обработки данных Java-байт-коды или ARM-команды. Понятно, что в других вариантах регистры 18 и 19 могут быть выполнены в виде одного регистра, содержащего оба флажка 20 и 21.
В процессе работы, если выполняются Java-байт-коды и активен аппаратный транслятор 6 байт-кодов, Java-байт-коды поступают в аппаратный транслятор байт-кодов и служат для формирования последовательности соответствующих ARM-команд (в данном конкретном примерном неограничительном варианте осуществления) или, по меньшей мере, сигналов управления процессорным ядром, представляющих ARM-команды, которые затем подаются в процессорное ядро 4. Следовательно, аппаратный транслятор 6 байт-кодов может отобразить простой Java-байт-код в последовательность соответствующих ARM-команд, которые могут исполняться процессорным ядром 4. Когда аппаратный транслятор байт-кодов не активен, процесс идет в обход, и нормальные ARM-команды могут подаваться в декодер 10 ARM-команд для управления процессорным ядром 4 в соответствии с его собственным набором команд. Понятно, что по всему описанию последовательности ARM-команд могут быть также последовательностями Thumb-команд и/или комбинацией команд из разных наборов команд, и такие альтернативы предусмотрены изобретением и подпадают под его объем.
Понятно, что аппаратный транслятор 6 байт-кодов может обеспечить поддержку аппаратной трансляции только для поднабора возможных Java-байт-кодов, которые могут встретиться. Некоторые Java-байт-коды могут потребовать настолько обширной и абстрактной обработки, что будет неэффективным пытаться отобразить их в аппаратных средствах в соответствующие операции ARM-команд. Соответственно, когда аппаратный транслятор 6 байт-кодов встречает такой не поддерживаемый аппаратно байт-код, он запускает программный интерпретатор команд, записанный в собственных ARM-командах, для выполнения обработки, указанной не поддерживаемым аппаратно Java-байт-кодом.
Программный интерпретатор команд может быть записан для обеспечения программной поддержки всем возможным Java-байт-кодам, которые могут быть интерпретированы. Если предусмотрен и включен аппаратный транслятор 6 байт-кодов, то в обычном случае только не поддерживаемые аппаратно Java-байт-коды будут отсылаться к соответствующим фрагментам кода в программном интерпретаторе команд. Однако если аппаратный транслятор 6 байт-кодов не предусмотрен или отключен (например, во время отладки или т.п.), то все Java-байт-коды будут отсылаться в программный интерпретатор команд.
На фиг.2 схематически проиллюстрирована работа программного интерпретатора команд. Поток Java-байт-кодов 22 представляет программу Java. Между Java-байт-кодами могут находиться операнды. Следовательно, после выполнения данного Java-байт-кода следующий подлежащий исполнению Java-байт-код может появиться непосредственно в следующей позиции байта или позже, через несколько позиций, если присутствуют перемежающие байты операнда.
Как показано на фиг.2, может встретиться Java-байт-код ВС4, который не поддерживается аппаратным транслятором 6 байт-кодов. Этот факт запускает исключительную ситуацию в аппаратном трансляторе 6 байт-кодов, при которой производится просмотр таблицы 24 указателей с использованием значения ВС4 байт-кода в качестве индекса для считывания указателя Р#4 на кодовый фрагмент 26, который будет выполнять обработку, заданную не поддерживаемым аппаратно байт-кодом ВС4. Значение базового адреса из таблицы указателей можно также сохранить в регистре. Выбранный кодовый фрагмент затем вводится с указанием R14 на неподдерживаемый байт-код ВС4.
Как видно на чертеже, поскольку имеется 256 возможных значений байт-кодов, таблица 24 указателей содержит 256 указателей. Аналогичным образом, до 256 собственных кодовых фрагментов ARM-команд предусмотрено для выполнения обработки, заданной всеми возможными Java-байт-кодами. (Их может быть меньше 256 в тех случаях, когда два байт-кода могут использовать один и тот же кодовый фрагмент). Аппаратный транслятор 6 байт-кодов будет типично обеспечивать аппаратную поддержку для множества простых Java-байт-кодов, чтобы повысить скорость обработки, и в этом случае соответствующие кодовые фрагменты в программном интерпретаторе команд не будут использоваться никогда, за исключением вынужденных случаев, например во время отладки или в других обстоятельствах, таких как преждевременное прекращение предварительной выборки, которые будут обсуждаться ниже. Однако, поскольку они обычно являются более простыми и короткими кодовыми фрагментами, их обеспечение не потребует большого объема дополнительной памяти. Кроме того, этот небольшой объем дополнительной памяти более чем компенсируется родовым характером программного интерпретатора команд и его способностью справиться со всеми возможными Java-байт-кодами в обстоятельствах, когда аппаратный транслятор байт-кодов отсутствует или отключен.
Можно заметить, что каждый из кодовых фрагментов 26 по фиг.2 заканчивается командой BXJ завершения последовательности. Команда BXJ завершения последовательности имеет разное действие в зависимости от состояния системы 2 обработки данных, как будет проиллюстрировано на фиг.3. На фиг.3 представлен алгоритм, иллюстрирующий в весьма схематичном виде обработку, выполняемую кодовым фрагментом 26 в программном интерпретаторе команд. На этапе 28 выполняется операция, указанная интерпретируемым Java-байт-кодом. На этапе 30 считывается из потока 22 байт-кодов следующий подлежащий исполнению Java-байт-код, и указатель байт-кода в потоке 22 Java-байт-кодов, соответствующий данному следующему Java-байт-коду, сохраняется в регистре банка 8 регистров, а именно R14. Следовательно, для Java-байт-кода ВС4 следующим байт-кодом будет ВС5, и в регистр R14 будет загружен указатель на следующую ячейку памяти Java-байт-кода ВС5.
На этапе 32 указатель в таблице указателей 24, соответствующий следующему Java-байт-коду ВС5, считывается из таблицы указателей 24 и сохраняется в регистре банка 8 регистров, а именно в регистре R12.
Понятно, что на фиг. 3 этапы 28, 30 и 32 проиллюстрированы как выполняемые раздельно и последовательно. Однако согласно известным методикам программирования обработка этапов 30 и 32 может перемежаться с обработкой этапа 28, чтобы воспользоваться возможностями (циклами) в обработке этапа 28, которые в противном случае будут потеряны. Следовательно, обработка этапов 30 и 32 может быть обеспечена с относительно небольшими затратами скорости выполнения.
На этапе 34 выполняется команда BXJ завершения последовательности с регистром R14, заданным как операнд.
До выполнения команды BXJ на этапе 34 состояние системы было установлено с указателем на следующий Java-байт-код в потоке 22 Java-байт-кодов, сохраненном в регистре R14, и с указателем на кодовый фрагмент, соответствующий этому следующему Java-байт-коду, сохраненному в регистре R12. Выбор конкретных регистров может варьироваться, при этом ни один из них, один или оба задаются как операнды для команды завершения последовательности или задаются заранее и определяются архитектурой.
Этапы 28, 30, 32 и 34 преимущественно являются программными. Этапы, следующие за этапом 34, преимущественно являются аппаратными и выполняются без отдельных идентифицируемых программных команд. На этапе 36 аппаратные средства определяют, активен ли аппаратный транслятор 6 байт-кодов. Это реализуется посредством считывания значений флажков регистров для определения наличия и включенного состояния аппаратного транслятора 6 байт-кодов. Возможны также другие механизмы определения наличия активного аппаратного транслятора 6 байт-кодов.
Если аппаратный транслятор 6 байт-кодов присутствует и включен, то обработка переходит к этапу 38, на котором управление передается аппаратному транслятору 6 байт-кодов вместе с содержимым регистра R14, определяющим указатель байт-кода на байт-код в потоке 22 байт-кодов, который аппаратный транслятор 6 байт-кодов должен попытаться выполнить как свой следующий байт-код. После этого действие кодового фрагмента 26 заканчивается.
Альтернативно, если на этапе 36 определено, что аппаратный транслятор 6 байт-кодов отсутствует или он отключен, обработка переходит к этапу 40, на котором осуществляется переход в собственном коде ARM-команд, чтобы начать исполнение данного кодового фрагмента в программном интерпретаторе команд, который указан адресом, хранимым в регистре R12. Следовательно, инициируется быстрое выполнение следующего кодового фрагмента, что обеспечивает преимущество в скорости обработки.
На фиг.4 более подробно показан конкретный кодовый фрагмент. Данный пример является Java-байт-кодом прибавления целого числа с символьным обозначением iadd.
Первая собственная ARM-команда использует указатель байт-кода в регистре R14, увеличенный на единицу, для считывания следующего значения байт-кода (команда прибавления целого числа не имеет каких-либо последующих операндов байт-кода и поэтому следующий байт-код будет следовать сразу за текущим байт-кодом). Указатель байт-кода в регистре R14 также обновляется посредством данного значения, увеличенного на единицу.
Вторая и третья команды служат для извлечения из стека двух значений целочисленных операндов, которые должны быть сложены.
Четвертая команда использует то, что в противном случае было бы потерянным циклом обработки из-за взаимоблокировки регистра на регистре R0, чтобы извлечь значение адреса кодового фрагмента для следующего байт-кода, хранимого в регистре R4, и сохранить этот адрес в регистре R12. Регистр Rexc используется для хранения базового указателя на начало таблицы указателей 24.
Пятая команда выполняет целочисленное сложение, заданное Java-байт-кодом.
Шестая команда записывает результат Java-байт-кода обратно в стек.
Последняя команда представляет собой команду BXJ завершения последовательности, заданную операндом R12. Регистр R12 сохраняет адрес фрагмента ARM-кода, который необходим для программной интерпретации следующего Java-байт-кода, если бы потребовалась программная интерпретация. Выполнение команды BXJ определяет, имеется ли включенный аппаратный транслятор 6 байт-кодов. Если он имеется, то управление переходит к аппаратному транслятору 6 байт-кодов вместе с операндом, сохраненным в регистре R14, задающем адрес следующего байт-кода. Если активный аппаратный транслятор 6 байт-кодов отсутствует, то начинается выполнение кодового фрагмента для следующего байт-кода, указанного значением адреса в регистре R12.
На фиг.5 схематически изображена система 42 обработки данных, аналогичная показанной на фиг.1, за исключением того, что в данном случае не предусмотрено аппаратного транслятора 6 байт-кодов. В этой системе флажок 21 всегда показывает, что выполняются ARM-команды, и попытки ввести выполнение Java-байт-кода с командой BXJ всегда рассматриваются, как если бы аппаратный транслятор 6 байт-кодов был отключен, не обращая внимания на флажок 20.
Фиг.6 иллюстрирует алгоритм обработки, выполняемой системой 42 при выполнении Java-байт-кода. Эта процедура аналогична обработке по фиг.3 в том, что используется такой же код программного интерпретатора, за исключением того, что в данном случае, когда выполняется команда BXJ завершения последовательности, всегда отсутствует возможность аппаратной поддержки байт-кодов и, соответственно, обработка всегда продолжается переходом к выполнению кодового фрагмента, указанного посредством R12 в качестве кодового фрагмента для следующего Java-байт-кода.
Понятно, что программный интерпретатор команд в данном случае реализован в виде собственных ARM-команд. Программный интерпретатор команд (и другой вспомогательный код) может быть предусмотрен в виде отдельного компьютерного программного продукта. Этот компьютерный программный продукт может распространяться на носителе, например дискете или компакт-диске, или может загружаться динамически через сетевое соединение. В контексте встроенных приложений обработки, для которых особенно пригодно настоящее изобретение, программный интерпретатор команд может быть предусмотрен в виде программ, зашитых в ПЗУ или в каком-либо другом устройстве долговременного хранения программ во встроенной системе.
На фиг.7 показана взаимосвязь между Java-байт-кодами и операциями обработки, которые они задают. Как видно из фиг.7, 8-разрядные Java-байт-коды обеспечивают 256 возможных отличающихся значений байт-кодов. Первым 203 из этих Java-байт-кодов соответствуют фиксированные связи, как определено стандартом Java, с соответствующими операциями обработки, например операцией iadd, описанной выше. Последние два Java-байт-кода, а именно 254 и 255, определены в спецификации виртуальной машины Java как определяемые конкретной реализацией. Следовательно, реализация Java может свободно назначать фиксированные связи этим байт-кодам. Альтернативно, реализация Java может выбрать их обработку как имеющих программируемые связи. Jazelle определяет для этих байт-кодов фиксированные связи. Между значениями байт-кодов 203 и 253 включительно можно задать программируемые связи по желанию пользователя. Они обычно используются для обеспечения связей между байт-кодами и операциями обработки, например быстрыми байт-кодами, которые решаются во время выполнения программы (см. спецификацию виртуальной машины Java, авторы Tim Lindholm, Frank Yellin, издательство Addison Wesley, ISBN 0-201-63452-Х).
На фиг.7 ясно видно, что хотя методики аппаратной ускоренной интерпретации хорошо подходят для работы с фиксированными связями, они менее пригодны для работы с программируемыми связями. Хотя все программируемые связи можно обрабатывать с использованием программных методик интерпретации, например интерпретации релевантных байт-кодов, подлежащих представлению посредством соответствующих кодовых фрагментов, эта обработка может быть медленной для байт-кодов, которые в некоторых случаях являются критичными для производительности.
На фиг.8 показана одна форма программируемой трансляционной таблицы. Эта программируемая трансляционная таблица 100 реализована в форме ассоциативной памяти (САМ). Подлежащий трансляции байт-код вводится в массив соответствия 102 САМ. Если этот массив 102 содержит совпадающий элемент байт-кода, то формируется совпадение, которое вызывает вывод значения, задающего соответствующую операцию, т.е.
если в таблице САМ имеется совпадающий элемент байт-кода, то аппаратные средства используют задающий операцию код для определения операции, подлежащей выполнению в аппаратных средствах, выполняют эту операцию и переходят к следующему байт-коду,
если же в таблице САМ нет совпадающего элемента байт-кода, то данный байт-код рассматривается как не поддерживаемый аппаратно и вызывается его кодовый фрагмент.
В данном примере задающими операцию значениями являются 4-разрядные значения, а элемент САМ, который обусловил данное совпадение, соответствует байт-коду bc6. Как будет понятно из фиг. 7, все байт-коды, которые могут подвергнуться такой программируемой трансляции, имеют два старших разряда "1" и, соответственно, только 6 младших разрядов байт-кода должно быть введено в массив 102.
Программируемая трансляционная таблица 106 в данном примере содержит 8 элементов. Количество имеющихся элементов может варьироваться в зависимости от объема аппаратных ресурсов, которые желательно выделить в данной задаче. В некоторых примерах может быть предусмотрено только четыре элемента, в то время как в других может быть десять элементов. Можно также обеспечить элемент для каждого возможного байт-кода с программируемой связью.
Понятно, что если имеющиеся ресурсы программируемого отображения сначала заполняются наиболее критичной трансляцией, то менее критичные трансляции могут быть подвергнуты программной интерпретации. Обеспечение программного интерпретатора в комбинации с программируемой трансляционной таблицей позволяет обеспечить конфигурацию системы и программирование таблицы без необходимости знать, сколько имеется элементов таблицы, поскольку при переполнении таблицы требуемые трансляции будут перехвачены и выполнены программным интерпретатором.
На фиг.9 изображен второй пример программируемой трансляционной таблицы 104. В этом примере трансляционная таблица реализована в форме памяти с произвольным доступом (ОЗУ), где подлежащий трансляции байт-код должен вводиться в декодер 106, который рассматривает байт-код в качестве адреса к массиву 108 ОЗУ 4-разрядных слов, каждое из которых представляет задающий операцию код. В этом случае задающий операцию код будет всегда найден для данного байт-кода. В результате этот тип таблицы использует один дополнительный задающий операцию код, который задает "вызвать кодовый фрагмент для данного байт-кода".
На фиг.10 представлен алгоритм, иллюстрирующий инициализацию и конфигурацию аппаратного интерпретатора программируемого отображения, имеющего форму, как в примере на фиг.8. На практике различные части операций, проиллюстрированных данным алгоритмом, выполняются, соответственно, программными командами инициализации и аппаратными средствами, реагирующими на эти команды.
На этапе 110 выполняется команда инициализации таблицы, которая служит для сброса всех существующих элементов таблицы и установки указателя на верхний элемент таблицы. После этого можно выполнить код инициализации для загрузки отображений в трансляционную таблицу с использованием программных команд, таких как команды загрузки регистра сопроцессора. Различные формы этих команд загрузки таблицы могут изменяться в зависимости от конкретных обстоятельств и среды. Система аппаратного интерпретатора программируемого отображения отвечает на эти команды посредством приема значения программной команды, например Java-байт-кода, и значения операции, которое должно быть связано с ним, на этапе 112. На этапе 114 аппаратное средство перехвата неподдерживаемой операции проверяет, поддерживается ли значение программируемой операции этим аппаратным интерпретатором программируемого отображения. Различные аппаратные интерпретаторы программируемого отображения могут поддерживать различные наборы значений операций и при этом могут быть обеспечены собственными специфическими аппаратными средствами перехвата. Аппаратное средство перехвата может быть относительно простым, если конкретной системе, например, известно, что она поддерживает значения операций 0, 1, 2, 3, 4, 5, 6, 7, 8, 10, но не 9. Аппаратный компаратор на этапе 114 может сравнивать значение операции на равенство со значением 9 и при обнаружении 9 отклонять программирование посредством направления обработки к этапу 116.
Допустим, что этап 114 показывает, что данное значение операции поддерживается, тогда на этапе 118 выполняется проверка, чтобы определить, был ли уже достигнут конец программируемой таблицы отображений. Если программируемая таблица отображений уже полна, обработка снова переходит к этапу 116 без добавления нового отображения. Обеспечение этапа 118 в аппаратных средствах означает, что вспомогательный код может стремиться запрограммировать программируемую таблицу отображений, не зная, сколько имеется элементов, и при этом аппаратные средства просто отклоняют переполняющие элементы. Следовательно, программист должен разместить наиболее критичные отображения в начале программирования таблицы, чтобы гарантировать, что они попадут в имеющиеся в наличии слоты. Исключение необходимости для вспомогательного кода знать, сколько имеется программируемых слотов, означает, что один набор вспомогательных кодов может работать на множестве платформ.
Допустим, что таблица имеет свободный элемент, тогда новое отображение записывается в этот элемент на этапе 120, и на этапе 122 указатель таблицы перемещается вперед.
На этапе 116 система проверяет наличие других значений программных команд, которые должны быть запрограммированы в программируемой таблице отображений. Этап 116 обычно является программным, на котором вспомогательный код стремится запрограммировать столько отображений, сколько потребуется во время инициализации системы.
В случае инициализации таблицы ОЗУ, как показано на фиг.9, процесс, описанный выше для фиг.10, можно модифицировать следующим образом:
на этапе 110 таблица сбрасывается путем установки всех элементов массива 108 по фиг.8 в "вызвать фрагмент байт-кода для данного байт-кода", вместо того, чтобы устанавливать массив 102 по фиг.8 таким образом, чтобы каждый элемент не совпадал ни с одним байт-кодом;
на этапе 110 отсутствует указатель трансляционной таблицы, подлежащий инициализации;
этап 118 отсутствует, потому что отсутствует указатель трансляционной таблицы;
этап 120 становится "записать значение операции в элемент таблицы, определенный значением программной команды", и
этап 122 отсутствует, потому что отсутствует указатель трансляционной таблицы.
Фиг.11 иллюстрирует часть конвейера обработки, которая может использоваться для интерпретации Java-байт-кода. Конвейер обработки 124 включает в себя стадию трансляции 126 и стадию Java-декодирования 128. Следующая стадия 130 может принимать множество различных форм в зависимости от конкретной реализации.
Слова из потока Java-байт-кодов загружаются поочередно в две половины переключающегося буфера 132. Мультиплексор 133 обычно выбирает текущий байт-код и его операнды из переключающегося буфера 132 и передает его через мультиплексор 137 в регистр-защелку 134. Если переключающийся буфер 132 пуст, потому что конвейер был освобожден или по другой причине, то мультиплексор 135 выбирает правильный байт-код непосредственно из входящего слова потока Java-байт-кодов и передает его в регистр-защелку 134.
Первый цикл декодирования байт-кода выполняется декодером 146 первого цикла, оперирующим с байт-кодом в регистре-защелке 134. Чтобы предусмотреть случаи, когда аппаратно-поддерживаемый байт-код имеет операнды, дополнительные мультиплексоры выбирают операнды из переключающегося буфера 132 и передают их в декодер 146 первого цикла. Эти мультиплексоры не показаны на чертеже, и они идентичны мультиплексорам 133. Обычно декодер 146 первого цикла имеет менее жесткие временные требования для ввода операндов, чем для ввода байт-кодов, так что для операндов не требуется обходной путь, подобный тому, который обеспечивают мультиплексоры 135 и 137 и регистр-защелка 134.
Если переключающийся буфер 132 содержит недостаточно байтов операндов для байт-кода в регистре-защелке 134, то декодер 146 первого цикла простаивает, пока не будет получено достаточно байт операнда.
Декодер 146 первого цикла выдает ARM-команду (или набор процессорного ядра, управляющий сигналами, представляющими ARM-команду), которая передается на последующую конвейерную стадию 130 через мультиплексор 142. Второй выходной сигнал представляет собой задающий операцию код, который записан в регистр-защелку 138 через мультиплексор 139. Задающий операцию код содержит разряд 140, который задает, является ли данный байт-код одноцикловым байт-кодом.
В следующем цикле следующий байт-код декодируется декодером 146 первого цикла, как было описано выше. Если бит 140 показывает, что это одноцикловый байт-код, то этот байт-код декодируется и контролирует последующую конвейерную стадию 130, как было описано ранее.
Если бит 140 вместо этого показывает, что это многоцикловый байт-код, то декодер 146 первого цикла простаивает, и многоцикловый или транслированный декодер 144 декодирует задающий операцию код в регистре-защелке 138 для получения ARM-команды (или набора сигналов управления процессорным ядром, которые представляют ARM-команду), которую мультиплексор 142 передает на следующую конвейерную стадию 130 вместо соответствующего выходного сигнала декодера 146 первого цикла. Многоцикловый или транслированный декодер также формирует дополнительный задающий операцию код, который записывается в регистр-защелку 138 через мультиплексор 139, снова вместо соответствующего выходного сигнала декодера 146 первого цикла. Этот дополнительный задающий операцию код также содержит разряд 140, который показывает, является ли эта ARM-команда последней для многоциклового байт-кода. Многоцикловый или транслированный декодер 144 продолжает генерировать следующие ARM-команды, как было описано выше, до тех пор, пока разряд 140 не покажет, чтобы была сформирована последняя ARM-команда, после чего декодер 146 первого цикла выходит из простоя и формирует первую ARM-команду для следующего байт-кода.
Описанный выше процесс можно модифицировать тремя разными способами, когда необходимо транслировать байт-код в регистре-защелке 134. Во-первых, байт-код извлекается из переключающегося буфера 132 мультиплексором 133 и транслируется транслятором 136 байт-кодов, с формированием при этом задающего операцию кода, который записывается в регистр-защелку 138 через мультиплексор 139. Этот задающий операцию код имеет разряд 140, установленный для индикации того, что последняя ARM-команда не была сформирована для текущего байт-кода, так что мультиплексор 142 и мультиплексор 139 будут выбирать выходные сигналы многоциклового или транслированного декодера 144 вместо декодера 146 первого цикла на первом цикле транслированного байт-кода.
Во-вторых, многоцикловый или транслированный декодер 144 генерирует все ARM-команды, подлежащие передаче на следующую конвейерную стадию 130 и соответствующие им дополнительные задающие операцию коды для записи обратно в регистр-защелку 138, вместо того, чтобы формировать их только после первого цикла, как это было бы для байт-кода, который не требует трансляции.
В-третьих, если байт-код был записан прямо в регистр-защелку 134 через мультиплексор 135 и поэтому отсутствовал в переключающемся буфере 132 и не мог быть транслирован транслятором 136 байт-кодов в предыдущем цикле, то декодер 146 первого цикла подает сигнал транслятору 136 байт-кодов, что он должен перезапуститься и простаивать в течение цикла. Этим гарантируется, что, когда декодер 146 первого цикла выходит из простоя, регистр-защелка 138 хранит действительный задающий операцию код для данного транслированного байт-кода.
На фиг.11 видно, что обеспечение стадии конвейерной трансляции позволяет эффективно скрыть или свернуть в конвейер обработку, необходимую для этапа программируемой трансляции, так как помещенные в буфер команды можно транслировать заранее и направить потоком в остальную часть конвейера, как это требуется.
На фиг.11 видно, что в данном примерном варианте осуществления аппаратный интерпретатор фиксированного отображения можно рассматривать как сформированный, в основном, посредством декодера 146 первого цикла и многоциклового или транслированного декодера 144, работающего в режиме, в котором он декодирует многоцикловые байт-коды, которые были подвергнуты декодированию первого цикла декодером 146 первого цикла. Аппаратный интерпретатор программируемого отображения в данном примере можно рассматривать как сформированный посредством транслятора 136 байт-кодов и многоциклового или транслированного декодера 144, который в данном случае срабатывает после трансляции программируемого байт-кода. Аппаратный интерпретатор фиксированного отображения и аппаратный интерпретатор программируемого отображения могут быть обеспечены самыми различными путями и могут совместно использовать значительную часть общих аппаратных средств, сохраняя при этом свои отличающиеся с абстрактной точки зрения функции. Все эти различные возможности подпадают под объем предложенных методик.
На фиг.12 показаны два 32-разрядных командных слова 200, 202, которые распространяются на границу 204 страницы виртуальной памяти. Это может быть граница страницы объемом 1 килобайт, хотя возможны и другие размеры страницы.
Первое командное слово 200 находится в рамках страницы виртуальной памяти, которая правильно отображена в системе виртуальной памяти. Второе командное слово 202 лежит в пределах страницы виртуальной памяти, которая на этой стадии не отображена в системе виртуальной памяти. Соответственно, двухбайтовая команда 206 переменной длины, первый байт которой находится в командном слове 200 и второй байт - в командном слове 202, будет иметь преждевременное прекращение предварительной выборки, связанное с ее вторым байтом. Обычные средства обработки преждевременного прекращения предварительной выборки, которые, например, поддерживают только команды, выровненные по командным словам, могут быть не способны справиться с этой ситуацией и могут, например, стремиться проанализировать и исправить выборку командного слова 200, содержащего первый байт команды 206 переменной длины, вместо того, чтобы фокусировать внимание на командном слове 202, содержащем второй байт командного слова 206 переменной длины, которое действительно привело к преждевременному прекращению.
На фиг.13 показана часть командного конвейера 208 в системе обработки данных для обработки Java-байт-кодов, которая включает в себя средство для работы с преждевременными прекращениями предварительной выборки такого типа, как показаны на фиг.12. Командный буфер содержит два регистра 210 и 212 командных слов, каждый из которых хранит 32-разрядное командное слово. Каждый из Java-байт-кодов имеет длину 8 бит и сопровождается нулем или большим количеством значений операндов.
Группа мультиплексоров 214 служит для выбора соответствующих байтов из регистров 210 и 212 командных слов в зависимости от текущего положения указателя Java-байт-кода, указывающего адрес первого байта текущей, подлежащей кодированию команды Java-байт-кода.
С каждым регистром 210 и 212 командных слов ассоциированы соответствующие регистры 216, 218 адреса команды и регистры 220 и 222 флажка преждевременного прекращения предварительной выборки. Эти ассоциированные регистры, соответственно, хранят адрес командного слова, к которому они относятся, и показывают, случилось ли преждевременное прекращение предварительной выборки, когда данное командное слово было выбрано из системы памяти. Эта информация передается по конвейеру вместе с самим командным словом, поскольку она обычно необходима дальше по конвейеру.
Мультиплексоры 224, 226 и 228 позволяют при желании обходить устройство входного буфера. Этот тип операции был описан выше. Понятно, что командный конвейер 208 не показывает все признаки ранее описанного командного конвейера, чтобы не усложнять чертеж. Аналогично, описанный ранее командный конвейер не показывает все признаки командного конвейера 208. На практике эта система может содержать комбинацию признаков, показанных на этих двух проиллюстрированных командных конвейерах.
На стадии декодирования байт-кодов в командном конвейере 208 декодер 230 байт-кодов в ответ на, по меньшей мере, Java-байт-код из мультиплексора 224 и, необязательно, на один или два байта операнда из мультиплексоров 226 и 228 формирует отображенную команду (команды) или соответствующие сигналы управления для передачи на следующие стадии конвейера, чтобы выполнить обработку, соответствующую декодированному Java-байт-коду.
Если произошло преждевременное прекращение предварительной выборки такого типа, как на фиг.12, то, несмотря на то, что сам Java-байт-код может быть корректным, следующие за ним значения операндов будут некорректными, и правильная работа не произойдет, если не будет исправлено преждевременное прекращение предварительной выборки. Генератор 232 исключительной ситуации байт-кода в ответ на адреса командных слов из регистров 216 и 218, а также на флажки преждевременного прекращения предварительной выборки из регистров 220 и 222 обнаруживает наличие ситуации, проиллюстрированной на фиг. 12. Если генератор 232 исключительной ситуации байт-кода обнаруживает такую ситуацию, он вынуждает мультиплексор 234 выдать команду или сигналы управления на следующие стадии, сформированные самим генератором исключительной ситуации байт-кода, а не декодером 230 байт-кода. Генератор 232 исключительной ситуации байт-кода в ответ на обнаружение ситуации преждевременного прекращения предварительной выборки по фиг.12 запускает выполнение 32-разрядного фрагмента ARM-кода, эмулирующего Java-байт-код, который был преждевременно прекращен, вместо того чтобы позволить аппаратным средствам интерпретировать этот Java-байт-код. Следовательно, Java-команда 206 переменной длины, которая подверглась преждевременному прекращению предварительной выборки, сама не будет выполняться, а вместо этого будет заменена последовательностью 32-разрядных ARM-команд. ARM-команды, использованные для эмуляции этой команды, вероятно, будут подвергаться преждевременным прекращениям данных при загрузке одного или нескольких байтов операндов, причем эти преждевременные прекращения данных происходят по тем же самым причинам, что и преждевременные прекращения предварительной выборки, происходившие, когда эти байты изначально выбирались как часть второго командного слова 202, и также возможно, что следующие преждевременные прекращения предварительной выборки и данных будут происходить во время исполнения 32-разрядного фрагмента ARM-кода. Все эти преждевременные прекращения происходят во время выполнения ARM-команды и поэтому будут правильно обрабатываться существующими процедурами обработчика исключительной ситуации преждевременного прекращения.
Таким образом, подавляется (т.е. не пропускается через ядро ARM) преждевременное прекращение предварительной выборки, которое произошло после выборки байт-кодов. Вместо этого исполняется последовательность ARM-команд, и любые преждевременные прекращения, произошедшие с этими ARM-командами, будут обрабатываться с использованием существующих средств, пропуская таким образом байт-код, который вызвал проблему. После выполнения эмулирующих ARM-команд, использованных для замены байт-кода с преждевременным прекращением, можно возобновить выполнение байт-кодов.
Если сам байт-код подвергся преждевременному прекращению предварительной выборки, то ARM-команда, помеченная преждевременным прекращением предварительной выборки, передается в остальную часть конвейера ARM. Если и когда она достигает стадии "выполнить" конвейера, она вызовет возникновение исключительной ситуации преждевременного прекращения предварительной выборки: это совершенно стандартный путь обработки преждевременных прекращений предварительной выборки для ARM-команд.
Если от преждевременного прекращения предварительной выборки пострадал не байт-код, а один или несколько его операндов, как показано на фиг.12, то вызывается фрагмент программного кода для этого байт-кода. Любые АРМ-команды, переданные в остальную часть конвейера ARM для вызова кодового фрагмента, не помечаются преждевременным прекращением предварительной выборки и будут нормально выполняться, если и когда они достигнут стадии "выполнить" конвейера.
На фиг.14 проиллюстрировано логическое выражение типа, который может использоваться генератором 232 исключительной ситуации байт-кода для обнаружения типа ситуации, проиллюстрированной на фиг. 12. Помеченная как "Половина 1" половина переключающегося буфера на фиг. 13 (блоки 210, 216, 220 образуют одну половину, а блоки 212, 218, 222 образуют другую половину, как показано штриховыми линиями вокруг этих элементов на фиг.13) в данный момент содержит первое командное слово (200 на фиг.12), и "Половина 2" (другая половина переключающегося буфера) содержит второе командное слово (202 на фиг.12). Пусть РА (Половина 1) означает содержимое любого из блоков 220 и 222 в Половина 1, аналогично для Половина 2.
Тогда индикаторы ситуации, описанной на фиг.12, покажут, что РА (Половина 1) - ложь, РА (Половина 2) - истина, а байт-код и его операнды распространятся на границу между двумя половинами переключающегося буфера. (Тот факт, что существует отмеченная граница страницы, объясняется просто тем, что обычно требуется, чтобы можно было различить два значения РА()).
В предпочтительных решениях, например, в которых каждая половина переключающегося буфера хранит слово и аппаратно-поддерживаемые байт-коды ограничены максимум 2 операндами, формула для определения факта распространения байт-кода плюс его операнды на границу такова:
((число операндов=1) И (bcaddr[1:0]=11))
ИЛИ ((число операндов=2) И ( bcaddr[1]=1)),
где bcaddr - адрес байт-кода. Это позволяет получить логическое выражение, изображенное на фиг.14.
Можно использовать и другие методики идентификации преждевременного прекращения предварительной выборки, такие как команда переменной длины, начинающаяся в пределах заданного расстояния от границы страницы памяти.
На фиг.15 схематически показана структура вспомогательного кода, связанного с интерпретацией Java-байт-кода. Она аналогична описанной выше фигуре, но в данном случае иллюстрирует включение указателей на кодовые фрагменты обработки исключительной ситуации байт-кода, которые запускаются событиями исключительной ситуации байт-кода. Следовательно, каждый Java-байт-код имеет ассоциированный фрагмент ARM-кода, который эмулирует его работу. Кроме того, каждая возможная исключительная ситуация байт-кода имеет ассоциированную часть ARM-кода обработки исключительной ситуации. В проиллюстрированном случае предусмотрено, что процедура 236 обработки преждевременного прекращения предварительной выборки байт-кода запускается после обнаружения описанного выше типа преждевременного прекращения предварительной выборки генератором 232 исключительной ситуации байт-кода. Этот код 236 обработки преждевременного прекращения действует посредством идентификации байт-кода в начале команды переменной длины, которая вызвала его запуск, и затем вызывает соответствующий кодовый фрагмент эмуляции для данного байт-кода в наборе кодовых фрагментов.
На фиг.16 представлен алгоритм, схематически иллюстрирующий работу генератора 232 исключительной ситуации байт-кода и последующую обработку. На этапе 238 определяется, является ли результатом выражения по фиг.14 истина. Если результатом данного выражения является ложь, то процесс заканчивается.
Если этап 238 показал тип ситуации, изображенной на фиг.12, то выполняется этап 246, который инициирует запуск исключительной ситуации преждевременного прекращения предварительной выборки байт-кода генератором 232 исключительной ситуации байт-кода. Генератор 232 исключительной ситуации байт-кода может просто запустить выполнение обработчика 236 преждевременного прекращения предварительной выборки байт-кода ARM-кода. Обработчик 236 преждевременного прекращения на этапе 248 идентифицирует байт-код, который начинает команду переменной длины, а затем на этапе 250 запускает выполнение кодового фрагмента ARM-команд, которые эмулируют этот идентифицированный байт-код.
Описанное выше средство для работы с преждевременными прекращениями предварительной выборки хорошо подходит для ситуаций, в которых имеется четыре или меньшее количество операндов (т.е. всего пять или меньше байт), в противном случае байт-код и его операнды могут переполнить второй буфер. На практике все байт-коды, для которых предпочтительно обеспечить аппаратный механизм ускорения, имеют 0, 1 или 2 операнда, а остальные байт-коды, в основном ввиду их сложности, во всех случаях обрабатываются программными средствами.
На фиг.17 показана операционная система 300 для управления множеством процессов 302, 304, 306 и 308 режима пользователя. Операционная система 300 работает в привилегированном режиме, а другие процессы 302, 304, 306 и 308 работают в режиме пользователя, имеющем меньше прав доступа к параметрам управления конфигурацией системы, чем операционная система 300, работающая в привилегированном режиме.
Как изображено на фиг.17, процессы 302 и 308, соответственно, относятся к различным виртуальным машинам Java. Каждая из виртуальных машин 302, 308 Java имеет собственные конфигурационные данные, состоящие из данных 310, 312 отображения трансляции байт-кодов и данных 314, 316 конфигурационного регистра. Понятно, что на практике предусмотрен один набор аппаратного средства ускорения Java для выполнения обоих процессов 302, 308, но когда эти разные процессы используют аппаратное средство ускорения Java, они оба требуют, чтобы он был сконфигурирован их соответствующими конфигурационными данными 310, 312, 314, 316. Следовательно, когда операционная система 300 переключает выполнение на процесс, использующий аппаратное средство ускорения Java и отличающийся от предыдущего процесса, который использовал это аппаратное средство, аппаратное средство ускорения Java должно быть заново инициализировано и переконфигурировано. Операционная система 300 сама не производит эту повторную инициализацию и переконфигурирование аппаратного средства ускорения Java, а указывает, что это должно быть сделано путем установки индикатора недействительной конфигурации, ассоциированного с аппаратным средством ускорения Java в недействительное состояние.
На фиг.18 схематически изображена система 318 обработки данных, содержащая процессорное ядро 320, имеющее набор собственных команд (например, набор ARM-команд) и ассоциированное аппаратное средство ускорения Java 322. Память 324 хранит компьютерный программный код, который может быть в форме ARM-команд или Java-байт-кодов. Если это Java-байт-коды, то они пропускаются через аппаратное средство ускорения Java 322, которое служит для их интерпретации в поток ARM-команд (или управляющих сигналов, соответствующих ARM-командам), которые могут затем исполняться процессорным ядром 320. Аппаратное средство ускорения Java 322 содержит трансляционную таблицу 326 байт-кодов, которая требует программирования для каждой виртуальной машины Java, для которой желательно выполнять Java-байт-коды. Кроме того, в аппаратном средстве ускорения Java 322 для управления его конфигурацией предусмотрены регистр 328 конфигурационных данных и регистр 330 управления операционной системой. В регистр 330 управления операционной системой включен индикатор действительной конфигурации в форме флажка CV, установка которого показывает, что конфигурация аппаратного средства ускорения Java 322 действительная, а отсутствие установки показывает, что она недействительная.
Аппаратное средство ускорения Java 322, стремясь выполнить Java-байт-код, в ответ на индикатор действительной конфигурации запускает исключительную ситуацию недействительной конфигурации, если индикатор действительной конфигурации соответствует конфигурационным данным для аппаратного средства ускорения Java 322 в недействительной форме. Обработчиком исключительной ситуации недействительной конфигурации может быть процедура ARM-кода, обеспечиваемая аналогично обсуждавшемуся выше обработчику преждевременного прекращения предварительной выборки. В аппаратном средстве ускорения Java 322 обеспечен аппаратный механизм, который устанавливает индикатор действительной конфигурации в форму, показывающую, что конфигурационные данные действительны, когда запускается исключительная ситуация конфигурации, до того, как новые действительные конфигурационные данные будут фактически записаны на свое место. Хотя такая установка индикатора действительной конфигурации до того, как были фактически записаны конфигурационные данные, может показаться алогичной, однако этот подход обеспечивает существенные преимущества, так как позволяет исключить проблемы, которые могут возникать при свопинге процесса частично через установку конфигурационных данных. Процедура исключительной ситуации конфигурации затем устанавливает требуемые конфигурационные данные для виртуальной машины Java, которым она соответствует, посредством записи элементов трансляционной таблицы байт-кодов, как обсуждалось выше, и любых других требующихся значений 328 регистра конфигурационных данных. Код исключительной ситуации конфигурации должен гарантировать, что запись конфигурационных данных будет завершена до того, как будут предприняты любые другие задачи аппаратным средством 322 ускорения Java.
На фиг.19 схематически проиллюстрирована работа операционной системы 300. На этапе 322 операционная система ожидает обнаружения переключения процесса. При обнаружении переключения процесса на этапе 334 определяется, использует ли данный новый процесс аппаратное средство 322 ускорения Java (именуемое также Jazelle, как упоминалось выше). Если аппаратное средство 322 ускорения Java не используется, то обработка переходит к этапу 336, на котором аппаратное средство 322 ускорения Java отключается перед переходом к этапу 339, на котором выполнение передается новому процессу. Если аппаратное средство 322 ускорения Java используется, то обработка переходит к этапу 338, на котором определяется, является ли новый инициируемый процесс таким же, как сохраненный текущий владелец аппаратного средства 322 ускорения Java, зарегистрированный операционной системой 300. Если владелец не изменился (т.е. новый процесс фактически такой же, как и последний процесс, который использовал аппаратное средство 322 ускорения Java), то обработка переходит к этапу 337, на котором аппаратное средство 322 ускорения Java включается перед переходом к этапу 339. Если же новый процесс не является сохраненным текущим владельцем, то обработка переходит к этапу 340, на котором индикатор действительной конфигурации устанавливается с целью индикации того, что текущая конфигурация аппаратного средства 322 ускорения Java недействительна. Это является границей ответственности операционной системы 300 в отношении управления данным изменением конфигурации, и действительное обновление конфигурационных данных оставляется в качестве задачи для аппаратного средства 322 ускорения Java, которое само работает с собственными средствами обработки исключительных ситуаций.
После этапа 340 этап 342 служит для обновления сохраненного текущего владельца новым процессом перед передачей управления выполнением на этап 337, а затем на этап 339.
На фиг.20 показаны операции, выполняемые аппаратным средством 322 ускорения Java. На этапе 344 аппаратное средство 322 ускорения Java ожидает получения байт-кода для выполнения. Когда поступает байт-код, это аппаратное средство проверяет, показывает ли индикатор действительной конфигурации, что конфигурация аппаратного средства 322 ускорения Java действительная, используя этап 346. Если конфигурация действительная, то обработка переходит к этапу 348, на котором выполняется полученный байт-код.
Если конфигурация недействительная, то обработка переходит к этапу 350, на котором аппаратное средство 322 ускорения Java использует аппаратный механизм для установки индикатора действительной конфигурации так, чтобы он показывал, что данная конфигурация действительная. Это можно сделать при желании программной командой в обработчике исключительной ситуации. На этапе 352 запускается исключительная ситуация недействительной конфигурации. Обработчик исключительной ситуации недействительной конфигурации можно реализовать в виде комбинации таблицы указателей для кодовых фрагментов и соответствующих кодовых фрагментов для обработки каждой из затронутых исключительных ситуаций, таких как программная эмуляция команды, преждевременное прекращение предварительной выборки (обе обсуждались выше), как в данном случае, или исключительной ситуации конфигурации.
На этапе 354 выполняется ARM-код, который образует исключительную ситуацию недействительной конфигурации и который служит для записи конфигурационных данных, необходимых для аппаратного средства 322 ускорения Java. Этот ARM-код может быть реализован в виде последовательности записей регистра сопроцессора, чтобы заполнить программируемую трансляционную таблицу 326, а также другие конфигурационные регистры 330. После этапа 354 этап 356 возвращается обратно в программу Java-байт-кодов и снова пытается выполнить первоначальный байт-код.
Если переключение процесса происходит во время этапа 354 или 358, то текущая установка конфигурации может быть сделана недействительной другим процессом, и индикатор действительной конфигурации будет сброшен операционной системой. В процедуре по фиг.20 это приводит к повторному прогону цикла 344-346-350-352-354, т.е. к повторной попытке произвести переконфигурацию сначала. Когда байт-код в конечном итоге действительно исполняется, конфигурация будет гарантировано действительной.
На фиг.21 показана система обработки данных, аналогичная системе, показанной на фиг.1, которая дополнительно содержит подсистему обработки данных с плавающей точкой. Когда происходит необработанная операция с плавающей точкой, подсистема обработки данных с плавающей точкой обеспечивает средства для ее обработки в ARM-коде.
Примером такой подсистемы является система программного эмулятора VFP компании ARM Limited of Cambridge, England. В случае программного эмулятора VFP все операции с плавающей точкой рассматриваются как необработанные операции с плавающей точкой, так как отсутствуют аппаратные средства для выполнения операций с плавающей точкой. Поэтому все операции с плавающей точкой обрабатываются с использованием имеющихся средств для эмуляции поведения VFP в ARM-коде.
В системах такого типа необработанные операции с плавающей точкой точные, то есть момент обнаружения необработанной операции с плавающей точкой совпадает с моментом ее возникновения.
На фиг.22 показана система обработки данных, подобная системе, изображенной на фиг.1 и 21, но дополнительно содержащая регистр операции с плавающей точкой и флажок необработанной операции с плавающей точкой.
Примером такой подсистемы является аппаратная система VFP компании ARM Limited of Cambridge, England. В этом случае только определенные типы операций с плавающей точкой рассматриваются как необработанные операции с плавающей точкой, а остальные обрабатываются аппаратными средствами VFP.
К операциям, которые могут быть необработанными операциями с плавающей точкой, относятся операции следующего класса:
деление на нуль
операции, связанные с NaN
операции, связанные с бесконечностью
операции, связанные с денормализованными числами.
В случае таких систем необработанная операция с плавающей точкой может быть неточной, то есть необработанная операция с плавающей точкой не обязательно обнаруживается в тот же самый момент, когда она возникает.
Необработанная операция VFP происходит, когда сопроцессор VFP отказывается принять команду VFP, которая бы в обычном случае образовывала часть потока ARM-команд, но в присутствии транслятора байт-кодов, показанного на фиг.1, может быть результатом байт-кода, который был транслирован в комбинацию команд ARM и VFP.
В случае, когда необработанная операция VFP происходит как часть потока ARM-команд, средство ARM для обработки необработанной операции VFP должно сгенерировать исключительную ситуацию неопределенной команды и приведен в действие обработчик неопределенной команды, связанный с вектором неопределенной команды.
В случае системы программного эмулятора VFP все операции VFP рассматриваются как необработанные операции VFP и применяется одно и то же средство ARM, генерируется исключительная ситуация неопределенной команды и приводится в действие обработчик неопределенной команды.
Когда необработанная операция VFP происходит как часть потока ARM-команд, обработчик неопределенной команды может определить путем проверки потока команд, что команда, которая вызвала необработанную операцию VFP, была действительно командой VFP, a не каким-либо другим видом неопределенной команды, и поскольку обработчик неопределенной команды работает в привилегированном режиме, он может выдавать требуемые команды сопроцессору для извлечения любого внутреннего состояния, которое ему необходимо, из сопроцессора VFP и завершать требуемую команду в программном обеспечении. Обработчик неопределенной команды использует и команду, идентифицированную в потоке ARM-команд, и внутреннее состояние VFP для обработки необработанной операции.
Во многих реализациях VFP команда, которая вызвала необработанную операцию, может не быть той командой, которая исполнялась, когда была обнаружена необработанная операция. Необработанная операция может быть вызвана командой, которая была выдана раньше и выполнялась параллельно со следующими командами ARM, но которая столкнулась с необработанным состоянием. VFP сигнализирует об этой ситуации отказом принять следующую команду VFP, вынуждая тем самым войти в обработчик неопределенной команды VFP, который может запросить VFP найти исходную причину необработанной операции.
Когда Jazelle интегрировано в систему, содержащую подсистему VFP, применяются следующие условия:
- Java-команды с плавающей точкой транслируются путем выдачи соответствующих команд VFP непосредственно в ядре, с использованием набора сигналов, имеющих прямое соответствие с командами VFP;
- VFP может выдавать сигнал о состоянии необработанной операции, если он встречает необработанную операцию;
- Jazelle перехватывает сигнал необработанной операции, препятствуя его посылке в ядро и не давая обработчику неопределенной команды выполнять, как случилось бы, если бы команда VFP в потоке ARM-команд сигнализировала о необработанной операции. Вместо этого Jazelle формирует исключительную ситуацию VFP Jazelle, которую он обрабатывает вспомогательным кодом VM Jazelle.
Вспомогательный код VM, встретив такую исключительную ситуацию VFP Jazelle, должен выполнить команду VFP "нет операции", т.е. любую команду VFP, которая оставляет состояние Jazelle без изменений, например команду FMRX Rd, FPSCR. Это синхронизирует аппаратные средства VFP с вспомогательным кодом и завершает работу любой операции VFP, указанной регистром операции с плавающей точкой вместе с флажком состояния "необработанная операция", который должен быть установлен в данном случае, как только встретилась необработанная операция. После завершения работы флажок состояния "необработанная операция" сбрасывается.
При таком подходе используется тот факт, что последовательности команд, выдаваемые Jazelle, можно запускать снова, как описано в совместно рассматриваемой заявке на патент Великобритании №0024402,0, поданной 05.10.2000 г., которая включена в настоящее описание в полном объеме в качестве ссылки. Использование способа, описанного в указанном выше источнике информации, вместе с данным способом позволяет перезапустить команду, которая вызвала формирование команды VFP, приведшей к необработанной операции.
На фиг.23 для каждой из Java-операций с плавающей точкой показаны соответствующие команды VFP, выданные транслятором Java-байт-кодов. Следует отметить, что показаны только те команды VFP, которые выданы, транслятор Java-байт-кодов может выдать дополнительную ARM-команду (команды) вместе с командами VFP. Транслятор байт-кодов Jazelle может также выдать дополнительные команды VFP типа «загрузить» и «сохранить» для загрузки или хранения значений с плавающей точкой.
На фиг.24 показана последовательность команд или сигналов, соответствующих командам, которые могли бы быть выданы транслятором байт-кодов Jazelle для последовательности Java-байт-кодов, состоящих из байт-кода 'dmul', за которым следует байт-код 'dcmpg'. Проиллюстрированная последовательность произойдет, если последовательность байт-кода (dmul, dcmpg) должна выполняться в то время, когда регистры двойной точности D0, D1, D2 хранят третий сверху, второй сверху и верхний элементы стека выполнения Java соответственно и когда ожидается, что целочисленный результат последовательности байт-кодов будет помещен в целочисленный регистр R0.
На фиг.25, 27 и 30 проиллюстрированы последовательности операций, когда необработанная операция с плавающей точкой происходит в разные моменты в последовательности транслированных команд. На фиг.25 и 29 показаны последовательности операций, когда необработанная операция с плавающей точкой вызвана командой FMULD. На фиг.27 и 30 показаны последовательности операций, когда необработанная операция с плавающей точкой вызвана операцией FCMPD. На фиг.25 и 27 показана последовательность операций, когда сигнализация о необработанной операции с плавающей точкой неточная. На фиг.29 и 30 показаны последовательности операций, когда сигнализация о необработанной операции с плавающей точкой точная.
Как можно заметить, существует четыре возможные последовательности событий:
1) Фиг.25: Неточное обнаружение необработанной операции; Java-байт-код, сигнализирующий о необработанной операции, не такой, как тот, который ее вызвал.
2) Фиг.27: Неточное обнаружение необработанной операции; Java-байт-код, сигнализирующий о необработанной операции, такой же, как тот, который ее вызвал, несмотря на тот факт, что система использует неточное обнаружение необработанной операции. Это обусловлено тем, что второй Java-байт-код 'dcmpg' выдает 2 команды VFP для одного Java-байт-кода, первая из которых вызывает необработанную операцию, а вторая сигнализирует о ней.
3) Фиг.29: Точное обнаружение необработанной операции; Java-байт-код, который сигнализирует о необработанной операции, такой же, как код, который ее вызвал.
4) Фиг.30: Точное обнаружение необработанной операции; Java-байт-код, который сигнализирует о необработанной операции, такой же, как тот, который ее вызвал, однако неизвестно, какая из двух команд VFP, выданных в результате выполнения байт-кода 'dcmpg', действительно вызвала необработанную операцию и сигнализировала о ней.
Комбинация упомянутого выше способа перезапуска с предложенным способом позволяет правильно обрабатывать все эти возможные последовательности событий.
На фиг.26 и 28 проиллюстрировано состояние регистра операций с плавающей точкой и флажка состояния "необработанная операция" в момент сразу после того, как была вызвана необработанная операция, соответствующее последовательности операций, показанных на фиг.25 и 27 соответственно.
Необходимо также упомянуть совместно рассматриваемые заявки на патент Великобритании 0024399,8, 0024402,0, 0024404,6 и 0024396,4, поданные 05.10.2000 г., а также заявку на патент Великобритании 0028249,1, поданную 20.11.2000 г., и заявку на патент США 09/731060, поданную 07.12.2000 г., в которых также описана система интерпретации Java-байт-кодов. Раскрытие этих совместно рассматриваемых заявок включено в настоящее описание в полном объеме в качестве ссылки.
| название | год | авторы | номер документа |
|---|---|---|---|
| ОБРАБОТКА ДАННЫХ С ИСПОЛЬЗОВАНИЕМ НЕСКОЛЬКИХ НАБОРОВ КОМАНД | 2002 |
|
RU2281547C2 |
| ПЕРЕЗАПУСКАЕМЫЕ ТРАНСЛИРОВАННЫЕ КОМАНДЫ | 2001 |
|
RU2263949C2 |
| ЗАПОМИНАНИЕ ОПЕРАНДОВ СТЕКА В РЕГИСТРЕ | 2001 |
|
RU2271565C2 |
| СОХРАНЕНИЕ/ВОССТАНОВЛЕНИЕ ВЫБРАННЫХ РЕГИСТРОВ ПРИ ТРАНЗАКЦИОННОЙ ОБРАБОТКЕ | 2012 |
|
RU2562424C2 |
| СПОСОБ И СИСТЕМА ДЛЯ УПРАВЛЕНИЯ ВЫПОЛНЕНИЕМ ВНУТРИ ВЫЧИСЛИТЕЛЬНОЙ СРЕДЫ | 2012 |
|
RU2577487C2 |
| ФИЛЬТРАЦИЯ ПРОГРАММНОГО ПРЕРЫВАНИЯ В ТРАНЗАКЦИОННОМ ВЫПОЛНЕНИИ | 2012 |
|
RU2568923C2 |
| БЛОК ДИАГНОСТИКИ ТРАНЗАКЦИЙ | 2012 |
|
RU2571397C2 |
| ВЫПОЛНЕНИЕ ВЫНУЖДЕННОЙ ТРАНЗАКЦИИ | 2012 |
|
RU2549112C2 |
| КОМАНДА НА НЕТРАНЗАКЦИОННОЕ СОХРАНЕНИЕ | 2012 |
|
RU2568324C2 |
| УСТРОЙСТВО И СПОСОБ ОБРАБОТКИ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ НАБОРОВ КОМАНД | 1995 |
|
RU2137183C1 |
Изобретение относится к области обработки данных, более конкретно к обработке необработанных операций в системах, поддерживающих множество наборов команд. Техническим результатом является обеспечение возможности обработки необработанных операций перед эмуляцией первого набора команд. Указанный результат достигается за счет того, что обнаруживают необработанную операцию программной команды из первого набора команд, например Java-байт-кода, запускают эмуляцию упомянутой первой команды с использованием одной или более команд дополнительного набора команд, например ARM-команд, обрабатывают любую последующую необработанную операцию, возникающую во время эмуляции упомянутой команды первого набора команд с использованием средства обработки исключительных ситуаций. Данный подход хорошо подходит для обработки необработанной операции команд переменной длины, которые интерпретируются процессорным ядром, имеющим собственный набор команд фиксированной длины. 3 н. и 57 з.п. ф-лы, 30 ил.
детектор (238) необработанной операции, предназначенный для обнаружения необработанной операции, возникающей во время выполнения программной команды первого набора команд,
обработчик (250) необработанной операции, предназначенный после обнаружения упомянутой необработанной операции для запуска эмуляции упомянутой команды первого набора команд с использованием одной или более команд по меньшей мере одного из упомянутых одного или более дополнительных наборов команд,
средство (236) обработки исключительных ситуаций, относящееся к упомянутым одному или более дополнительным наборам команд и предназначенное для обработки любой последующей необработанной операции, возникающей во время эмуляции упомянутой команды первого набора команд.
(i) если необработанная операция возникла до начала выполнения последней операции в упомянутой последовательности, то логическое средство перезапуска перезапускает выполнение на первой операции в упомянутой последовательности, и
(ii) если необработанная операция возникла после начала выполнения последней операции в последовательности, то логическое средство перезапуска перезапускает выполнение на следующей команде после упомянутой последовательности.
обнаруживают (238) необработанную операцию, возникающую во время выполнения программной команды первого набора команд,
после обнаружения упомянутой необработанной операции запускают эмуляцию (250) упомянутой команды первого набора команд с использованием одной или более команд по меньшей мере одного из упомянутых одного или более дополнительных наборов команд,
обрабатывают любую последующую необработанную операцию, возникающую во время эмуляции упомянутой команды первого набора команд, с использованием средства обработки исключительных ситуаций, относящегося к упомянутым одному или более дополнительным наборам команд.
(i) если необработанная операция произошла до начала выполнения последней операции в упомянутой последовательности, то логическое средство перезапуска перезапускает выполнение на первой операции в упомянутой последовательности, и
(ii) если необработанная операция произошла после начала выполнения последней операции в упомянутой последовательности, то логическое средство перезапуска перезапускает выполнение на следующей команде после упомянутой последовательности.
логическое средство обработчика (250) необработанной операции, предназначенное после обнаружения необработанной операции, возникающей во время выполнения команды первого набора команд, для запуска эмуляции упомянутой команды, которая вызвала упомянутую необработанную операцию, с использованием одной или более команд по меньшей мере одного из упомянутых одного или более дополнительных наборов команд,
логическое средство (236) обработки исключительных ситуаций, относящееся к упомянутым одному или более дополнительным наборам команд и предназначенное для обработки любой последующей необработанной операции, возникающей во время эмуляции упомянутой команды первого набора команд.
устройство обработки данных выполнено с возможностью генерирования последовательности одного или более наборов выходных сигналов транслятора, соответствующих командам одного из множества наборов команд, чтобы представить по меньшей мере одну команду из упомянутого множества наборов команд, причем каждая последовательность такова, что никакого изменения не вносится во входные переменные до тех пор, пока не будет выполнена последняя операция в последовательности, и
после возникновения необработанной операции во время выполнения последовательности операций, представляющих по меньшей мере одну команду из упомянутого множества наборов команд,
(i) если необработанная операция произошла до начала выполнения последней операции в последовательности, то логическое средство перезапуска перезапускает выполнение на первой операции в упомянутой последовательности, и
(ii) если необработанная операция произошла после начала выполнения последней операции в последовательности, то логическое средство перезапуска перезапускает выполнение на следующей команде после упомянутой последовательности.
| US 6021265 А, 01.02.2000 | |||
| СПЕЦИАЛИЗИРОВАННЫЙ ПРОЦЕССОР | 1995 |
|
RU2147378C1 |
| Устройство выборки команд процессора | 1986 |
|
SU1410028A1 |
| US 5740461 A, 14.04.1998. | |||
