Соответствие конструкции виртуальной машины ее основному языку программирования.

В качестве фона для побочного проекта я читал о различных конструкциях виртуальных машин, причем JVM, конечно, получила наибольшее распространение в прессе. Я также просмотрел BEAM (Erlang), GHC RTS (что-то вроде виртуальной машины, но не совсем) и некоторые реализации JavaScript. У Python также есть интерпретатор байт-кода, о существовании которого я знаю, но о котором мало читал

. ] Чего я не нашел, так это хорошего объяснения того , почему определенные варианты проектирования виртуальных машин делаются для определенного языка. , JavaScript, Lisp).

Редактировать: В ответ на комментарий с просьбой об уточнении вот пример. JVM использует стековый, а не регистровый автомат, что вызывало большие споры, когда Java впервые представили. Оказалось, что инженеры, разработавшие JVM, сделали это с намерением портировать платформу. y, и преобразование стековой машины обратно в регистровую было проще и эффективнее, чем преодоление несоответствия импеданса, когда было слишком много или слишком мало виртуальных регистров.

Вот еще один пример: для Haskell следует рассмотреть статью Реализация ленивых функциональных языков на стандартном оборудовании: Spineless Tagless G-machine.Это очень отличается от любого другого типа виртуальных машин, о котором я знаю. И на самом деле GHC (главная реализация Haskell) не работает вживую, а используется как промежуточный шаг в компиляции. Пейтон-Джонс перечисляет не менее 8 других виртуальных машин, которые не работали. Я хотел бы понять, почему некоторые виртуальные машины преуспевают, а другие терпят неудачу.