Механизм Javascript обычно используется для преобразования байт-кода из исходного кода. Затем байт-код преобразуется в собственный код.
1) Зачем трансформировал байткод?? исходный код, непосредственно преобразующий собственный код, является низкой производительностью? 2) Если исходный код очень прост (например, функция a+b), исходный код, непосредственно преобразующий собственный код, хорош?
Сложность и переносимость.
Преобразование исходного кода в объектный код, будь то байт-код для виртуальной машины или машинный код для реальной машины, — сложный процесс. Байт-код более точно имитирует то, что делают большинство реальных машин, поэтому с ним проще работать: лучше оптимизировать код, чтобы он работал быстрее, преобразовать в машинный код для еще большего ускорения или даже преобразовать в другие форматы. если этого требует ситуация.
Из-за этого обычно оказывается проще написать внешний интерфейс, единственной задачей которого является преобразование исходного кода в байт-код (или какой-либо другой промежуточный язык), и затем серверная часть, которая работает с промежуточным языком: оптимизирует его, выводит машинный код и все такое прочее. Более традиционные компиляторы для таких языков, как C, делали это в течение длительного времени. Java можно считать необычным применением этого принципа: процесс его сборки обычно останавливается на промежуточном представлении (т. е. байт-коде Java), а затем разработчики отправляют это, чтобы JVM могла «завершить работу», когда пользователь ее запускает.
Есть два больших преимущества такой работы, кроме упрощения работы с кодом. Первое большое преимущество заключается в том, что вы можете повторно использовать серверную часть для работы с другими языками. Это не так важно для JavaScript (у которого нет стандартизированной серверной части), но это то, как такие проекты, как LLVM и GCC, в конечном итоге разрастаются, охватывая так много разных языков. Написание внешнего интерфейса — тяжелая работа, но допустим, я сделал, например, внешний интерфейс Lua для внутреннего интерфейса Mozilla JavaScript. Тогда я мог бы подключиться ко всей работе по оптимизации, которую Mozilla вложила в этот бэкэнд. Это экономит мне много работы.
Другое большое преимущество заключается в том, что вы можете повторно использовать внешний интерфейс для работы с большим количеством компьютеров. Это действительно имеет практическое значение для JavaScript. Если бы мне пришлось писать интерпретатор JavaScript, я бы, вероятно, написал свой первый бэкенд для x86 — архитектуры, которую использует большинство ПК, — потому что именно там я, вероятно, занимался разработкой. Но большинство сотовых телефонов не используют архитектуру на основе x86 — в наши дни ARM более распространен, поэтому, если я хочу быстро работать на сотовых телефонах, мне нужно добавить серверную часть ARM. Но я мог бы сделать это, не переписывая весь интерфейс, так что я еще раз сэкономил себе много работы. Если бы я хотел работать на Wii U (или на игровых консолях предыдущего поколения, или на старых компьютерах Mac), то мне понадобился бы бэкенд POWER, но, опять же, я мог бы сделать это без переписывания интерфейса.
Суть в том, что хотя выполнение двух преобразований кажется более сложным, в конечном итоге это оказывается проще. Это одна из тех странных и неинтуитивных вещей, которые иногда всплывают при проектировании программного обеспечения, но преимущества реальны.
