สถาปัตยกรรมที่แปลกใหม่ที่คณะกรรมการมาตรฐานใส่ใจ

154

ฉันรู้ว่ามาตรฐาน C และ C ++ ออกจากแง่มุมต่าง ๆ ของการใช้งานภาษาที่กำหนดเพราะถ้ามีสถาปัตยกรรมที่มีคุณสมบัติอื่น ๆ มันจะยากมากหรือเป็นไปไม่ได้ที่จะเขียนคอมไพเลอร์ที่สอดคล้องกับมาตรฐาน

ฉันรู้ว่า 40 ปีที่แล้วคอมพิวเตอร์เครื่องใดมีคุณสมบัติเฉพาะของตัวเอง อย่างไรก็ตามฉันไม่รู้สถาปัตยกรรมที่ใช้ในปัจจุบันที่:

CHAR_BIT != 8
signed ไม่ใช่สองส่วน (ฉันได้ยินว่า Java มีปัญหากับอันนี้)
จุดลอยตัวไม่เป็นไปตามมาตรฐาน IEEE 754 (แก้ไข: ฉันหมายถึง "ไม่ได้อยู่ในการเข้ารหัสแบบไบนารีของ IEEE 754")

เหตุผลที่ฉันขอคือว่าผมมักจะอธิบายให้คนที่เป็นของดีที่ C ++ ไม่อาณัติด้านระดับต่ำอื่น ๆ เช่นประเภทขนาดคง†มันดีเพราะไม่เหมือน 'ภาษาอื่น ๆ ' เพราะมันทำให้โค้ดของคุณพกพาได้เมื่อใช้อย่างถูกต้อง (แก้ไข: เนื่องจากมันสามารถย้ายไปยังสถาปัตยกรรมอื่น ๆ ได้โดยไม่ต้องจำลองด้านต่ำของเครื่องเช่นเช่นเลขคณิตสองส่วนของเครื่องหมาย + สถาปัตยกรรมขนาด) . แต่ฉันรู้สึกแย่ที่ฉันไม่สามารถชี้ไปที่สถาปัตยกรรมเฉพาะได้ด้วยตัวเอง

ดังนั้นคำถามคือสถาปัตยกรรมใดที่แสดงคุณสมบัติข้างต้น

† uint*_ts เป็นตัวเลือก

c++ c architecture

— ยาโคฟกอลก้า
แหล่งที่มา

9

ฉันคิดว่าคุณมีมันย้อนหลัง หาก C ++ ต้องมอบอำนาจให้พูดว่าเติมเต็มสองครั้งสำหรับเลขจำนวนเต็มที่ลงนามแล้วมันจะทำให้รหัส C ++ พกพาสะดวกยิ่งขึ้นไม่น้อย คำถามที่ว่าทำไมคณะกรรมการมาตรฐาน C ++ ไม่ได้บังคับให้เรื่องนี้เป็นเรื่องอื่น โดยเฉพาะอย่างยิ่งถึงแม้ว่าคุณจะพูดว่ามันเป็นไปไม่ได้ที่จะเขียนคอมไพเลอร์สำหรับสถาปัตยกรรมที่ไม่ได้มาตรฐานคุณสามารถจำลอง 8 บิต chars หรือ twos complement เลขคณิตได้แม้ในขณะที่แพลตฟอร์มของคุณไม่สนับสนุนโดยตรง

— จอห์น

8

@ John: แล้วมันจะเป็นไปไม่ได้ดังนั้นคอมไพเลอร์ที่ไม่ได้มาตรฐานจะสร้างโค้ดได้เร็วกว่าโค้ดที่สอดคล้องกัน และฉันก็ยังไม่เห็นว่ามันทำให้โค้ดของคุณพกพาได้มากกว่าเดิมอย่างไร

— Yakov Galka

4

ฉันแน่ใจว่าเหตุผลที่แท้จริงสำหรับมาตรฐานการเป็นเช่นนั้นไม่ใช่เพราะมันเป็นโซลูชันที่สมบูรณ์แบบ แต่เป็นเพราะเมื่อมาตรฐานเขียนคอมไพเลอร์ C และ C ++ หลายตัวมีอยู่แล้วและคณะกรรมการมาตรฐานไม่ต้องการปฏิเสธคอมไพเลอร์ที่มีอยู่

