Почему виртуальная машина Java была разработана без регистров для хранения промежуточных значений данных? Вместо этого каждая вещь работает на стеке. есть ли какое-либо конкретное преимущество наличия архитектуры на основе стека вместо регистрации?Преимущества архитектуры на основе стека команды JVM
Ява была разработана для переноски с нуля. Но как вы можете сохранить свой байт-код переносимым, если это зависит от того, какие регистры присутствуют на платформе, на которой вы его используете? Особенно учитывая, что изначально он предназначался для запуска (также) на приставках, которые имеют совершенно другую архитектуру процессора от обычных ПК.
Это только время выполнения, что JVM действительно знает доступные регистры и другие аппаратные средства. Тогда компилятор JIT может (и будет) оптимизировать для них, если применимо.
При проектировании виртуальной машины проще разместить стек, а не набор виртуальных регистров. Если у хост-компьютера есть стек, как все они делают, делать нечего, и если у него есть регистры, вы все равно можете использовать их для других вещей: временные и т. Д. Если, с другой стороны, у хост-машины нет регистров , только стек, и вы создаете свою виртуальную машину вокруг регистров, у вас есть серьезные проблемы с реализацией на ваших руках, так как вы должны использовать собственный стек, таким образом, который будет мешать его использованию в качестве виртуального стека.
Я должен уважительно не соглашаться с предыдущими ответами.
Предположение о существовании стека выражений не лучше предположения, чем наличие регистров. Обычно регистрационные машины не могут напрямую выполнять коды операций стека, а стековые машины не могут напрямую выполнять коды операций регистра. Они должны быть сопоставлены.
EJP говорит «Если хост-машина имеет стек, , как все они делают, нет ничего, чтобы сделать». Это ложное утверждение. Предполагая, что все машины имеют стеки, способные выполнять вычисления, показывают путаницу в отношении того, что такое машина стека.
Так что, конечно, более чем «ничего не нужно» для сопоставления кодов операций одной машинной архитектуры с другой. Если вы не используете чип с ускорением ускорения на базе Java, лучше не предполагать этого.
Я не утверждаю, что стоп-машина является хорошим выбором для переносимости. Я говорю, что есть «что-то делать», чтобы отображать инструкции из stack-to-register или register-to-stack. Оба варианта возможны.
Однако много разговоров является академическим. В практика, в 2014 году преобладающая платформа регистрируется.Даже «основанные на стеке» процессоры часто являются мягкими чипами, реализованными в верхней части чипа регистров. См. Спецификацию Java Card 3 и посмотрите на реализации и узнайте, какие процессоры фактически используются. Я оставлю это как упражнение.
Если мы не разрабатываем виртуальную машину для очень конкретной платформы (например, нам было предложено создать JVM, который будет работать только на процессоре GreenSpaces, который я не вижу), тогда я предполагаю, что контекст - это общее приложение, встроенные приложения, телевизионная приставка, контроллеры прошивки, игрушки, даже смарт-карты. Для всего этого я вижу 8-32-разрядные процессоры, такие как ARM, либо используемые, либо доступные. Основная JVM написана на C. C. позволяет создавать интерпретатор с помощью кода виртуального стека или виртуального регистра. В 90-х годах было много дискуссий о Java-процессорах на основе стека, которые напрямую поддерживают коды операций JVM. В 2014 году мы видим эти реализации на аппаратном обеспечении на основе регистров или в качестве дополнительных инструкций, таких как Jazelle (ускорение Java) на ARM926EJ-S, где также имеются регистры и поддержка набора команд ARM.
Для общее приложение, виртуальные машины на основе стека, конечно же, не накладываются на стопки на практике. Эти машины используют первичные инструкции на основе регистров; и операторы стека предназначены для сохранения и восстановления регистров или стека вызовов, а не для выполнения вычислений, логики или ветвления. Стек виртуальных машин в стеке JIT в собственный набор команд машины, будь то набор стека или набора регистров. С 1980 года практически каждая новая архитектура процессора регистрируется, согласно Hennessy And Patterson - «Компьютерная архитектура - количественный подход». Это означает, что регистры-регистры, регистры-память или наборы регистра-немедленного набора команд. Вы не можете добавить 2 значения в стек на машине, у которой нет добавления на основе стека. На x86, ваш стек опкоды основе для операции ADD может трансформироваться из:
push a
push b
add
в машинный код регистра:
mov eax, [addra]
mov ebx, [addrb]
add eax, ebx
Во-вторых, независимо от того, является ли стек поток опкод или рагистрации, JIT может скомпилируйте его в собственный код. Таким образом, выбор модели VM - это просто программная модель. Регистрационные машины так же виртуальны. Они не кодируют какую-либо собственную регистрационную информацию, регистры в кодах операций являются виртуальными символами.
Теперь, когда Java была разработана, мысли касались небольших кодов операций и совместимости с 8-битным процессором. Коды операций на основе стека меньше, чем регистровые коды операций. Так что это имело смысл. Я уверен, что я где-то читал, что это была одна из главных причин, по которой Джеймс Гослинг выбрал для Oak (оригинальное название для Java), помимо простоты. У меня просто нет руки. В этом я согласен с Петером Тёреком.
В виртуальных машинах байт-коды регистров часто используют большой набор виртуальных регистров, требующий больших байт-кодов.На большинстве реальных аппаратных средств регистры обычно кодируются с примерно 3 бит (Intel x86) до 5 бит (Sparc), поэтому плотность может отличаться от VM до VM или CPU до CPU или VM до CPU. Dalvik использует от 4 до 16 бит для представления регистров, тогда как Parrot использовал 8 бит на регистр для всех кодов операций (по крайней мере, в том, что я использовал формат байт-кода v2). Дальвик достигает лучшей средней плотности. Основываясь на моем опыте создания их, сложно построить машину регистрации общего назначения в 8-битном байт-коде, если вы строго придерживаетесь примитивов и не используете небольшой файл регистра. Это может показаться неинтуитивным, но, как правило, один код операции фактически имеет несколько кодировок с разными типами регистров.
Один последний момент: много оптимизации мягкого ядра потенциально выходит из окна, когда JIT входит в изображение.
Основное исключение, которое я принимаю с аргументом, что стековые машины лучше отображают аппаратное обеспечение, заключается в том, что он игнорирует, где работает JVM и/или где идет технология. Вне Chuck Moore я не знаю никого, кто проектировал процессоры на основе стека (IGNITE и GreenSpaces GA144), и большинство новых разработок - это машина для регистрации. Аргументы для стековых машин являются преимущественно академическими. Для каждого 8-битного аргумента процессора стека я могу показать вам несколько регистрационных машин (Hitachi H8 с регистрами, ARM926 с регистрами, Intel 8051) с компилятором C. Вероятнее всего, вы можете писать в Forth на чистом стеке, чем Java. Для новой платформы имеет смысл пойти с дешевым ARM-процессором, где есть компиляторы C, полная JVM и т. Д. Эти команды запускают наборы регистров.
Итак, если то правда? Это имеет значение? Мое мнение, основанное на моем опыте, «не столько, сколько люди думают». Помните, байт-код - это просто промежуточное представление. Чистое интерпретируемое ядро машины часто является ступенчатым камнем, мостом, отказоустойчивым ядром по умолчанию. Конечным пунктом назначения является возможная версия 2 с JITter для собственной производительности. Таким образом, точка зрения, которую придерживаются многие, кто сделал это один или два раза, состоит в том, что имеет смысл держать ядро как можно более простым и перейти к JIT, затратив на это 90% оптимизации. Любое потраченное впустую усилие, настраивающее переработанное ядро, можно рассматривать как преждевременную оптимизацию. Если, с другой стороны, вы не планируете JITTER, или JIT нецелесообразно из-за ограничений памяти, затем оптимизируйте их на виртуальном ядре или реализуйте виртуальную машину на чипе.
Я также вижу здесь некоторую путаницу. В № 2 вы говорите о виртуальных машинах, когда имеете в виду физические процессоры. Я не вижу, где вы объясните, как виртуальная машина на основе регистров может быть (легко) реализована на стеке-процессоре, что является проблемой. Я не вижу, где вы указываете, что не так с моим собственным ответом, хотя вы заявляете, что не согласны с ним. Наконец, я не вижу повода для вас покровительствовать работе тех, кто на самом деле это сделал. – EJP
Если бы я смог проголосовать за это, я бы сразу наградил +50 upvotes. Такое более глубокое знание с установкой фоновой архитектуры с момента создания просто потрясающе для чтения. Хотя, я не мог понять несколько строк между ними, но почта имеет обязательный для чтения контент. Спасибо @mrjoltcola за предоставление такой ценной информации и критики за неправильные части почтительно! –
@EJP - В соответствии с запросом у меня есть обновление, чтобы четко указать, что я не согласен с вашим собственным ответом. Что касается «покровительственной работы тех, кто на самом деле это сделал», я реализовал 3 виртуальных машины с нуля, два из которых доступны с открытым исходным кодом, которые доступны для скачивания, один из которых описан в нескольких книгах О'Рейли и других издатели. Я также изучал, программировал или писал JIT на процессорах Intel x86, Sparc, Motorola, PowerPC, PA-RISC, ARM, MIPS и 8051, поэтому у меня есть общее представление о процессорах. Я не утверждаю, что делал замечательные вещи. Но я едва ли квалифицирую себя тем, кто этого не сделал. – codenheim
Строго говоря, виртуальные регистры не обязательно должны отображаться на физические регистры. Из другого POV аппаратная поддержка стека снова не гарантируется, правильно? – Vlad
ActionScript VM является, например, основанной на регистре. Я думаю, что обоснование такого дизайна не так просто и, в конце концов, сводится к множеству компромиссов, которые дизайнеры Oak (я бы предположил, что они были - до приобретения Sun) по отношению к их конкретному видению применения языка , –
Я предпочитаю интерпретировать исходный вопрос как * преимущества виртуальной машины на основе стека по сравнению с другими средствами для создания виртуальных машин, таких как VM * на виртуальном регистре. Однако, похоже, OP может жить с выбранным ответом (или забыть свою собственную оригинальную мотивацию). – smwikipedia