Tại sao C được sử dụng để phát triển trình điều khiển chứ không phải là C#?

Question

thể trùng lặp:
C# driver development?

Tại sao chúng ta sử dụng C để phát triển thiết bị điều khiển chứ không phải C#?

Answer 1

Vì chương trình C# không thể chạy ở chế độ hạt nhân (Ring 0).

Answer 2

Lý do chính là C phù hợp hơn với phát triển cấp thấp (gần phần cứng) so với C#. C được thiết kế như một dạng mã lắp ráp di động. Ngoài ra, nhiều lần nó có thể khó khăn hoặc không an toàn cho C# được sử dụng. Thời gian quan trọng là khi trình điều khiển được chạy ở vòng-0, hoặc chế độ hạt nhân. Hầu hết các ứng dụng không có nghĩa là để chạy trong chế độ này, bao gồm cả thời gian chạy .NET.

Mặc dù về mặt lý thuyết có thể thực hiện, nhiều lần C phù hợp hơn với tác vụ. Một số lý do là kiểm soát chặt chẽ hơn những gì mã máy được sản xuất và được gần gũi hơn với bộ vi xử lý là hầu như luôn luôn tốt hơn khi làm việc trực tiếp với phần cứng.

Answer 3

Vì C# là ngôn ngữ cấp cao và không thể nói trực tiếp với bộ vi xử lý. Mã C biên dịch thẳng vào mã gốc mà một bộ xử lý có thể hiểu được.

Answer 4

C là ngôn ngữ hỗ trợ nhiều hơn cho giao tiếp với các thiết bị ngoại vi khác. Vì vậy, C được sử dụng để phát triển phần mềm hệ thống. Vấn đề duy nhất là người ta cần quản lý bộ nhớ. Đó là cơn ác mộng của nhà phát triển. Trong C#, quản lý bộ nhớ có thể được thực hiện easiy và tự động (có n số khác biệt giữa c và C# , thử googling).

Answer 5

Bỏ qua các hạn chế ngôn ngữ được quản lý của C# một chút, các ngôn ngữ hướng đối tượng, chẳng hạn như C#, thường làm những việc dưới mui xe có thể cản trở khi phát triển trình điều khiển. Phát triển trình điều khiển - thực sự đọc và thao tác các bit trong phần cứng - thường có các ràng buộc thời gian chặt chẽ và sử dụng các thực hành lập trình được tránh trong các loại lập trình khác, chẳng hạn như chờ đợi bận và các con trỏ dereferencing được thiết lập từ các giá trị hằng số nguyên. Trình điều khiển thiết bị thường thực sự được viết trong một hỗn hợp của C và lắp ráp nội tuyến (hoặc sử dụng một số phương pháp khác của hướng dẫn phát hành mà trình biên dịch C thường không sản xuất). Các cơ chế khóa mức thấp một mình (viết bằng lắp ráp) là đủ để làm cho việc sử dụng C# khó khăn. C# có rất nhiều chức năng khóa, nhưng khi bạn đào sâu chúng ở mức luồng. Trình điều khiển cần phải có khả năng chặn các ngắt cũng như các luồng khác để tạo thành một số tác vụ.

Ngôn ngữ hướng đối tượng cũng có xu hướng phân bổ và deallocate (thông qua thu gom rác) nhiều bộ nhớ hơn và hơn. Tuy nhiên, trong trình xử lý ngắt, khả năng truy cập chức năng phân bổ đống của bạn bị hạn chế nghiêm trọng. Điều này là do phân bổ đống có thể kích hoạt bộ sưu tập rác (đắt tiền) và bởi vì bạn phải tránh và đối phó với cả mã ngắt lẫn mã không gián đoạn cố gắng phân bổ cùng một lúc. Không có nhiều hạn chế được đặt trên mã này, đầu ra của trình biên dịch và trên bất kỳ thứ gì đang quản lý mã (VM hoặc có thể được biên dịch nguyên bản và chỉ sử dụng các thư viện), bạn có thể sẽ gặp phải một số lỗi rất lạ.

Ngôn ngữ được quản lý phải do một người nào đó quản lý. Quản lý này có thể dựa vào một hệ điều hành cơ bản hoạt động. Điều này tạo ra một vấn đề khởi động để sử dụng mã được quản lý cho nhiều trình điều khiển (nhưng không phải tất cả).