— จอห์น

4

@ จอห์น: ฉันสงสัยว่า "ทำให้ง่ายขึ้นสำหรับนักเขียนคอมไพเลอร์" มีความสำคัญเมื่อสร้างมาตรฐาน C ++ (พวกเขาจะทำงานที่น่ากลัวถ้ามันเป็นเพราะ C + + เป็นหนึ่งในภาษาที่ยากที่สุดในการแยกวิเคราะห์และด้านอื่น ๆ ของ ภาษาไม่ได้ทำให้ผู้เขียนคอมไพเลอร์ง่ายขึ้น) ประสิทธิภาพการรองรับแพลตฟอร์มที่กว้างและความเข้ากันได้แบบย้อนหลังนั้นค่อนข้างสำคัญ และทั้งสามคนนั้นจะต้องทนทุกข์ทรมานหากข้อ จำกัด ที่คุณพูดถึงจะถูกเพิ่มเข้าไปในมาตรฐาน

— Sander De Dycker

5

มันไม่เกี่ยวกับคอมไพเลอร์ แต่เป็นฮาร์ดแวร์ C ++ ปล่อยบางสิ่งที่ไม่ระบุไว้เพื่ออนุญาตให้ใช้คุณสมบัติฮาร์ดแวร์โดยตรง แอพโทรศัพท์ของคุณจะไม่ทำงานบนเมนเฟรมดังนั้นจึงไม่มีความสะดวกในการพกพา

— Bo Persson

114

ลองดูที่อันนี้

เซิร์ฟเวอร์ Unisys ClearPath Dorado

เสนอความเข้ากันได้ย้อนหลังสำหรับผู้ที่ยังไม่ได้ย้ายซอฟต์แวร์ Univac ทั้งหมด

ประเด็นสำคัญ:

คำ 36 บิต
CHAR_BIT == 9
ส่วนเสริม
จุดลอยตัวที่ไม่ใช่ IEEE 72 บิต
แยกพื้นที่ที่อยู่สำหรับรหัสและข้อมูล
คำจ่าหน้า
ไม่มีตัวชี้สแต็กโดยเฉพาะ

ไม่ทราบว่าพวกเขามี C ++ คอมไพเลอร์ว่า แต่พวกเขาจะทำได้

และตอนนี้ลิงก์ไปยังคู่มือ C ฉบับล่าสุดได้เปิดตัวแล้ว:

คู่มืออ้างอิง Unisys C Compiler Programming

ส่วน 4.5 มีตารางชนิดข้อมูลที่มี 9, 18, 36 และ 72 บิต

ขนาดและช่วงของชนิดข้อมูลในคอมไพเลอร์ USC C

— บ่อเพอร์สัน
แหล่งที่มา

13

ฉันคิดว่าเป็นโมฆะ * ต้องชั่วร้ายที่จะใช้ในสถาปัตยกรรมนั้น

— luiscubal

13

@ybungalobill - ฉันเชื่อchar*และvoid*ต้องมีขนาดเท่ากันและใหญ่พอที่จะถือตัวชี้อื่น ๆ ส่วนที่เหลือขึ้นอยู่กับการใช้งาน

— โบเพอร์สัน

22

@ybungalobill: สำหรับคอมไพเลอร์ Win16 เก่าพอยน์เตอร์ปกติอยู่ใกล้กับพอยน์เตอร์และมีออฟเซ็ต 16 บิตดังนั้นsizeof(int*) == 2แต่พอยน์เตอร์ที่ไกลก็มีตัวเลือก 16 บิตเช่นsizeof(void*) == 4กัน

— Adam Rosenfield

10

