Kiến trúc kỳ lạ mà các ủy ban tiêu chuẩn quan tâm

Tôi biết rằng các tiêu chuẩn C và C ++ để lại nhiều khía cạnh của việc triển khai ngôn ngữ - được định nghĩa chỉ vì nếu có một kiến ​​trúc với các đặc điểm khác, sẽ rất khó hoặc không thể viết trình biên dịch tuân thủ tiêu chuẩn cho nó.

Tôi biết rằng 40 năm trước, bất kỳ máy tính nào cũng có thông số kỹ thuật độc đáo của riêng nó. Tuy nhiên, tôi không biết bất kỳ kiến ​​trúc nào được sử dụng ngày nay:

• CHAR_BIT != 8
• signed không phải là bổ sung của hai (tôi nghe nói Java có vấn đề với cái này).
• Điểm nổi không tuân thủ theo chuẩn IEEE 754 (Chỉnh sửa: Ý tôi là "không có trong mã hóa nhị phân của IEEE 754").

Lý do tôi hỏi là tôi thường giải thích cho mọi người rằng nó tốt mà C ++ không ban hành bất kỳ khía cạnh cấp thấp khác như các loại có kích thước cố định ^† . Điều này tốt bởi vì không giống như 'các ngôn ngữ khác', nó làm cho mã của bạn có thể di động khi được sử dụng một cách chính xác (Chỉnh sửa: bởi vì nó có thể được chuyển sang nhiều kiến ​​trúc hơn mà không yêu cầu mô phỏng các khía cạnh cấp thấp của máy, ví dụ như hai số học bổ sung về ký hiệu + kiến ​​trúc cường độ) . Nhưng tôi cảm thấy tồi tệ rằng tôi không thể chỉ vào bất kỳ kiến ​​trúc cụ thể nào.

Vì vậy, câu hỏi là: kiến ​​trúc nào thể hiện các tính chất trên?

† uint*_ts là không bắt buộc.

Hãy nhìn vào cái này

Máy chủ Unisys ClearPath Dorado

cung cấp khả năng tương thích ngược cho những người chưa di chuyển tất cả phần mềm Univac của họ.

Những điểm chính:

• Từ 36 bit
• CHAR_BIT == 9
• bổ sung của một
• Điểm nổi 72-bit không phải của IEEE
• không gian địa chỉ riêng cho mã và dữ liệu
• địa chỉ từ
• không có con trỏ ngăn xếp chuyên dụng

Không biết họ có cung cấp trình biên dịch C ++ hay không, nhưng họ có thể .

Và bây giờ, một liên kết đến một phiên bản gần đây của hướng dẫn sử dụng C của họ đã xuất hiện:

Hướng dẫn tham khảo lập trình trình biên dịch Unisys C

Mục 4.5 có một bảng các loại dữ liệu với 9, 18, 36 và 72 bit.

Không có giả định nào của bạn giữ cho máy tính lớn. Để bắt đầu, tôi không biết về một máy tính lớn sử dụng IEEE 754: IBM sử dụng điểm nổi cơ sở 16 và cả hai máy tính lớn của Unisys đều sử dụng cơ sở 8. Các máy Unisys hơi đặc biệt ở nhiều khía cạnh khác: Bo đã đề cập đến 2200 kiến trúc, nhưng kiến ​​trúc MPS thậm chí còn xa lạ: các từ được gắn thẻ 48 bit. (Từ đó có phải là con trỏ hay không phụ thuộc vào một chút trong từ.) Và các biểu diễn số được thiết kế sao cho không có sự phân biệt thực sự giữa dấu phẩy động và số học tích phân: dấu phẩy động là cơ sở 8; nó không yêu cầu chuẩn hóa, và không giống như mọi điểm nổi khác mà tôi đã thấy, nó đặt số thập phân ở bên phải của lớp phủ, thay vì bên trái và sử dụng cường độ đã ký cho số mũ (ngoài lớp phủ). Với các kết quả mà một giá trị dấu phẩy động tích phân có (hoặc có thể có) chính xác biểu diễn bit giống như một số nguyên cường độ đã ký. Và không có hướng dẫn số học dấu phẩy động: nếu số mũ của hai giá trị đều bằng 0, thì lệnh này không tính số học tích phân, nếu không, nó thực hiện số học dấu phẩy động. (Tiếp nối triết lý gắn thẻ trong kiến ​​trúc.) Có nghĩa là trong khiint có thể chiếm 48 bit, 8 trong số chúng phải là 0 hoặc giá trị sẽ không được coi là số nguyên.

