Tại sao một số hệ điều hành xử lý sự kiện được viết bằng asm thay vì c?

17

Câu hỏi của tôi là tại sao ngày nay một số xử lý sự kiện của hệ điều hành vẫn được viết bằng ngôn ngữ hợp ngữ thay vì ngôn ngữ cấp cao hơn như C, khi hạt nhân được viết chủ yếu bằng C?

kernel c assembly

— MAKZ
nguồn

5

"Chủ yếu là trong c" - và đoán phần còn lại là gì? ;)

— goldilocks

@goldilocks nó cũng đang lắp ráp. Nhưng tại sao, trong khi các phần khác là trong c?

— MAKZ

4

Tôi không phải là chuyên gia về nó nhưng có một số điều liên quan đến phần cứng cấp thấp không thể thực hiện được trong C; đây thường là kiến trúc cụ thể. "ASM nội tuyến" thường được sử dụng trong mã C cho mục đích đó, vì vậy, ví dụ foobar()sẽ được xác định, sử dụng lắp ráp nội tuyến, một cách trên một nền tảng và một cách khác trên một nền tảng khác. Điều này giữ cho việc sử dụng asm ở mức tối thiểu, nhưng không thể tránh hoàn toàn.

— goldilocks

Làm thế nào để bạn thiết lập thanh ghi con trỏ bảng mô tả toàn cầu trong C?

— dùng253751

24

Ngôn ngữ trừu tượng hóa việc truy cập vào các thanh ghi CPU và HĐH khi xử lý các sự kiện phải lưu bối cảnh, do đó, nó cần truy cập vào các thanh ghi tại điểm của sự kiện, do đó phá vỡ thông số C.

— Khôngnếpnhăn
nguồn

Đây thực sự là lý do chính. Một số trình biên dịch C nhúng có các phần mở rộng cho phép chúng giải quyết các thanh ghi (thường thông qua các hằng / biến toàn cục được khai báo trước). Họ có thể làm điều đó bởi vì họ chỉ nhắm mục tiêu một kiến trúc. Nhưng trình biên dịch C đa năng nhắm mục tiêu quá nhiều kiến trúc khác nhau để làm cho các phần mở rộng như vậy hợp lý. Do đó, họ thường chỉ thực hiện một cơ chế nhúng asm (bên cạnh đó, điều đó sẽ khiến chúng không chuẩn)

— slebetman

18

C là một bản tóm tắt từ mã máy chạy trên máy (mặc dù gần hơn nhiều so với hầu hết các ngôn ngữ khác).

Đối với những điều đó, các câu lệnh mã máy không thể được biểu thị bằng C và có thể để tối ưu hóa thêm không được cung cấp bởi trình biên dịch C được sử dụng, chủ yếu ở dạng trình biên dịch nội tuyến .

Trong cây mã nguồn hạt nhân, cây này được lưu trữ bên dưới arch/<arch>và tên kiến trúc cụ thể include/asm-<arch>ở đâu <arch>. Nó thực sự chỉ là một phần nhỏ của nguồn kernel hoàn chỉnh.

— bất kỳ ai
nguồn

6

Bạn không thể làm điều này trong C :)

lgdt[xxxx]
mov eax, cr0
or al, 0x01
mov cr0, eax

Đang cố gắng vào chế độ được bảo vệ x86. Rõ ràng là tôi vẫn có thể làm điều này trong C bằng cách "phát ra" mã máy thô, nhưng trong trường hợp tôi yêu cầu truy cập vào các phần mềm chính xác - tôi hầu như không gặp may.

Ví dụ thứ hai là BootLoader. Trên các hệ thống x86, yêu cầu mã khởi động truyền thống phải dài chính xác 512 byte và hai byte cuối cùng lần lượt là 0xAA và 0x55 (hoặc 55 AA) ... Đảm bảo một điều như vậy với trình biên dịch C là một cơn ác mộng và trình biên dịch thực hiện công việc một cách tuyệt vời

Có rất nhiều trường hợp như vậy mà hội không chỉ thích hợp hơn - mà là phương tiện duy nhất.

— Krishna S Santosh
nguồn

-5

asm mỏng hơn và thường nhanh hơn rất nhiều so với C bị vấy bẩn bởi các thư viện, v.v. và HĐH đang xử lý RẤT NHIỀU sự kiện TẤT CẢ mọi lúc. Bạn muốn mỏng và nhanh cho chức năng này.

— Escoce
nguồn

2

Tối ưu hóa công nghệ biên dịch C đã trở nên khá tốt. Đó là một huyền thoại rằng asm thường sẽ nhanh hơn rất nhiều so với C. Trong mọi trường hợp đó không phải là lý do mà các hoạt động của hệ điều hành cấp thấp sử dụng asm. Nó chủ yếu liên quan đến các hoạt động không thể được biểu thị bằng C như các rào cản bộ nhớ và đăng ký các điệu nhảy cho các quy ước gọi không phải C, v.v ...

— Celada