Có nền tảng nào mà con trỏ đến các loại khác nhau có kích thước khác nhau không?

Question

Chuẩn C cho phép các con trỏ đến các loại khác nhau có kích thước khác nhau, ví dụ: sizeof(char*) != sizeof(int*) được cho phép. Tuy nhiên, nó yêu cầu rằng nếu một con trỏ được chuyển đổi thành void* và sau đó được chuyển đổi về kiểu gốc của nó, nó phải so sánh với giá trị ban đầu của nó. Do đó, nó theo logic một cách hợp lý rằng sizeof(void*) >= sizeof(T*) cho tất cả các loại T, đúng không? Trên các nền tảng phổ biến nhất được sử dụng ngày nay (x86, PPC, ARM và 64-bit, vv), kích thước của tất cả các con trỏ bằng kích thước đăng ký gốc (4 hoặc 8 byte), bất kể đánh máy. Có bất kỳ nền tảng bí truyền hoặc nhúng nào trong đó các con trỏ đến các loại khác nhau có thể có kích thước khác nhau không? Tôi đặc biệt hỏi về dữ liệu con trỏ, mặc dù tôi cũng muốn biết liệu có các nền tảng có chức năng hàm có kích thước không bình thường hay không.

Tôi chắc chắn là không phải hỏi về các hàm trỏ-thành viên của C++ và các hàm con trỏ tới thành viên. Những người có kích thước bất thường trên nền tảng phổ biến và thậm chí có thể thay đổi trong một nền tảng, tùy thuộc vào thuộc tính của lớp con trỏ (không đa hình, thừa kế đơn, đa thừa kế, thừa kế ảo hoặc loại không đầy đủ).

Answer 1

Answer from the C FAQ:

Thủ tướng Chính 50 loạt sử dụng phân khúc 07.777, offset 0 cho con trỏ null, ít nhất là cho PL/I. Các mô hình sau sử dụng phân khúc 0, bù 0 cho các con trỏ null trong C, đòi hỏi các chỉ lệnh mới như TCNP (Test C Null Pointer), hiển nhiên như là một đỉnh cho tất cả các mã C đã viết kém chưa thực hiện mà đưa ra các giả định không chính xác. Các máy Prime cũ hơn, được giải quyết bằng văn bản cũng nổi tiếng vì yêu cầu các con trỏ byte lớn hơn (char * 's) hơn con trỏ từ (int *' s). Dòng sản phẩm MV Eclipse từ Data General có ba định dạng con trỏ được hỗ trợ kiến ​​trúc (từ, byte và bit con trỏ), hai trong số đó được sử dụng bởi trình biên dịch C: con trỏ byte cho char * và void *, và con trỏ từ cho mọi thứ khác. Vì lý do lịch sử trong quá trình tiến hóa của dòng 32-bit MV từ đường Nova 16 bit, các con trỏ từ và con trỏ byte có các bit bảo vệ bù đắp, vô hướng và vòng ở các vị trí khác nhau trong từ. Chuyển một định dạng con trỏ không khớp đến một hàm dẫn đến lỗi bảo vệ. Cuối cùng, trình biên dịch MV C đã thêm nhiều tùy chọn tương thích để cố gắng xử lý mã có lỗi không khớp kiểu con trỏ.

Một số khung chính của Honeywell-Bull sử dụng mẫu bit 06000 cho các con trỏ null (nội bộ).

CDC Cyber ​​180 Series có các con trỏ 48 bit bao gồm vòng, đoạn và bù. Hầu hết người dùng (trong vòng 11) đều có con trỏ null là 0xB00000000000. Nó phổ biến trên các máy bổ sung CDC cũ để sử dụng một từ một bit như một lá cờ đặc biệt cho tất cả các loại dữ liệu, kể cả các địa chỉ không hợp lệ.

Dòng HP 3000 cũ sử dụng lược đồ địa chỉ khác cho địa chỉ byte thay vì địa chỉ từ; giống như một số máy trên nó do đó sử dụng các biểu diễn khác nhau cho các con trỏ char * và void * so với các con trỏ khác.

Máy tượng trưng Lisp, một kiến ​​trúc được gắn thẻ, thậm chí không có con trỏ số thông thường; nó sử dụng các cặp (về cơ bản là một xử lý không tồn tại) như là một con trỏ null C.