Tuân thủ đầy đủ IEEE 754 là rất hiếm trong triển khai điểm nổi. Và làm suy yếu đặc điểm kỹ thuật trong vấn đề đó cho phép rất nhiều tối ưu hóa.

Ví dụ, sự khác biệt hỗ trợ subnorm giữa x87 và SSE.

Tối ưu hóa như hợp nhất một phép nhân và phép cộng riêng biệt trong mã nguồn cũng làm thay đổi kết quả một chút, nhưng tối ưu hóa tốt trên một số kiến ​​trúc.

Hoặc trên x86, việc tuân thủ nghiêm ngặt của IEEE có thể yêu cầu một số cờ nhất định được đặt hoặc chuyển bổ sung giữa các thanh ghi dấu phẩy động và bộ nhớ thông thường để buộc nó sử dụng loại dấu phẩy động được chỉ định thay vì các phao nổi 80 bit bên trong.

Và một số nền tảng hoàn toàn không có phần cứng nổi và do đó cần phải mô phỏng chúng trong phần mềm. Và một số yêu cầu của IEEE 754 có thể tốn kém khi thực hiện trong phần mềm. Cụ thể, các quy tắc làm tròn có thể là một vấn đề.

Kết luận của tôi là bạn không cần các kiến ​​trúc kỳ lạ để có thể rơi vào tình huống là bạn không luôn muốn đảm bảo tuân thủ nghiêm ngặt của IEEE. Vì lý do này, rất ít ngôn ngữ lập trình đảm bảo tuân thủ nghiêm ngặt của IEEE.

Tôi tìm thấy liên kết này liệt kê một số hệ thống trong đó CHAR_BIT != 8. Chúng bao gồm

một số DSP DSP có CHAR_BIT == 16

Chip BlueCore-5 (chip Bluetooth của Cambridge Silicon Radio) có CHAR_BIT == 16.

Và tất nhiên, có một câu hỏi về Stack Overflow: Nền tảng nào có thứ gì khác ngoài char 8 bit

Đối với các hệ thống bổ sung không có hai, có một cách đọc thú vị trên comp.lang.c ++. Được kiểm duyệt . Tóm tắt: có những nền tảng có đại diện bổ sung hoặc ký hiệu và cường độ.

Tôi khá chắc chắn rằng các hệ thống VAX vẫn đang được sử dụng. Họ không hỗ trợ điểm nổi của IEEE; họ sử dụng định dạng riêng của họ. Alpha hỗ trợ cả định dạng dấu phẩy động VAX và IEEE.

Các máy vectơ Cray, như T90, cũng có định dạng dấu phẩy động riêng, mặc dù các hệ thống Cray mới hơn sử dụng IEEE. (T90 tôi đã sử dụng đã ngừng hoạt động vài năm trước; tôi không biết liệu có còn sử dụng hoạt động không.)

T90 cũng đã có / có một số đại diện thú vị cho con trỏ và số nguyên. Một địa chỉ gốc chỉ có thể trỏ đến một từ 64 bit. Trình biên dịch C và C ++ có CHAR_BIT == 8 (cần thiết vì nó chạy Unicos, một hương vị của Unix và phải tương tác với các hệ thống khác), nhưng một địa chỉ gốc chỉ có thể trỏ đến một từ 64 bit. Tất cả các hoạt động ở mức byte được trình biên dịch tổng hợp và a void*hoặc char*lưu trữ một byte bù theo 3 bit thứ tự cao của từ. Và tôi nghĩ rằng một số loại số nguyên có bit đệm.

Máy tính lớn của IBM là một ví dụ khác.

