Tại sao có quá ít trình biên dịch C?

C là một trong những ngôn ngữ được sử dụng rộng rãi nhất trên thế giới. Nó chiếm một tỷ lệ lớn của mã hiện có và tiếp tục được sử dụng cho một lượng lớn mã mới. Nó được người dùng yêu thích, nó được truyền tải rộng rãi đến mức có thể chạy C theo nhiều định nghĩa không chính thức của một nền tảng và được người hâm mộ ca ngợi là ngôn ngữ "nhỏ" với bộ tính năng tương đối sạch.

Vậy tất cả các trình biên dịch ở đâu?

Trên máy tính để bàn, có hai (thực tế) hai : GCC và Clang. Nghĩ về nó trong vài giây có lẽ bạn cũng sẽ nhớ Intel tồn tại. Có một số ít người khác, quá mơ hồ để người bình thường đặt tên và hầu như không bận tâm đến việc hỗ trợ phiên bản ngôn ngữ gần đây (hoặc thường là một tập hợp ngôn ngữ được xác định rõ, chỉ là "tập hợp con"). Một nửa số thành viên của danh sách này là chú thích lịch sử; hầu hết những người còn lại rất chuyên môn và vẫn không thực sự thực hiện toàn bộ ngôn ngữ. Rất ít thực sự có vẻ là nguồn mở.

Scheme và Forth - các ngôn ngữ nhỏ khác được người hâm mộ yêu thích vì nó - có thể có nhiều trình biên dịch hơn người dùng thực tế. Ngay cả một cái gì đó như SML có nhiều cách triển khai "nghiêm túc" hơn so với C. Trong khi thông báo về trình biên dịch C mới (chưa hoàn thành) nhằm xác minh thực sự thấy một số phản hồi khá tiêu cực và các triển khai kỳ cựu đấu tranh để có đủ người đóng góp để bắt kịp C99.

Tại sao? Thực hiện C có khó không? Nó không phải là C ++. Có phải người dùng chỉ đơn giản là có một ý tưởng rất sai lệch về nhóm phức tạp mà nó rơi vào (nghĩa là nó thực sự gần với C ++ hơn Scheme)?

Ngày nay, bạn cần một trình biên dịch C thực sự để trở thành một trình biên dịch tối ưu hóa , đáng chú ý vì C không còn là ngôn ngữ gần với phần cứng, bởi vì các bộ xử lý hiện tại rất phức tạp ( không theo thứ tự , đường ống , siêu thanh , với bộ đệm & TLB phức tạp , do đó cần lập lịch hướng dẫn , v.v ...). Bộ xử lý x86 ngày nay không giống như bộ xử lý i386 của thế kỷ trước, ngay cả khi cả hai đều có thể chạy cùng một mã máy. Xem C không phải là ngôn ngữ cấp thấp (Máy tính của bạn không phải là bài viết nhanh PDP-11) của David Chisnall.

Rất ít người đang sử dụng các trình biên dịch C không tối ưu hóa ngây thơ như tinycc hoặc nwcc , vì chúng tạo ra mã chậm hơn nhiều lần so với các trình biên dịch tối ưu hóa có thể cung cấp.

Mã hóa một trình biên dịch tối ưu hóa là khó khăn. Lưu ý rằng cả GCC và Clang đều tối ưu hóa một số biểu diễn mã "trung lập ngôn ngữ nguồn" (Gimple cho GCC, LLVM cho Clang). Sự phức tạp của một trình biên dịch C tốt không nằm trong giai đoạn phân tích cú pháp!

Cụ thể, việc tạo một trình biên dịch C ++ không khó hơn nhiều so với tạo một trình biên dịch C: phân tích C ++ và chuyển đổi nó thành một số biểu diễn mã nội bộ rất phức tạp (vì đặc tả C ++ rất phức tạp), nhưng được hiểu rõ, nhưng các phần tối ưu hóa thậm chí còn nhiều hơn phức tạp (bên trong GCC: tối ưu hóa trung cấp, trung lập ngôn ngữ nguồn và bộ xử lý đích, tạo thành phần lớn trình biên dịch, phần còn lại được cân bằng giữa các giao diện người dùng cho một số ngôn ngữ và back-end cho một số bộ xử lý). Do đó, hầu hết các trình biên dịch C tối ưu hóa cũng có thể biên dịch một số ngôn ngữ khác, như C ++, Fortran, D, ... Các phần cụ thể C ++ của GCC chiếm khoảng 20% ​​trình biên dịch ...