Tùy thuộc vào kiểu bộ nhớ `'đang sử dụng, bộ xử lý 8086-gia đình (PC tương thích) có thể sử dụng con trỏ dữ liệu 16 bit và chức năng 32 bit con trỏ hoặc ngược lại.

Một số máy in màu 64 bit đại diện cho int * trong 48 bit thấp hơn của từ ; char * cũng sử dụng một số trong số 16 bit trên để chỉ ra địa chỉ byte trong một từ.

Liên kết bổ sung: A message from Chris Torek với các chi tiết khác về một số máy này.

Answer 2

Quay lại những năm vàng của DOS, 8088 và bộ nhớ phân đoạn, thông thường phải chỉ định "mô hình bộ nhớ", ví dụ: tất cả các mã sẽ phù hợp với 64k (một phân đoạn) nhưng dữ liệu có thể kéo dài nhiều phân đoạn; điều này có nghĩa là một con trỏ hàm sẽ là 2 byte, một con trỏ dữ liệu, 4 ​​byte. Không chắc liệu có ai vẫn đang lập trình cho các loại máy đó không, có thể một số vẫn tồn tại trong các ứng dụng nhúng.

Answer 3

Không hoàn toàn những gì bạn đang yêu cầu, nhưng trở lại trong 16-bit DOS/Windows ngày, bạn đã có sự khác biệt giữa một con trỏ và một con trỏ xa, sau này là 32-bit.

tôi có thể có cú pháp sai ...

int *pInt = malloc(sizeof(int)); 
int far *fpInt = _fmalloc(sizeof(int)); 

printf("pInt: %d, fpInt: %d\n", sizeof(pInt), sizeof(fpInt)); 

Output:

pint: 2, 4 fpInt

Answer 4

Người ta có thể dễ dàng tưởng tượng một máy kiến ​​trúc Harvard có kích cỡ khác nhau cho con trỏ hàm và tất cả các con trỏ khác. Không biết ví dụ ...

Answer 5

Do đó, nó theo logic một cách hợp lý rằng sizeof(void*) >= sizeof(T*) cho tất cả các loại T, đúng không?

Điều đó không nhất thiết phải tuân theo, vì sizeof là về đại diện bộ nhớ và không phải tất cả các mẫu bit đều phải là giá trị hợp lệ. Tôi nghĩ rằng bạn có thể viết triển khai tuân thủ ở đó sizeof(int*) == 8, sizeof(void*) == 4, nhưng không có nhiều hơn 2^32 giá trị có thể cho một int *. Không chắc chắn tại sao bạn muốn.

Answer 6

Con trỏ cận và vẫn được sử dụng trên một số bộ vi điều khiển nhúng với flash hoặc RAM, để cho phép bạn trỏ đến dữ liệu trong cùng một trang (gần con trỏ) hoặc một trang khác (con trỏ xa, lớn hơn vì nó bao gồm thông tin trang).

Ví dụ, bộ vi điều khiển HCS12 của Freescale sử dụng kiến ​​trúc Von Neumann 16 bit, có nghĩa là không có địa chỉ nào có thể lớn hơn 16 bit. Bởi vì giới hạn này sẽ đặt vào số lượng không gian mã có sẵn, có một trang đăng ký 8-bit.

Vì vậy, để trỏ đến dữ liệu trong cùng một trang mã, bạn chỉ cần chỉ định địa chỉ 16 bit; đây là một con trỏ gần.

Để trỏ đến dữ liệu trong trang mã khác, bạn phải bao gồm cả số trang 8 bit và địa chỉ 16 bit trong trang đó, dẫn đến con trỏ xa 24 bit.

Answer 7

Có thể kích thước của con trỏ đến dữ liệu khác với con trỏ đến hàm chẳng hạn. Nó là phổ biến cho điều này xảy ra trong bộ vi xử lý cho hệ thống nhúng. Các máy kiến ​​trúc Harvard như dmckee đã đề cập khiến việc này dễ xảy ra.

Nó chỉ ra rằng nó làm cho phụ trợ gcc một nỗi đau để phát triển!:)

Chỉnh sửa: Tôi không thể đi vào chi tiết của máy cụ thể mà tôi đang nói đến nhưng hãy để tôi thêm lý do tại sao máy Harvard làm cho điều này dễ xảy ra. Kiến trúc Harvard có lưu trữ và đường dẫn khác nhau để hướng dẫn và dữ liệu, do đó nếu bus cho lệnh là 'lớn hơn' cho dữ liệu, bạn sẽ có một con trỏ hàm có kích thước lớn hơn con trỏ tới dữ liệu!