Jakie są motywy kompilacji kodu bajtowego?

Question

Pracuję nad własnym językiem programowania zabawek. Na razie interpretuję język źródłowy z AST i zastanawiam się, jakie korzyści może dać mi kompilacja kodu bajtowego, a następnie jego interpretacja.

Na razie mam trzy rzeczy na uwadze:

• przemierzając setki drzew składnia czasu może być wolniejsze niż bieganie z instrukcjami w tablicy, zwłaszcza jeśli wsparcie tablicy O (1) dostępu losowego (np. przeskakiwanie 10 instrukcji w górę i w dół).
• W typowym środowisku wykonawczym, mam pewne koszty w czasie wykonywania, ponieważ mój AST jest wpisany i ciągle go przechodzę (tj. Mam 10 typów węzłów i muszę sprawdzić, jaki typ mam teraz wykonać). Być może kompilacja do kodu bajtowego bez typu może pomóc w ulepszeniu tego, ponieważ po sprawdzeniu typu i kompilacji, będę miał niepoprawne wartości i kod.
• Kompilacja do kodu bajtowego może zapewnić lepszą przenośność.

Czy moje punkty są prawidłowe? Jakie są inne motywy kompilacji kodu bajtowego?

Answer 1

Szybkość jest głównym powodem; tłumaczenie ustne AST jest po prostu zbyt wolne w praktyce.

Innym powodem użycia kodu bajtowego jest to, że można go w prosty sposób serializować (zapisywać na dysku), dzięki czemu można go dystrybuować. Właśnie to robi Java.

Answer 2

Punkt generowania kodu bajtowego (lub dowolnej innej "łatwo interpretowanej" postaci, takiej jak kod gwintowany) jest w zasadzie wydajnością.

Aby intruder AST mógł zdecydować, co dalej zrobić, musi przejść przez drzewo, sprawdzić węzły, określić typ węzłów, sprawdzić typ argumentów, zweryfikować legalność i zdecydować, który szczególny przypadek AST wyznaczony operator stosuje (mówi "+", ale oznacza 16-bitowe dodawanie lub ciągi konkatenacyjne?), zanim w końcu wykona jakąś akcję.

Jeśli ktoś podejmie ostatnią akcję i wygeneruje jakąś łatwą do interpretacji strukturę, to w czasie "wykonania" tłumacz może skupić się na wykonywaniu czynności bez tego sprawdzania/specjalnego oznaczania.

Inną niedawną wymówką jest to, że jeśli generujesz kod bajtowy dla wielu znanych maszyn wirtualnych (JVM, MSIL, Parrot itp.), Nie musisz nawet kodować interpretera. W przypadku JVM i MSIL można również korzystać z kompilatorów JIT z nimi związanych, a także ze starannego projektowania języka, kompatybilności z ogromnymi bibliotekami, które są prawdziwą atrakcją Java i C#.