Ngoài ra, C (hoặc C ++) được sử dụng rộng rãi đến mức mọi người mong đợi mã của họ có thể biên dịch được ngay cả khi nó không tuân theo chính xác các tiêu chuẩn chính thức, không xác định chính xác đủ ngữ nghĩa của ngôn ngữ (vì vậy mỗi trình biên dịch có thể có cách hiểu riêng của nó). Cũng xem xét trình biên dịch C đã chứng minh CompCert và trình phân tích tĩnh Frama-C , công ty quan tâm đến ngữ nghĩa chính thức hơn của C.

Và tối ưu hóa là một hiện tượng dài hạn : thực hiện một vài tối ưu hóa đơn giản là dễ dàng, nhưng chúng sẽ không làm cho trình biên dịch cạnh tranh! Bạn cần thực hiện rất nhiều tối ưu hóa khác nhau, và sắp xếp và kết hợp chúng một cách khéo léo, để có được một trình biên dịch trong thế giới thực có tính cạnh tranh. Nói cách khác, một trình biên dịch tối ưu hóa trong thế giới thực phải là một phần mềm phức tạp. BTW, cả GCC và Clang / LLVM đều có một số trình tạo mã C / C ++ chuyên dụng nội bộ. Và cả hai đều là những con thú khổng lồ (vài triệu dòng mã nguồn, với tốc độ tăng trưởng vài phần trăm mỗi năm) với cộng đồng nhà phát triển lớn (vài trăm người, làm việc chủ yếu toàn thời gian, hoặc ít nhất là một nửa thời gian).

Chú ý rằng có không có (theo sự hiểu biết của tôi) đa luồng C biên dịch, ngay cả khi một số bộ phận của một trình biên dịch có thể chạy song song (tối ưu hóa ví dụ như trong nội bộ thủ tục, đăng ký phân bổ, kế hoạch giảng dạy ...). Và xây dựng song song với make -jkhông phải lúc nào cũng đủ (đặc biệt là với LTO ).

Ngoài ra, rất khó để được tài trợ cho việc mã hóa trình biên dịch C từ đầu, và một nỗ lực như vậy cần phải kéo dài vài năm. Cuối cùng, hầu hết các trình biên dịch C hoặc C ++ đều là phần mềm miễn phí ngày nay (không còn thị trường cho các trình biên dịch độc quyền mới được bán bởi các công ty khởi nghiệp) hoặc ít nhất là các hàng hóa độc quyền (như Microsoft Visual C ++ ) và là một phần mềm miễn phí gần như được yêu cầu cho các trình biên dịch ( bởi vì họ cần sự đóng góp từ nhiều tổ chức khác nhau).

Tôi rất vui khi nhận được tài trợ để làm việc trên trình biên dịch C từ đầu như phần mềm miễn phí, nhưng tôi không đủ ngây thơ để tin rằng điều đó là có thể ngày hôm nay!

Tôi muốn tranh luận về giả định cơ bản của bạn rằng chỉ có một số ít triển khai C.

Tôi thậm chí không biết C, tôi không sử dụng C, tôi không phải là thành viên của cộng đồng C, tuy nhiên, thậm chí tôi biết nhiều hơn so với một vài trình biên dịch mà bạn đề cập.

Đầu tiên và quan trọng nhất, có trình biên dịch có thể lùn hoàn toàn cả GCC và Clang trên máy tính để bàn: Microsoft Visual C. Bất chấp sự xâm nhập mà cả OSX và Linux đã tạo ra trên máy tính để bàn và thị trường mà iOS và Android đã "đánh cắp" cách xa người dùng máy tính để bàn truyền thống trước đây, Windows vẫn là hệ điều hành máy tính để bàn thống trị và phần lớn các chương trình máy tính để bàn Windows có thể được biên dịch bằng các công cụ của Microsoft.

Theo truyền thống, mỗi nhà cung cấp hệ điều hành và mọi nhà cung cấp chip đều có trình biên dịch riêng. Microsoft, với tư cách là nhà cung cấp hệ điều hành, có Microsoft Visual C. IBM, vừa là nhà cung cấp hệ điều hành vừa là nhà cung cấp chip, có XLC (là trình biên dịch hệ thống mặc định cho AIX và trình biên dịch có cả AIX và i / OS được biên dịch) . Intel có trình biên dịch riêng. Sun / Oracle có trình biên dịch riêng trong Sun Studio.

Sau đó, có các nhà cung cấp trình biên dịch hiệu năng cao như PathScale và Nhóm Portland, có trình biên dịch (và thư viện OpenMP) được sử dụng để đánh số.