Mặt khác, các hệ thống cụ thể này không nhất thiết phải loại trừ các thay đổi đối với tiêu chuẩn ngôn ngữ. Cray không cho thấy bất kỳ mối quan tâm đặc biệt nào trong việc nâng cấp trình biên dịch C của nó lên C99; có lẽ điều tương tự được áp dụng cho trình biên dịch C ++. Có thể hợp lý để thắt chặt các yêu cầu đối với việc triển khai được lưu trữ, chẳng hạn như yêu cầu CHAR_BIT == 8, dấu phẩy động định dạng IEEE nếu không phải là ngữ nghĩa đầy đủ và bổ sung 2 mà không cần bit đệm cho số nguyên đã ký. Các hệ thống cũ có thể tiếp tục hỗ trợ các tiêu chuẩn ngôn ngữ trước đó (C90 không chết khi C99 xuất hiện) và các yêu cầu có thể lỏng lẻo hơn đối với việc triển khai tự do (hệ thống nhúng) như DSP.

Mặt khác, có thể có những lý do chính đáng để các hệ thống trong tương lai thực hiện những điều được coi là kỳ lạ ngày nay.

CHAR_BITS

Theo mã nguồn gcc :

CHAR_BITlà 16bit cho 1750a , dsp16xx kiến trúc.
CHAR_BITlà 24bit cho kiến trúc dsp56k .
CHAR_BITlà 32bit cho kiến trúc c4x .

Bạn có thể dễ dàng tìm thấy nhiều hơn bằng cách làm:

find $GCC_SOURCE_TREE -type f | xargs grep "#define CHAR_TYPE_SIZE"

hoặc là

find $GCC_SOURCE_TREE -type f | xargs grep "#define BITS_PER_UNIT"

nếu CHAR_TYPE_SIZEđược xác định một cách thích hợp.

Tuân thủ IEEE 754

Nếu kiến ​​trúc đích không hỗ trợ các hướng dẫn dấu phẩy động, gcc có thể tạo phù thủy dự phòng phần mềm không theo tiêu chuẩn theo mặc định. Hơn nữa, các tùy chọn đặc biệt (như -funsafe-math-optimizationsphù thủy cũng vô hiệu hóa việc bảo quản dấu hiệu cho số không) có thể được sử dụng.

Đại diện nhị phân của IEEE 754 là không phổ biến trên GPU cho đến gần đây, xem Paranoia nổi điểm GPU .

EDIT: một câu hỏi đã được đặt ra trong các ý kiến ​​cho dù điểm nổi GPU có liên quan đến chương trình máy tính thông thường, không liên quan đến đồ họa hay không. Chết tiệt Hầu hết mọi thứ hiệu suất cao được tính toán công nghiệp ngày nay đều được thực hiện trên GPU; danh sách này bao gồm AI, khai thác dữ liệu, mạng lưới thần kinh, mô phỏng vật lý, dự báo thời tiết và nhiều hơn nữa. Một trong những liên kết trong các ý kiến ​​cho thấy lý do tại sao: một thứ tự lợi thế điểm nổi lớn của GPU.

Một điều nữa tôi muốn thêm vào, có liên quan nhiều hơn đến câu hỏi OP: mọi người đã làm gì cách đây 10 - 15 năm khi điểm nổi GPU không phải là IEEE và khi không có API như OpenCL hay CUDA ngày nay để lập trình GPU? Dù bạn có tin hay không, những người tiên phong về điện toán GPU đã quản lý để lập trình GPU mà không cần API để làm điều đó ! Tôi đã gặp một trong số họ trong công ty của tôi. Đây là những gì anh ta đã làm: anh ta mã hóa dữ liệu anh ta cần để tính toán như một hình ảnh với các pixel đại diện cho các giá trị anh ta đang làm việc, sau đó sử dụng OpenGL để thực hiện các thao tác anh ta cần (chẳng hạn như "gaussian Blur" để biểu thị một tích chập với phân phối bình thường , v.v.) và giải mã hình ảnh kết quả thành một mảng kết quả. Và điều này vẫn nhanh hơn so với sử dụng CPU!

Những thứ như vậy là điều đã thúc đẩy NVidia cuối cùng làm cho dữ liệu nhị phân nội bộ của họ tương thích với IEEE và giới thiệu API theo định hướng tính toán thay vì thao tác hình ảnh.