Что недостатками предназначения является JVM вместо x86?
Я разрабатываю новый язык. Моя начальная цель состояла в том, чтобы скомпилировать в собственный x86 для платформы Windows, но теперь я вызываю сомнение.
Я видел, что некоторые новые языки предназначаются для JVM (самый известный Scala и Clojure). Конечно, не возможно портировать каждый язык легко на JVM; сделать так может привести к небольшим изменениям в языке, и это - дизайн.
После того, чтобы ставить этот вопрос я даже сомневался больше об этом решении. Я теперь знаю некоторые "про" аргументы JVM. Исходный вопрос был: действительно ли предназначением является JVM хорошая идея при создании компилятора для нового языка?
Обновленный вопрос: Что недостатками предназначения является JVM вместо x86 в Windows?
4 ответа
Ориентация на JVM - это довольно проверенный и испытанный подход. Тот факт, что Clojure, Scala, JRuby и многие другие языки сделали это успешно, должен дать вам некоторую уверенность.
В целом, я считаю, что JVM, вероятно, является лучшей целью для новых/экспериментальных языков в настоящее время, особенно если вы надеетесь достичь кросс-платформенных возможностей, используя преимущества действительно фантастического JIT-компилятора и множества очень мощных библиотек.
С учетом сказанного, основные недостатки, с которыми вы можете столкнуться при использовании JVM, на мой взгляд, следующие:
Отсутствие поддержки хвостовой рекурсии на уровне байткода. Есть способы обойти это (например, см. специальную форму "recur" в Clojure), но это раздражает некоторые реализации языка, особенно функциональные языки. Вероятно, в конечном итоге это будет исправлено в будущих версиях Java.
Немного очевидно, но вам нужна JVM, установленная на вашем клиенте. Обычно в настоящее время это не проблема, но все еще есть случаи, когда это может быть сложно.
Примитивы (int, long, float и т.д.) в Java ведут себя иначе, чем остальная объектная система. Опять же, это можно обойти, но это дополнительные хлопоты для разработчиков языка.
Некоторые потенциально полезные/интересные ссылки:
ASM bytecode analysis and manipulation framework. Это отличный инструмент, Я считаю, что это то, что использует Clojure под капотом.
Возможно, вы захотите настроить таргетинг на LLVM, а не на JVM. LLVM может использоваться для целевого ряда архитектур, включая x86.
Переносимость - это нечто большее, чем простая поддержка ЦП, но LLVM может очень помочь и, если хотите, предоставить вам собственный код.
. Если вы создаете язык для JVM, у вас также есть большое преимущество, заключающееся в том, что огромная библиотека находится в ваши ноги, которые можно легко использовать на вашем языке. Скорее всего, это не так, если вы компилируете для x86. Я предполагаю, что вы не сможете включить, например, C-заголовки на вашем языке без синтаксического анализатора C.
По этой причине Scala, Groovy и другие пользуются таким успехом.
На текущем этапе разработки JVM и с новым улучшением для поддержки языков сценариев я бы просто нацелился на JVM, потому что вероятность того, что ваш язык будет выполняться быстрее, чем с любой библиотекой времени выполнения, которую вы когда-либо могли создать для себя .
Вы должны нацеливаться на JVM только в том случае, если вы счастливы, что часть времени выполнения вашего кода полностью зависит от стороннего кода и требует, чтобы ваши пользователи устанавливали такие, и , JVM предоставит важные функции, которые вы не можете разумно разработать самостоятельно или попросить людей расширить для этой цели (например, заголовки ОС на C ++), и , вы довольны JNI в качестве интерфейса для собственный код (и, следовательно, другой управляемый код, например .NET).
В конечном итоге это полностью зависит от доступных вам ресурсов и от того, как вы представляете языковое взаимодействие. Если вы собираетесь использовать JVM для предоставления множества функций, и вы счастливы, что взаимодействие было ужасным, тогда используйте его. В противном случае, я думаю, вам следует пересмотреть свое мнение.