Tại sao chương trình chung thường bắt đầu ở mức 0x8000?

Question

Tôi không phải là người mới khởi động và hệ thống SW, nhưng tôi không biết nguồn gốc của lý do tại sao chương trình chung bắt đầu tại 0x8000. Tôi đã biết địa chỉ 0x8000 đã được sử dụng làm địa chỉ bắt đầu trong chương trình C/C++ bình thường.

Kích thước tối thiểu của bộ nạp khởi động cho chương trình chung có lên đến 0x8000 không? Hoặc là kích thước khối tối thiểu của ROM nên được phân bổ cho bộ nạp khởi động 32KB? Hoặc là có một lý do khác?

Tôi muốn biết điều này, về mặt lịch sử hoặc hợp lý và từ quan điểm địa chỉ ảo.

---

Tôi đánh giá cao tất cả, thời gian và trợ giúp của bạn về vấn đề này. Để đặt câu hỏi rõ ràng hơn, câu hỏi liên quan đến địa chỉ ảo không phải với vật lý.

Tôi về cơ bản đồng ý với ý kiến ​​của R từ quan điểm địa chỉ bộ nhớ vật lý.

Không nói một hệ thống cụ thể, ví dụ linux (ngay cả trong android), RTOS chung (hạt nhân, và những người khác, đặc biệt là phần liên kết ARM), tất cả đều sử dụng địa chỉ 0x8000 làm chương trình địa chỉ bắt đầu chung. được đặt tên như crt_begin.o, crt.o, v.v. tại 0x0 với bộ tải tồn tại trong khu vực này.

Vì vậy, tôi đoán kích thước tối thiểu của bộ nạp khởi động cho chương trình chung là 32KB xem xét kích thước khối nếu nó được đặt tại BootROM trong thời gian khởi động (khởi động nguội).

Ummm, Nhưng tôi không chắc chắn ...

Answer 1

Nói chung, trên tất cả các hệ thống nhúng nhỏ nhất, nền tảng ABI nhà thiết kế muốn tránh bao giờ có địa chỉ thấp nhất trong sử dụng để dereferences con trỏ null có thể bị mắc kẹt. Có một vài KB địa chỉ không hợp lệ cung cấp cho bạn một số an toàn bổ sung nếu con trỏ null bị bỏ qua với một mảng hoặc thành phần cấu trúc bù đắp, như trong null_ptr->some_member.

Answer 2

Tùy thuộc vào hệ thống và các chương trình bắt đầu tại các địa chỉ khác nhau trên các hệ thống khác nhau. Dưới Unix, thông thường (hoặc thậm chí có thể yêu cầu bởi Posix) để sử dụng địa chỉ 0 làm con trỏ rỗng và không ánh xạ trang đầu tiên của bộ nhớ ảo, để dereferencing một con trỏ rỗng sẽ dẫn đến vi phạm phân đoạn. Tôi nghi ngờ rằng các hệ thống khác sử dụng địa chỉ 0 làm con trỏ null hoạt động tương tự (nhưng số tiền dự trữ là có thể thay đổi). (Trong lịch sử, thường là bản đồ trang đầu tiên chỉ đọc , và điền nó bằng số không, làm điều đó một con trỏ rỗng sẽ hoạt động như thể nó là một chuỗi rỗng, một con trỏ đến "". Đó là khoảng 25 năm Tuy nhiên.)

tôi hy vọng rằng, ngay cả ngày hôm nay, một số hệ thống nhúng làm tải chương trình bắt đầu tại địa chỉ 0.

Answer 3

tôi nghi ngờ trong rất nhiều trường hợp, 32K đầu tiên được dành riêng cho các màn hình sử dụng mã/ram. Trong rất nhiều 8.051 đánh giá nó không phải là không phổ biến để mặc định 0x1000 hoặc 0x2000 cho tất cả các ứng dụng tùy thuộc vào màn hình cư trú (một số mà làm việc như debuggers quá).