Hoàn toàn có thể viết trình điều khiển thiết bị trong C#.Nếu bạn đang lái một thiết bị nối tiếp, chẳng hạn như thiết bị GPS, thì nó có thể tầm thường (mặc dù bạn sẽ sử dụng chip UART hoặc trình điều khiển USB ở đâu đó thấp hơn, có thể được viết bằng C hoặc lắp ráp) vì nó có thể được thực hiện như một ứng dụng. Nếu bạn đang viết một thẻ ethernet (không được sử dụng để khởi động mạng) thì có thể (về lý thuyết) có thể sử dụng C# cho một số phần, nhưng có lẽ bạn sẽ phụ thuộc rất nhiều vào các thư viện được viết bằng các ngôn ngữ khác và/hoặc sử dụng chức năng trình điều khiển vùng người dùng của hệ điều hành.

C được sử dụng cho trình điều khiển vì nó có đầu ra tương đối dự đoán được. Nếu bạn biết một chút lắp ráp cho một bộ vi xử lý bạn có thể viết một số mã trong C, biên dịch cho bộ xử lý đó, và có một dự đoán khá tốt tại những gì lắp ráp cho rằng sẽ như thế nào. Bạn cũng sẽ biết quyết định của những hướng dẫn đó. Không ai trong số họ sẽ làm bạn ngạc nhiên và bắt đầu thu gom rác hoặc gọi một destructor (hoặc hoàn thành).

Answer 6

Đây là sự thật trung thực. Những người có xu hướng giỏi về giao diện phần cứng hoặc phần cứng, không phải là những người lập trình rất tinh vi. Họ có xu hướng dính vào các ngôn ngữ đơn giản như C. Nếu không, các framework sẽ phát triển cho phép các ngôn ngữ như C++ hoặc thậm chí C# được sử dụng ở cấp hạt nhân. Toàn bộ hệ điều hành đã được viết bằng C++ (ECOS). Vì vậy, IMHO, nó chủ yếu là truyền thống.

Hiện tại, có là một số đối số hợp pháp chống lại việc sử dụng các ngôn ngữ phức tạp hơn trong mã yêu cầu như trình điều khiển/hạt nhân. Có khía cạnh hiển thị . Trình biên dịch C# và C++ thực hiện rất nhiều cảnh hậu trường. Một câu lệnh gán vô thưởng vô nhị có thể ẩn một đoạn mã (toán tử ghi đè, thuộc tính). Chi phí của trường hợp ngoại lệ có thể không được hiển thị rõ ràng. Bộ sưu tập rác thải làm cho tuổi thọ của các đối tượng/bộ nhớ không rõ ràng. Tất cả các tính năng làm cho chương trình dễ dàng hơn, cũng là dây để treo cho mình.

Sau đó, có hệ sinh thái bắt buộc cho ngôn ngữ. Nếu các tính năng được yêu cầu kéo vào quá nhiều thành phần, kích thước một mình có thể trở thành một yếu tố. Nếu các nguyên thủy trong ngôn ngữ có xu hướng nặng (vì lợi ích của trừu tượng phần mềm hữu ích), đó là một trình điều khiển gánh nặng và nhân có thể không sẵn sàng mang theo.

Answer 7

Chỉ để xây dựng một chút cho câu trả lời của Darin Dimitrov. Có C# chương trình không thể chạy trong chế độ hạt nhân.

Nhưng tại sao họ không thể?

Trong Patrick Dussud interview cho Đằng sau mã, ông mô tả một nỗ lực đã được thực hiện trong quá trình phát triển Vista để bao gồm CLR ở mức thấp *. Các bức tường mà họ nhấn là CLR mất phụ thuộc thư viện bảo mật hệ điều hành mà lần lượt mất phụ thuộc vào cấp độ giao diện người dùng. Họ không thể giải quyết vấn đề này cho Vista. Ngoại trừ kỳ dị tôi không biết nỗ lực nào khác để làm điều này.

* Lưu ý rằng trong khi "mức thấp" có thể không đủ để có thể viết trình điều khiển trong C# thì ít nhất là cần thiết.