Язык ассемблера - стековая машина

Question

В свободное время я изучаю ассемблер, чтобы стать лучшим разработчиком.

Я понимаю разницу между машинами на основе стека и машинами на основе регистров на концептуальном уровне, но мне интересно, как на самом деле реализованы машины на основе стека. Если виртуальная машина, например JVM или .NET работает на архитектуре на основе регистров, например x86 или x64, то он должен использовать регистры на уровне сборки (насколько мне известно). Я явно что-то здесь упускаю. Поэтому я не уверен в различии на языке ассемблера.

Я читал статьи здесь, например. Машина на основе стека зависит от машины на основе регистра? , а также от Википедии, но я не думаю, что они отвечают на мой вопрос напрямую.

Answer 1

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

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

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

В: Так почему же косвенность? A: Переносимость - набор команд стекового компьютера можно эмулировать на любом количестве различных машин на основе регистров. Это означает, что одно и то же приложение JVM может быть запущено на любом компьютере, на котором есть интерпретатор, поэтому старый слоган Java «Пишите один раз, запускайте где угодно»

Answer 2

Для справки: Burroughs B5000 и Inmos Transputer были стековыми машинами. DEC PDP11 имел такие гибкие режимы адресации, что его можно было использовать в качестве стекового компьютера.Я думаю, что Лилит Никлауса Вирта , возможно, была стековой машиной (более 20 лет назад, мой разум ускользает: -)

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

Инструкции могут загружать немедленные (постоянные) значения в стек или загружать / сохранять в памяти.

Так что их не было add.w r0, r1, r5 или add.w eax, [#fe34].Было add.w.

Так что пример (не совсем точный, он был более сложный) последовательности ассемблера может быть

loadstack 0xfe34   -- got fe34 onto stack
loadstackindirect  -- use address on the stack, to load the value at that address
add.w              -- assumes we already have the other operand on the stack
                   -- result back onto the stack

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

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

XMOS теперь продают современный «эквивалент» и нанимают некоторых из тех же людей.

Прошло более 20 лет с тех пор, как я написал Transputer code, поэтому извините за немного расплывчатость.

В системе UCSD Pascal использовалась виртуальная машина, определяемая программным обеспечением, которая быластековая машина.Идея заключалась в том, чтобы сделать что-то переносимое на новые компьютеры, но также простое в написании, легко компилируемом и разумном исполнении.Эта виртуальная машина была определена на собственном диалекте Паскаля.Когда он был перенесен на реальные компьютеры, регистры использовались для хранения указателя стека и, вероятно, для некоторой изобретательности в обработке вершины стека (с помощью регистров), чтобы получить разумную производительность.

Answer 3

тогда он должен использовать регистры на уровне сборки

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

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

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