32K có thể là bộ nạp trình khởi động u-boot/etc của bạn.

Answer 4

Đó là phần nào tùy ý và trên Linux, ít nhất được quyết định bởi trình liên kết. Ý tưởng chung là để dành một số không gian để bắt ngoại lệ con trỏ NULL. Để giúp ngăn chặn không gian hạt nhân NULL dereferences con trỏ từ thực hiện mã người dùng tùy ý trong chế độ hạt nhân, Linux ngăn cản bạn từ bản đồ rất dưới cùng của bộ nhớ. /proc/sys/vm/mmap_min_addr kiểm soát địa chỉ thấp nhất bạn có thể lập bản đồ (bạn có thể thay đổi địa chỉ thành 0 và ánh xạ một trang tại 0 nếu bạn muốn).

Trên linux, bạn có thể xem bản đồ bộ nhớ bằng cách xem trong /proc. Ví dụ,

genwitt ~> cat /proc/self/maps 
00400000-0040c000 r-xp 00000000 08:01 354804        /bin/cat 
0060b000-0060c000 r--p 0000b000 08:01 354804        /bin/cat 
0060c000-0060d000 rw-p 0000c000 08:01 354804        /bin/cat 
01dda000-01dfb000 rw-p 00000000 00:00 0         [heap] 
7f5b25913000-7f5b25a97000 r-xp 00000000 08:01 435953      /lib64/libc-2.14.1.so 
7f5b25a97000-7f5b25c97000 ---p 00184000 08:01 435953      /lib64/libc-2.14.1.so 
7f5b25c97000-7f5b25c9b000 r--p 00184000 08:01 435953      /lib64/libc-2.14.1.so 
7f5b25c9b000-7f5b25c9c000 rw-p 00188000 08:01 435953      /lib64/libc-2.14.1.so 
7f5b25c9c000-7f5b25ca1000 rw-p 00000000 00:00 0 
7f5b25ca1000-7f5b25cc2000 r-xp 00000000 08:01 436061      /lib64/ld-2.14.1.so 
7f5b25cd2000-7f5b25e97000 r--p 00000000 08:01 126248      /usr/lib64/locale/locale-archive 
7f5b25e97000-7f5b25e9a000 rw-p 00000000 00:00 0 
7f5b25ec0000-7f5b25ec1000 rw-p 00000000 00:00 0 
7f5b25ec1000-7f5b25ec2000 r--p 00020000 08:01 436061      /lib64/ld-2.14.1.so 
7f5b25ec2000-7f5b25ec3000 rw-p 00021000 08:01 436061      /lib64/ld-2.14.1.so 
7f5b25ec3000-7f5b25ec4000 rw-p 00000000 00:00 0 
7fff18c37000-7fff18c58000 rw-p 00000000 00:00 0       [stack] 
7fff18d0c000-7fff18d0d000 r-xp 00000000 00:00 0       [vdso] 
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0     [vsyscall]

Answer 5

Tôi tin rằng câu trả lời là có liên quan đến việc xử lý ngắt. Các địa chỉ xử lý ngắt được đặt trong phần cứng. Trong Intel 8086, có một bảng dịch trực tiếp trên mã trình xử lý ngắt và quy trình xử lý gián đoạn tương ứng. Có lẽ, điều này đã được thực hiện bởi một số mạch tổ hợp và do đó, để duy trì khả năng tương thích về phía trước, nó sẽ là hợp lý hơn để đặt chúng vào lúc bắt đầu của bộ nhớ hơn là ở cuối để ngăn chặn những thay đổi mọi lúc. Vì vậy, địa chỉ bắt đầu thực hiện sẽ nằm ở đầu kia của bộ nhớ. Ngoài ra, cần phải có đủ mã trong khối đó để tải chương trình phân đoạn bộ nhớ và lệnh nhảy để chuyển sang thực thi mã từ địa chỉ mã đó.