Nhược điểm của việc nhắm mục tiêu JVM thay vì x86 là gì?

Question

Tôi đang phát triển một ngôn ngữ mới. Mục tiêu ban đầu của tôi là biên dịch thành x86 bản địa cho nền tảng Windows, nhưng bây giờ tôi nghi ngờ.

Tôi đã thấy một số ngôn ngữ mới nhắm mục tiêu đến JVM (đáng chú ý nhất là Scala và Clojure). Ofcourse nó không thể port mọi ngôn ngữ dễ dàng cho JVM; để làm như vậy có thể dẫn đến những thay đổi nhỏ đối với ngôn ngữ và thiết kế của nó.

Sau khi đặt câu hỏi này, tôi thậm chí còn nghi ngờ nhiều hơn về quyết định này. Bây giờ tôi biết một số đối số JVM "chuyên nghiệp". Câu hỏi ban đầu là: là nhắm mục tiêu các JVM một ý tưởng tốt, khi tạo một trình biên dịch cho một ngôn ngữ mới?

Cập nhật câu hỏi: Nhược điểm của việc nhắm mục tiêu JVM thay vì x86 trên Windows là gì?

Answer 1

Nhắm mục tiêu JVM là một cách tiếp cận khá cố gắng và thử nghiệm. Thực tế là Clojure, Scala, JRuby và many other languages đã thực hiện thành công như vậy sẽ giúp bạn yên tâm.

Tầm nhìn của tôi là JVM có lẽ là mục tiêu tốt nhất cho các ngôn ngữ mới/thử nghiệm, đặc biệt nếu bạn hy vọng đạt được khả năng nền tảng chéo trong khi tận dụng trình biên dịch JIT thực sự tuyệt vời và vô số thư viện rất mạnh .

Có nói rằng, những nhược điểm chính bạn có thể gặp phải nhắm mục tiêu các JVM là theo ý kiến ​​của tôi như sau:

• Thiếu sự hỗ trợ đệ quy đuôi ở cấp bytecode. Có nhiều cách xung quanh việc này (ví dụ: xem biểu mẫu đặc biệt "tái diễn" của Clojure) nhưng nó gây phiền toái cho một số triển khai ngôn ngữ, đặc biệt là các ngôn ngữ chức năng. Có thể cuối cùng sẽ được khắc phục trong các phiên bản tương lai của Java.

• Hơi rõ ràng, nhưng bạn cần cài đặt JVM trên máy khách của mình. Thường không phải là một vấn đề ngày nay, nhưng vẫn còn những trường hợp mà điều này có thể khó khăn.

• Nguyên thủy (int, long, float, vv ..) trong Java hoạt động khác với phần còn lại của hệ thống đối tượng. Một lần nữa bạn có thể làm việc xung quanh điều này nhưng nó là một số rắc rối thêm cho người thực hiện ngôn ngữ.

Một số khả năng hữu ích/liên kết thú vị:

• ASM bytecode analysis and manipulation framework. Đây là một công cụ tuyệt vời, Tôi tin rằng đó là những gì Clojure sử dụng dưới mui xe.

• Clojure source code

Answer 2

Nếu bạn tạo ngôn ngữ cho JVM, bạn cũng có lợi thế lớn là một thư viện lớn nằm dưới chân bạn, có thể dễ dàng sử dụng từ bên trong ngôn ngữ của bạn. Điều này rất có thể không phải là trường hợp nếu bạn biên dịch cho x86. Tôi cho rằng bạn sẽ không làm cho nó có thể bao gồm ví dụ C-tiêu đề bằng ngôn ngữ của bạn mà không có trình phân tích cú pháp C.

Vì lý do này Scala, Groovy và những người khác là một thành công như vậy.

Ở giai đoạn phát triển hiện tại của JVM và với tính năng nâng cao mới cho hỗ trợ ngôn ngữ kịch bản, tôi sẽ nhắm mục tiêu JVM, vì tỷ lệ cược là ngôn ngữ của bạn sẽ được thực thi nhanh hơn với mọi thư viện thời gian chạy mà bạn có thể tạo bản thân bạn.

Answer 3

Bạn chỉ nên nhắm mục tiêu JVM nếu bạn vui khi có phần thời gian chạy của mã hoàn toàn phụ thuộc vào mã của bên thứ ba và yêu cầu người dùng của bạn cài đặt, và, JVM sẽ cung cấp các tính năng đáng kể mà bạn có thể phát triển hợp lý hoặc yêu cầu mọi người mở rộng cho mục đích này (ví dụ: tiêu đề hệ điều hành trong C++), và, bạn hài lòng với JNI làm giao diện của bạn với mã gốc (và do đó, mã được quản lý khác như .NET).

Cuối cùng, nó hoàn toàn phụ thuộc vào tài nguyên có sẵn cho bạn và cách bạn hình dung ngôn ngữ interop. Nếu bạn định sử dụng JVM để cung cấp nhiều tính năng, và bạn hài lòng vì sự tương tác quá đáng sợ, hãy sử dụng nó. Khác, tôi nghĩ bạn nên xem xét lại.

Answer 4

Bạn có thể muốn xem xét nhắm mục tiêu LLVM thay vì JVM. LLVM có thể được sử dụng để nhắm mục tiêu một số kiến ​​trúc, bao gồm x86.

Có nhiều tính di động hơn hỗ trợ CPU đơn giản, nhưng LLVM có thể giúp ích rất nhiều và vẫn cung cấp cho bạn mã gốc, nếu bạn muốn.