Mars kỹ thuật số vẫn còn trong kinh doanh. Tôi tin rằng Walter Bright có sự khác biệt duy nhất là người duy nhất trên hành tinh tự mình tạo ra một trình biên dịch C ++ chất lượng sản xuất (phần lớn).

Cuối cùng nhưng không kém phần quan trọng, chúng tôi có tất cả các trình biên dịch độc quyền cho các vi điều khiển nhúng. IIRC, có nhiều bộ vi điều khiển được bán hàng năm hơn máy tính để bàn, thiết bị di động, máy chủ, máy trạm và CPU máy tính lớn đã được bán trong toàn bộ lịch sử điện toán kết hợp. Vì vậy, đó chắc chắn không phải là sản phẩm thích hợp.

Một đề cập danh dự được gửi tới TruffleC , một trình thông dịch C (!) Chạy trên JVM (!) Được viết bằng khung trình thông dịch Truffle AST, chậm hơn 7% so với GCC và Clang (bất kỳ tốc độ nào nhanh nhất trên bất kỳ điểm chuẩn cụ thể nào) Trò chơi Điểm chuẩn Ngôn ngữ Máy tính và nhanh hơn cả về vi điểm. Sử dụng TruffleC, nhóm Truffle đã có thể có được phiên bản JRuby + Truffle của họ để thực thi các tiện ích mở rộng Ruby C nhanh hơn so với triển khai C C thực tế!

Vì vậy, đây là 6 triển khai cùng với những triển khai mà bạn đã liệt kê mà tôi có thể đặt tên trên đỉnh đầu mà không hề biết gì về C.

Bạn cần bao nhiêu trình biên dịch?

Nếu chúng có các bộ tính năng khác nhau, bạn tạo ra một vấn đề về tính di động. Nếu chúng được hàng hóa, bạn chọn "mặc định" (GCC, Clang hoặc VS). Nếu bạn quan tâm đến hiệu suất 5% cuối cùng, bạn có điểm chuẩn.

Nếu bạn đang làm ngôn ngữ lập trình hoạt động giải trí hoặc cho mục đích nghiên cứu, thì đó có thể là ngôn ngữ hiện đại hơn. Do đó, sự phổ biến của trình biên dịch đồ chơi cho Scheme và ML. Mặc dù OCaml dường như đang nhận được một số lực kéo cho các mục đích phi học thuật phi đồ chơi.

Lưu ý điều này thay đổi rất nhiều theo ngôn ngữ. Java về cơ bản có chuỗi công cụ Sun / Oracle và GNU. Python có nhiều trình biên dịch khác nhau, không có trình biên dịch nào thực sự được tôn trọng so với trình thông dịch chuẩn. Rust và Go có chính xác một thực hiện mỗi. C # có Microsoft và Mono.

C / C ++ là duy nhất trong số các ngôn ngữ được biên dịch ở chỗ nó có 3 triển khai chính của một đặc tả chung.

Theo quy tắc loại bỏ bất cứ thứ gì không được sử dụng nhiều, mọi ngôn ngữ được biên dịch khác có từ 0 đến 1.

Và tôi nghĩ javascript là lý do duy nhất bạn cần chỉ định 'được biên dịch'.

Vậy ngôn ngữ mục tiêu của bạn là gì?

Trình biên dịch SML thường nhắm mục tiêu C hoặc một cái gì đó như LLVM (hoặc như được thấy trong liên kết của bạn, JVM hoặc JavaScript).

Nếu bạn đang biên dịch C, thì không phải vì bạn đang đi đến JVM. Bạn đang đi đến một cái gì đó tồi tệ hơn C. Tệ hơn nhiều. Và sau đó bạn có thể nhân đôi địa ngục nhỏ đó một loạt lần cho tất cả các nền tảng mục tiêu của bạn.

Và chắc chắn, C không phải là C ++, nhưng tôi muốn nói rằng nó gần với C ++ hơn Scheme. Nó có tập hợp con của tội ác hành vi không xác định (Tôi đang xem kích thước của các loại được xây dựng). Và nếu bạn làm hỏng những chi tiết vụn vặt đó (hoặc thực hiện nó một cách "chính xác" nhưng không ngờ tới) thì bạn có hàng thập kỷ mã hiện có trên các hệ thống quan trọng sẽ cho bạn biết bạn khủng khiếp như thế nào. Nếu bạn làm hỏng trình biên dịch SML, nó sẽ không hoạt động - và ai đó có thể nhận thấy. Một ngày nào đó.