มีหรือเคยเป็นคู่มือออนไลน์สำหรับคอมไพเลอร์ C ++ ของพวกเขา มันก็คุ้มค่าที่จะชี้ให้เห็นว่านี่เป็นเพียงหนึ่งในสถาปัตยกรรมเมนเฟรมของ Unisys: อีกอันหนึ่งเป็นสถาปัตยกรรมที่ติดแท็กขนาดที่เซ็นชื่อขนาด 48 บิต (ซึ่งฉันพบคู่มือ C เท่านั้นไม่ใช่ C ++) เกี่ยวกับส่วนที่เหลือ: ฉันไม่คิดว่าที่sizeof(int*) != sizeof(char*)นี่: ทั้งสองเป็น 36 บิต แต่ตัวเลือกไบต์ในอยู่บนบิตการสั่งซื้อสูงและจะถูกละเว้นในchar* int*(ฉันใช้เครื่องจักรอื่น ๆ โดยที่ `sizeof (char *)> sizeof (int *))

— James Kanze

16

@ Adam Rosenfield ในคอมไพเลอร์ MS / DOS 16 บิตคุณมี "โหมด" ที่แตกต่างกันและตัวชี้ข้อมูลไม่จำเป็นต้องมีขนาดเท่ากับตัวชี้ฟังก์ชั่น แต่อย่างน้อยในสิ่งที่ฉันใช้ตัวชี้ข้อมูลทั้งหมด (รวมถึงvoid*) จะมีขนาดเท่ากันเสมอ (แน่นอนคุณไม่สามารถแปลงตัวชี้ฟังก์ชั่นเป็นvoid*เพราะvoid*อาจมีขนาดเล็กลง แต่ตามมาตรฐานคุณไม่สามารถทำได้ในวันนี้)

— James Kanze

51

ไม่มีการสันนิษฐานของคุณสำหรับเมนเฟรมคอมพิวเตอร์ สำหรับผู้เริ่มฉันไม่รู้ว่าเมนเฟรมที่ใช้ IEEE 754: IBM ใช้จุดลอยตัวฐาน 16 และเมนเฟรมของ Unisys ทั้งคู่ใช้ฐาน 8 เครื่องของ Unisys ค่อนข้างพิเศษในแง่อื่น: Bo ได้กล่าวถึง 2200 สถาปัตยกรรม แต่สถาปัตยกรรม MPS เป็นคนแปลกหน้าด้วย: 48 บิตคำที่ติดแท็ก (ไม่ว่าคำนั้นจะเป็นตัวชี้หรือไม่ก็ขึ้นอยู่กับคำในนั้น) และการแทนตัวเลขได้รับการออกแบบเพื่อให้ไม่มีความแตกต่างระหว่างจุดลอยตัวและเลขคณิตสมบูรณ์: จุดลอยตัวคือฐาน 8; มันไม่ต้องการการทำให้เป็นมาตรฐานและไม่เหมือนกับจุดลอยตัวอื่น ๆ ที่ฉันเคยเห็นมันวางทศนิยมทางด้านขวาของแมนทิสซาแทนที่จะซ้ายและใช้ขนาดที่เซ็นชื่อสำหรับเลขชี้กำลัง (นอกเหนือจากแมนทิสซา) ด้วยผลลัพธ์ที่ค่าจุดอินทิกรัลอินทิกรัลมี (หรืออาจมี) การแทนค่าบิตเดียวกับจำนวนเต็มขนาดที่เซ็นชื่อ และไม่มีคำแนะนำในการคำนวณเลขทศนิยม: ถ้าเลขชี้กำลังของทั้งสองค่าเป็น 0 การเรียนการสอนทำเลขคณิตหนึ่งหรือไม่เช่นนั้นมันจะคำนวณเลขทศนิยม (ความต่อเนื่องของปรัชญาการติดแท็กในสถาปัตยกรรม) ซึ่งหมายความว่าในขณะที่int อาจครอบครอง 48 บิต 8 ในนั้นต้องเป็น 0 มิฉะนั้นค่าจะไม่ถูกนับเป็นจำนวนเต็ม

— James Kanze
แหล่งที่มา

4

IBM mainframes (z / Architecture) รองรับจุดลอย IEE754

— Nikita Nemkin

1

fyi เห็นความคิดเห็น twitter นี้

— Shafik Yaghmour

6

@Nikita - พวกเขาทำในขณะนี้ เริ่มแรกมันเป็น add-on (แพง) เพื่อสนับสนุน Java

— โบเพอร์สัน

1

ClearPath เอ็นเตอร์ไพรส์เซิร์ฟเวอร์ C คู่มือการใช้งานโปรแกรมการอ้างอิง และนี่คือรูปแบบตัวเลขการลงนามของเบอร์โรห์

— phuclv

42

การปฏิบัติตามมาตรฐาน IEEE 754 เต็มรูปแบบหายากในการนำไปใช้งานแบบ floating-point และการลดลงของสเปคในเรื่องนั้นช่วยให้การเพิ่มประสิทธิภาพจำนวนมาก

ตัวอย่างเช่นการสนับสนุน subnorm แตกต่างกันระหว่าง x87 และ SSE

การเพิ่มประสิทธิภาพเช่นการหลอมรวมการคูณและการเพิ่มซึ่งแยกจากกันในซอร์สโค้ดก็เปลี่ยนผลลัพธ์เล็กน้อยเช่นกัน แต่เป็นการเพิ่มประสิทธิภาพที่ดีในสถาปัตยกรรมบางอย่าง

หรือตามมาตรฐาน IEEE ที่เข้มงวด x86 อาจต้องมีการตั้งค่าสถานะบางอย่างหรือถ่ายโอนเพิ่มเติมระหว่างการลงทะเบียนจุดลอยตัวและหน่วยความจำปกติเพื่อบังคับให้ใช้ประเภทจุดลอยที่ระบุแทนการลอย 80 บิตภายใน

และบางแพลตฟอร์มไม่มีฮาร์ดแวร์ใด ๆ เลยจึงต้องจำลองพวกมันในซอฟต์แวร์ และข้อกำหนดบางประการของ IEEE 754 อาจมีราคาแพงในการติดตั้งซอฟต์แวร์ โดยเฉพาะอย่างยิ่งกฎการปัดเศษอาจเป็นปัญหา

ข้อสรุปของฉันคือคุณไม่ต้องการสถาปัตยกรรมที่แปลกใหม่เพื่อให้เข้ากับสถานการณ์หากคุณไม่ต้องการรับประกันการปฏิบัติตามมาตรฐาน IEEE ที่เข้มงวดเสมอไป ด้วยเหตุนี้ภาษาการเขียนโปรแกรมบางภาษาจึงรับประกันการปฏิบัติตามมาตรฐาน IEEE ที่เข้มงวด

— CodesInChaos
แหล่งที่มา

7

ชุดฮาร์ดแวร์ "แปลกใหม่" อีกชุดคือเมนเฟรมของไอบีเอ็มซึ่งรูปแบบจุดลอยตัวจะนำหน้ามาตรฐาน IEEE แตกต่างจาก Java, C ++ ยังคงสามารถใช้ฮาร์ดแวร์ที่มีอยู่

— โบเพอร์สัน

5

IEEE 754 ไม่รองรับ GPU อย่างสมบูรณ์

— kerem

3

การขาดการปฏิบัติตามอย่างเคร่งครัดกับ IEEE 754 นั้นเป็นเรื่องที่น่ารำคาญสำหรับบางคน แต่ฉันไม่คิดว่ามันค่อนข้างจะอยู่ในขอบเขตของปัญหาที่ OP ใส่ใจจริงๆ

— Omnifarious

3

@ Matthieu เนื่องจากสิ่งนี้ถูกติดแท็ก "C" ด้วยฉันควรพูดถึงตัววิเคราะห์ C ที่สามารถบอกคุณค่าทั้งหมดที่โปรแกรม floating-point ของคุณอาจใช้กับการลงทะเบียนทศนิยม 80 บิตที่หกไปยังหน่วยความจำ blog.frama-c.com/index.php?post/2011/03/03/cosine-for-real

— Pascal Cuoq

2

@MatthieuM: มันดีเกินไป ISO / ANSI ไม่อนุญาตให้ใช้พารามิเตอร์ Variadic เพื่อระบุขนาดขั้นต่ำ / maximmum สำหรับอาร์กิวเมนต์ทศนิยมและจำนวนเต็ม ถ้าพวกเขามี 80 บิตจะได้รับชนิดที่มีประโยชน์และระยะยาวเนื่องจากปัญหาที่เกิดขึ้นจริงกับมันก็คือว่ามันทำงานได้ไม่ดีด้วยlong double printfความจริงที่ว่า double double ที่เก็บข้อมูลชั้นนำ 1 นั้นช่วยเร่งการคำนวณบนระบบที่ไม่ใช่ FPU อย่างชัดเจนและจะกำจัดความจำเป็นในการจัดการ denormals เป็นพิเศษในบริบทอื่น ๆ นอกเหนือจากการแปลงเป็น / จากประเภทอื่น ๆ เสียดายที่ C แย่มากprintfทุกอย่าง

— supercat

40

ผมพบว่าการเชื่อมโยงนี้รายชื่อบางระบบCHAR_BIT != 8ที่ พวกเขารวมถึง

TI DSP บางตัวมี CHAR_BIT == 16

BlueCore-5 ชิป (ชิปบลูทู ธ จากซิลิคอนเคมบริดจ์วิทยุ) CHAR_BIT == 16ซึ่งมี

และแน่นอนว่ามีคำถามเกี่ยวกับ Stack Overflow: แพลตฟอร์มใดมีสิ่งอื่นนอกเหนือจาก 8-bit char

ในฐานะที่เป็นสำหรับผู้ที่ไม่ใช่ระบบ two's-สมบูรณ์มีการอ่านที่น่าสนใจในcomp.lang.c ++. การดูแล สรุป: มีแพลตฟอร์มที่มีส่วนประกอบหรือสัญลักษณ์และขนาด

— DCN
แหล่งที่มา

5

อุปกรณ์อะนาล็อก 32 บิต SHARC DSP มีCHAR_BIT=32และ Texas Instruments DSP จาก TMS32F28xx CHAR_BIT=16มี GCC 3.2 สำหรับ PDP-10 CHAR_BIT=9มี ฉันคิดว่า S / 360 อาจมีรูปแบบไม่ 8 บิตเช่นกัน

— osgx

1

ฉันยังต้องการตัวอย่างสำหรับสถาปัตยกรรม 'non two's complement' โดยเฉพาะอย่างยิ่งเมื่อมันเกิดขึ้นว่าCHAR_BITSเป็นซ้ำบางส่วน

— Yakov Galka

TI DSPs มีตัวอักษร 16 บิตเท่านั้นเนื่องจากผู้ใช้งานเลือก (มันน่าจะเป็นงานที่ต้องทำงานให้ถูกต้อง แต่ไม่ยากนักที่จะพูดถึง IIRC - อาจจะเป็นแค่ "รู" ในโครงนั่งร้าน codegen ในคอมไพเลอร์พื้นฐาน) . ดังนั้นจึงไม่ใช่เหตุผลเชิงสถาปัตยกรรมที่ลึกล้ำ รหัส C ทำงานบนเครื่องที่เป็นนามธรรม หากสิ่งที่คุณมีคือ INT แบบ 16 บิตให้จัดเก็บสองตัวอักษรในแต่ละตัวและเพิ่มการผสานการอ่าน - แก้ไข - เขียนไปยังเครื่องมือเพิ่มตาแมว (อย่างน้อยที่สุด) แน่นอนว่ามันใช้งานได้มากกว่า แต่เพียงแค่ดูว่ามีงานมากขึ้นเพียงใดสำหรับทุกคนในการจัดการกับสิ่งแปลก ๆ ในสถานที่ที่พวกเขาจะไม่ปรากฏ yuck

— Reinstate Monica

24

ฉันค่อนข้างแน่ใจว่าระบบ VAX ยังคงใช้งานอยู่ พวกเขาไม่รองรับ IEEE floating-point; พวกเขาใช้รูปแบบของตัวเอง Alpha รองรับรูปแบบทศนิยมทั้ง VAX และ IEEE

เครื่องเวกเตอร์ Cray เช่น T90 มีรูปแบบจุดลอยตัวด้วยเช่นกันแม้ว่าระบบ Cray รุ่นใหม่จะใช้ IEEE (T90 ที่ฉันใช้เคยถูกปลดประจำการเมื่อหลายปีก่อนฉันไม่ทราบว่ายังคงมีการใช้งานอยู่หรือไม่)

T90 ยังมี / มีการแสดงที่น่าสนใจสำหรับพอยน์เตอร์และจำนวนเต็ม ที่อยู่ดั้งเดิมสามารถชี้ไปที่คำแบบ 64 บิตเท่านั้น คอมไพเลอร์ C และ C ++ มี CHAR_BIT == 8 (จำเป็นเพราะรัน Unicos, รสชาติของ Unix และต้องทำงานร่วมกับระบบอื่น) แต่ที่อยู่ดั้งเดิมสามารถชี้ไปที่คำแบบ 64 บิตเท่านั้น การดำเนินการระดับไบต์ทั้งหมดถูกสังเคราะห์โดยคอมไพเลอร์และ a void*หรือchar*เก็บออฟเซ็ตไบต์ในคำสั่งสูง 3 บิต และฉันคิดว่าจำนวนเต็มบางประเภทมีการเติมบิต

IBM mainframes เป็นอีกตัวอย่างหนึ่ง

ในทางตรงกันข้ามระบบเฉพาะเหล่านี้ไม่จำเป็นต้องจำกัด การเปลี่ยนแปลงมาตรฐานภาษา เครย์ไม่แสดงความสนใจเป็นพิเศษในการอัพเกรดคอมไพเลอร์ C เป็น C99 คงเป็นสิ่งเดียวกันกับคอมไพเลอร์ C ++ มันอาจจะสมเหตุสมผลที่จะกระชับความต้องการสำหรับการใช้งานที่โฮสต์เช่นต้องการ CHAR_BIT == 8, ทศนิยมรูปแบบ IEEE ถ้าไม่ใช่ความหมายเต็มและ 2's - สมบูรณ์โดยไม่ต้องแพ็ดบิตสำหรับจำนวนเต็มลงนาม ระบบเก่าสามารถรองรับมาตรฐานภาษาก่อนหน้านี้ต่อไปได้ (C90 ไม่ตายเมื่อ C99 ออกมา) และข้อกำหนดอาจเป็นแบบหลวม ๆ สำหรับการใช้งานอิสระ (ระบบฝังตัว) เช่น DSP

ในทางกลับกันอาจมีเหตุผลที่ดีสำหรับระบบในอนาคตที่จะทำสิ่งต่าง ๆ ที่จะถือว่าแปลกใหม่ในวันนี้

— Keith Thompson
แหล่งที่มา

6

จุดที่ดีในตอนท้ายเกี่ยวกับวิธีการที่เข้มงวดมาตรฐานป้องกันนวัตกรรมมากเกินไป เมื่อเราได้รับคอมพิวเตอร์ควอนตัม (หรือออร์แกนิก) ที่มีสถานะ trinary ความต้องการทางคณิตศาสตร์แบบโมดูโลสำหรับunsignedประเภทอินทิกรัลจะเป็นความเจ็บปวดครั้งใหญ่

— Ben Voigt

@BenVoigt เหตุใดการคิดเลขในมือจึงไม่เจ็บปวด? ไม่สามารถใช้โมดูโล 3 ^ n ในคอมพิวเตอร์เหล่านั้นไม่ได้เหรอ?

— phuclv

2

@ LưuVĩnhPhúc: นั่นคือจุดที่มีการดำเนินงานฮาร์ดแวร์ดำเนินการโมดูโล 3 ** n ให้ประเภท C + + ที่ไม่ได้ลงนามซึ่งการดำเนินการที่กำหนดไว้โมดูโล 2 ** n จะเป็นเรื่องยาก

— Ben Voigt

2

ฉันรู้ว่า VAX 11/780 หนึ่งยังคงใช้เป็นโฮสต์สำหรับคอมไพเลอร์ข้ามที่กำหนดเป้าหมายระบบฝังตัวเฉพาะที่มีสถาปัตยกรรมที่เป็นกรรมสิทธิ์ เพื่อรักษา VAX นั้นโดยเฉพาะผู้ดูแลได้เข้าใกล้พิพิธภัณฑ์เพื่อหาอะไหล่

— ปีเตอร์

2

@ Keith - ในทางเทคนิคสิ่งกีดขวางเพียงอย่างเดียวกำลังดำเนินการผ่านกระบวนการเพื่อให้หลักฐานที่จะเป็นไปตามข้อกำหนดด้านกฎระเบียบเนื่องจากระบบฝังตัวเป้าหมายมีความสำคัญสูง มีอุปสรรคมากมายที่ไม่ใช่ด้านเทคนิค (การเมืองขององค์กรและอื่น ๆ ) อย่างไรก็ตามถึงวันที่จะผ่านไม่ได้ ในปัจจุบันการติดตั้งเคสเพื่อโจมตีพิพิธภัณฑ์ง่ายกว่าการอัพเดทโฮสต์

— ปีเตอร์

16

CHAR_BITS

ตามรหัสแหล่งgcc :

CHAR_BITเป็น16บิตสำหรับ1750a , สถาปัตยกรรมdsp16xx
CHAR_BITเป็น24บิตสำหรับสถาปัตยกรรมdsp56k
CHAR_BITเป็น32บิตสำหรับสถาปัตยกรรมc4x

คุณสามารถค้นหาเพิ่มเติมได้อย่างง่ายดายโดยทำ:

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

หรือ

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

หากCHAR_TYPE_SIZEมีการกำหนดไว้อย่างเหมาะสม

การปฏิบัติตามมาตรฐาน IEEE 754

หากสถาปัตยกรรมเป้าหมายไม่รองรับคำสั่งจุดลอยตัวgccอาจสร้างแม่มดทางเลือกซอฟต์แวร์ไม่ใช่ค่ามาตรฐานตามค่าเริ่มต้น มากกว่าตัวเลือกพิเศษ (เช่น-funsafe-math-optimizationsแม่มดยังปิดการใช้งานเครื่องหมายการรักษาสำหรับศูนย์) สามารถใช้

— ivaigult
แหล่งที่มา

3

upvoted สำหรับเพียงสั่ง OP เพื่อดูที่มาของคอมไพเลอร์ที่เป็นที่นิยม; นี่คือคำจำกัดความของ RFTM ในกรณีนี้ดังนั้นจึงควรเป็นสถานที่แรกที่ผู้คนมอง

— underscore_d

9

การแสดงเลขฐานสองของ IEEE 754 นั้นไม่ใช่เรื่องแปลกสำหรับ GPU จนกระทั่งเมื่อเร็ว ๆ นี้ดูที่Paranoia ของ Floating-Pointหวาดระแวง

แก้ไข: คำถามได้รับการหยิบยกขึ้นมาในความคิดเห็นว่าจุดลอยของ GPU มีความเกี่ยวข้องกับการเขียนโปรแกรมคอมพิวเตอร์ปกติหรือไม่ซึ่งไม่เกี่ยวข้องกับกราฟิก ใช่! สิ่งที่มีประสิทธิภาพสูงที่สุดในอุตสาหกรรมคำนวณในวันนี้ทำบน GPUs; รายการประกอบด้วย AI, data mining, โครงข่ายประสาทเทียม, การจำลองทางกายภาพ, พยากรณ์อากาศ, และอีกมากมาย หนึ่งในลิงค์ในความคิดเห็นแสดงว่าทำไม: ลำดับความสำคัญได้เปรียบของทศนิยมของ GPU

อีกสิ่งหนึ่งที่ฉันต้องการเพิ่มซึ่งเกี่ยวข้องกับคำถาม OP: ผู้คนทำอะไรเมื่อ 10-15 ปีก่อนเมื่อจุดลอยตัวของ GPU ไม่ใช่ IEEE และเมื่อไม่มี API เช่น OpenCL หรือ CUDA ของวันนี้เพื่อเขียนโปรแกรม GPU เชื่อหรือไม่ว่าผู้บุกเบิกการคำนวณ GPU รุ่นแรกจัดการกับการเขียนโปรแกรม GPU โดยไม่ต้องใช้ API ทำเช่นนั้น ! ฉันพบหนึ่งในพวกเขาใน บริษัท ของฉัน นี่คือสิ่งที่เขาทำ: เขาเข้ารหัสข้อมูลที่เขาต้องการคำนวณเป็นภาพที่มีพิกเซลแสดงถึงค่าที่เขากำลังทำงานอยู่จากนั้นใช้ OpenGL เพื่อดำเนินการตามที่เขาต้องการ ฯลฯ ) และถอดรหัสภาพผลลัพธ์กลับไปเป็นอาร์เรย์ผลลัพธ์ และนี่ก็ยังเร็วกว่าการใช้ CPU!

สิ่งที่เป็นเช่นนั้นคือสิ่งที่ทำให้ NVidia ทำให้ข้อมูลภายในไบนารีของพวกเขาเข้ากันได้กับ IEEE และแนะนำ API เชิงการคำนวณมากกว่าการจัดการภาพ

— ไมเคิล
แหล่งที่มา

GPU มีความเกี่ยวข้องกันอย่างไร? (a) หน้านี้ดูล้าสมัยมาก (b) จนถึงทุกวันนี้คุณไม่สามารถเขียนโปรแกรม GPU ใน C: เนื่องจาก C สนับสนุนสิ่งต่าง ๆ เช่นฟังก์ชั่นวนซ้ำซึ่ง GPUs อย่างดีที่สุดเท่าที่ฉันรู้ ดังนั้นคุณไม่สามารถเขียนคอมไพเลอร์ได้ถ้าคุณต้องการ

— Yakov Galka

1

@ybungalobill, ถ่ายทำงานซ้ำกับ GPU เป็นอยู่ในปัจจุบันที่ต้องการวิธีการคำนวณขนาดใหญ่ ในความเป็นจริงฉันกำลังพัฒนาหนึ่งใน C ++ โชคดีที่เราทำงานกับ NVidia CUDA GPUs ที่มี IEEE 754 รองรับการแสดงเลขฐานสองของการลอย

— Michael

ฉันไม่ได้พูดว่า GPU ไม่ได้ใช้สำหรับการคำนวณ GP ฉันบอกว่าคุณไม่ได้ตั้งโปรแกรมเคอร์เนลใน C จริงๆแม้จะมีความคล้ายคลึงกันทางไวยากรณ์ คุณสามารถดำเนินการint f(int n) { return n <= 1 ? 1 : n * f(n-1); }ใน CUDA ได้หรือไม่? ถ้าไม่เช่นนั้น GPUs ไม่เกี่ยวข้องกับคำถามนี้ (ซึ่งถามเกี่ยวกับคณะกรรมการ C และ C ++)

— Yakov Galka

6

@ybungalobill: หลายคำตอบ ครั้งแรกCUDA ไม่สนับสนุน C, C ++ และ Fortran ดูลิงก์เดียวกันสำหรับข้อได้เปรียบด้านประสิทธิภาพอันน่าทึ่งของ GPU 2048 เธรดเหนือ CPU 8 เธรดทั่วไปของคุณ ที่สองจริงเพียงชุดย่อย (แม้ว่าภาษาใหญ่) ของภาษาเหล่านั้นได้รับการสนับสนุนรวมถึงการขาดการสนับสนุนที่เหมาะสมสำหรับการเรียกใช้โมเดลการเขียนโปรแกรม CUDA ซ้ำ (เรียกว่า "ไดนามิกขนาน") จนถึง CUDA 5.0 ประการที่สามการเรียกซ้ำมักจะถูกแทนที่ด้วยลูปซึ่งจำเป็นสำหรับความสมบูรณ์แบบแบบมัลติเธรดอยู่แล้ว

— Michael