เหตุใด Intel จึงซ่อนแกน RISC ภายในไว้ในโปรเซสเซอร์

เริ่มต้นด้วย Pentium Pro (P6 microarchitecture) Intel ได้ออกแบบไมโครโปรเซสเซอร์ใหม่และใช้แกน RISC ภายในภายใต้คำแนะนำ CISC แบบเก่า เนื่องจาก Pentium Pro คำสั่ง CISC ทั้งหมดจะถูกแบ่งออกเป็นส่วนย่อย ๆ (uops) จากนั้นดำเนินการโดย RISC core

ในตอนแรกเป็นที่ชัดเจนสำหรับฉันว่า Intel ตัดสินใจซ่อนสถาปัตยกรรมภายในใหม่และบังคับให้โปรแกรมเมอร์ใช้ "CISC shell" ด้วยการตัดสินใจนี้ Intel สามารถออกแบบสถาปัตยกรรมไมโครโปรเซสเซอร์ใหม่ทั้งหมดโดยไม่ทำลายความเข้ากันได้จึงสมเหตุสมผล

อย่างไรก็ตามฉันไม่เข้าใจสิ่งหนึ่งทำไม Intel ยังคงซ่อนชุดคำสั่ง RISC ภายในไว้เป็นเวลาหลายปี ทำไมพวกเขาไม่ปล่อยให้โปรแกรมเมอร์ใช้คำสั่ง RISC เหมือนกับการใช้ชุดคำสั่ง x86 CISC แบบเก่า

หาก Intel รักษาความเข้ากันได้แบบย้อนหลังเป็นเวลานาน (เรายังมีโหมด 8086 เสมือนอยู่ถัดจากโหมด 64 บิต) ทำไมพวกเขาไม่อนุญาตให้เรารวบรวมโปรแกรมดังนั้นพวกเขาจะข้ามคำแนะนำ CISC และใช้ RISC core โดยตรง วิธีนี้จะเปิดวิธีที่เป็นธรรมชาติในการละทิ้งชุดคำสั่ง x86 อย่างช้าๆซึ่งเลิกใช้แล้วในปัจจุบัน (นี่คือเหตุผลหลักที่ Intel ตัดสินใจใช้ RISC core ภายในใช่ไหม)

ดูซีรีส์ Intel 'Core i' ใหม่ที่ฉันเห็นว่าพวกเขาขยายเฉพาะชุดคำสั่ง CISC ที่เพิ่ม AVX, SSE4 และอื่น ๆ

ไม่ชุดคำสั่ง x86 ไม่ได้เลิกใช้งานอย่างแน่นอน เป็นที่นิยมเช่นเคย เหตุผลที่ Intel ใช้ชุดคำสั่งไมโครที่คล้าย RISC เป็นการภายในเนื่องจากสามารถประมวลผลได้อย่างมีประสิทธิภาพมากขึ้น

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

สำหรับการเปิดเผยรูปแบบนี้กับโปรแกรม "ภายนอก" มีสองประเด็น:

• ไม่ใช่รูปแบบที่เสถียร Intel สามารถเปลี่ยนระหว่างรุ่น CPU เพื่อให้เข้ากับสถาปัตยกรรมเฉพาะได้มากที่สุด สิ่งนี้ช่วยให้พวกเขาเพิ่มประสิทธิภาพสูงสุดและข้อได้เปรียบนี้จะหายไปหากพวกเขาต้องจัดการกับรูปแบบคำสั่งคงที่และเสถียรสำหรับการใช้งานภายในและการใช้งานภายนอก
• ไม่มีอะไรที่จะได้รับจากการทำ ด้วย CPU ที่มีขนาดใหญ่และซับซ้อนในปัจจุบันตัวถอดรหัสจึงเป็นส่วนที่ค่อนข้างเล็กของ CPU การต้องถอดรหัสคำสั่ง x86 ทำให้ซับซ้อนมากขึ้น แต่ส่วนที่เหลือของ CPU ไม่ได้รับผลกระทบดังนั้นโดยรวมแล้วมีเพียงเล็กน้อยที่จะได้รับโดยเฉพาะอย่างยิ่งเนื่องจากยังคงต้องมีส่วนหน้า x86 อยู่ที่นั่นเพื่อที่จะรันโค้ด "ดั้งเดิม" ได้ . ดังนั้นคุณจะไม่บันทึกทรานซิสเตอร์ที่ใช้อยู่ในส่วนหน้า x86 ในปัจจุบัน

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

คำตอบที่แท้จริงนั้นง่าย

ปัจจัยสำคัญที่อยู่เบื้องหลังการใช้งานโปรเซสเซอร์ RISC คือการลดความซับซ้อนและเพิ่มความเร็ว ข้อเสียของ RISC คือความหนาแน่นของคำสั่งที่ลดลงซึ่งหมายความว่ารหัสเดียวกันที่แสดงในรูปแบบ RISC like ต้องการคำแนะนำมากกว่ารหัส CISC ที่เทียบเท่า

ผลข้างเคียงนี้ไม่ได้มีความหมายมากนักหาก CPU ของคุณทำงานด้วยความเร็วเท่ากันกับหน่วยความจำหรืออย่างน้อยก็ถ้าทั้งคู่ทำงานด้วยความเร็วที่ใกล้เคียงกันพอสมควร

ขณะนี้ความเร็วของหน่วยความจำเมื่อเทียบกับความเร็วของ CPU แสดงให้เห็นถึงความแตกต่างอย่างมากในนาฬิกา ซีพียูปัจจุบันบางครั้งเร็วกว่าหน่วยความจำหลักห้าเท่าหรือมากกว่า

สถานะของเทคโนโลยีนี้สนับสนุนรหัสที่หนาแน่นกว่าซึ่งเป็นสิ่งที่ CISC ให้ไว้

คุณสามารถโต้แย้งว่าแคชสามารถเร่งความเร็วซีพียู RISC ได้ แต่ก็สามารถพูดได้เช่นเดียวกันเกี่ยวกับ CISC cpus

คุณได้รับการปรับปรุงความเร็วที่มากขึ้นโดยใช้ CISC และแคชมากกว่า RISC และแคชเนื่องจากแคชขนาดเดียวกันมีผลมากกว่ารหัสความหนาแน่นสูงที่ CISC มีให้

ผลข้างเคียงอีกประการหนึ่งคือ RISC ใช้งานคอมไพเลอร์ได้ยากกว่า ง่ายต่อการปรับแต่งคอมไพเลอร์สำหรับ CISC cpus เป็นต้น

Intel รู้ว่าพวกเขากำลังทำอะไร

นี่เป็นเรื่องจริงที่ ARM มีโหมดความหนาแน่นของรหัสที่สูงกว่าที่เรียกว่า Thumb

หาก Intel รักษาความเข้ากันได้แบบย้อนหลังเป็นเวลานาน (เรายังมีโหมด 8086 เสมือนอยู่ถัดจากโหมด 64 บิต) ทำไมพวกเขาไม่อนุญาตให้เรารวบรวมโปรแกรมดังนั้นพวกเขาจะข้ามคำแนะนำ CISC และใช้ RISC core โดยตรง วิธีนี้จะเปิดวิธีที่เป็นธรรมชาติในการละทิ้งชุดคำสั่ง x86 อย่างช้าๆซึ่งเลิกใช้แล้วในปัจจุบัน (นี่คือเหตุผลหลักที่ Intel ตัดสินใจใช้ RISC core ภายในใช่ไหม)

คุณต้องมองในมุมของธุรกิจนี้ Intel ได้พยายามที่จะย้ายออกจาก x86 แต่ห่านที่วางไข่ทองคำให้กับ บริษัท XScale และ Itanium ไม่เคยเข้าใกล้ระดับความสำเร็จของธุรกิจหลัก x86

สิ่งที่คุณถามโดยทั่วไปคือให้ Intel กรีดข้อมือเพื่อแลกกับความคลุมเครือที่อบอุ่นจากนักพัฒนา การบ่อนทำลาย x86 ไม่ได้อยู่ในผลประโยชน์ของพวกเขา อะไรก็ตามที่ทำให้นักพัฒนาจำนวนมากไม่ต้องเลือกกำหนดเป้าหมาย x86 บ่อนทำลาย x86 ซึ่งจะทำลายพวกเขา

คำตอบนั้นง่ายมาก Intel ไม่ได้พัฒนา CPU สำหรับนักพัฒนา ! พวกเขากำลังพัฒนาสิ่งเหล่านี้สำหรับผู้ที่ตัดสินใจซื้อซึ่ง BTW คือสิ่งที่ทุก บริษัท ในโลกทำ!

Intel ให้คำมั่นสัญญาไว้นานแล้วว่า (ด้วยเหตุผล) ซีพียูของพวกเขาจะยังคงใช้งานร่วมกันได้ ผู้คนต้องการทราบว่าเมื่อพวกเขาซื้อคอมพิวเตอร์ที่ใช้ Intel เครื่องใหม่นั้นซอฟต์แวร์ปัจจุบันทั้งหมดของพวกเขาจะทำงานเหมือนกับที่ทำในคอมพิวเตอร์เครื่องเก่าทุกประการ (แม้ว่าหวังว่าจะเร็วขึ้น!)

นอกจากนี้ Intel รู้ดี ว่าวิธีการที่สำคัญที่มุ่งมั่นเป็นเพราะพวกเขาเคยพยายามที่จะไปเป็นวิธีที่แตกต่างกัน คุณรู้จัก Itanium CPU กันกี่คนกันแน่!?

คุณอาจไม่ชอบ แต่การตัดสินใจที่จะอยู่กับ x86 คือสิ่งที่ทำให้ Intel เป็นหนึ่งในชื่อธุรกิจที่เป็นที่รู้จักมากที่สุดในโลก!

คำตอบของ @ jalf ครอบคลุมสาเหตุส่วนใหญ่ แต่มีรายละเอียดที่น่าสนใจอย่างหนึ่งที่ไม่ได้กล่าวถึง: แกนที่คล้าย RISC ภายในไม่ได้ออกแบบมาเพื่อเรียกใช้ชุดคำสั่งเช่น ARM / PPC / MIPS ภาษี x86 ไม่ได้จ่ายเฉพาะในตัวถอดรหัสที่ใช้พลังงานเท่านั้น แต่ในระดับหนึ่งตลอดทั้งแกน กล่าวคือไม่ใช่แค่การเข้ารหัสคำสั่ง x86 เท่านั้น ทุกคำสั่งที่มีความหมายแปลก ๆ

ลองแกล้งทำเป็นว่า Intel สร้างโหมดการทำงานโดยที่สตรีมคำสั่งเป็นอย่างอื่นที่ไม่ใช่ x86 พร้อมคำแนะนำที่แมปโดยตรงกับ uops ลองแกล้งทำเป็นว่า CPU แต่ละรุ่นมี ISA ของตัวเองสำหรับโหมดนี้ดังนั้นจึงยังคงมีอิสระที่จะเปลี่ยนภายในเมื่อต้องการและแสดงให้เห็นด้วยทรานซิสเตอร์จำนวนน้อยที่สุดสำหรับการถอดรหัสคำสั่งของรูปแบบทางเลือกนี้

สันนิษฐานว่าคุณยังคงมีรีจิสเตอร์จำนวนเท่าเดิมซึ่งแมปกับสถานะสถาปัตยกรรม x86 ดังนั้นระบบปฏิบัติการ x86 จึงสามารถบันทึก / กู้คืนได้บนสวิตช์บริบทโดยไม่ต้องใช้ชุดคำสั่งเฉพาะของ CPU แต่ถ้าเราโยนให้เห็นว่าข้อ จำกัด ในทางปฏิบัติใช่เราอาจมีการลงทะเบียนอีกไม่กี่เพราะเราสามารถใช้ซ่อนลงทะเบียนชั่วคราวลิขสิทธิ์ตามปกติสำหรับเฟิร์มแว1

หากเรามีตัวถอดรหัสทางเลือกโดยไม่มีการเปลี่ยนแปลงขั้นตอนไปป์ไลน์ในภายหลัง (หน่วยการดำเนินการ) ISA นี้จะยังคงมีความผิดปกติของ x86 จำนวนมาก มันคงไม่ใช่สถาปัตยกรรม RISC ที่ดีมาก ไม่มีคำสั่งเดียวจะซับซ้อนมาก แต่ความบ้าคลั่งอื่น ๆ ของ x86 ก็ยังคงอยู่ที่นั่น

ตัวอย่างเช่น: การเลื่อนไปทางซ้าย / ขวาปล่อยให้แฟล็ก Overflow ไม่ได้กำหนดไว้เว้นแต่จำนวนกะจะเป็นหนึ่งในกรณีของ = การตรวจจับการลงชื่อล้นตามปกติ ความบ้าคลั่งที่คล้ายกันสำหรับการหมุน อย่างไรก็ตามคำแนะนำ RISC ที่เปิดเผยสามารถให้การเปลี่ยนแปลงแบบไม่ใช้แฟล็กและอื่น ๆ (อนุญาตให้ใช้ uops เพียงหนึ่งหรือสองตัวที่มักจะเข้าสู่คำสั่ง x86 ที่ซับซ้อน) ดังนั้นนี่จึงไม่ถือเป็นข้อโต้แย้งหลัก

หากคุณกำลังจะสร้างตัวถอดรหัสใหม่ทั้งหมดสำหรับ RISC ISA คุณสามารถให้มันเลือกและเลือกส่วนของคำสั่ง x86 เพื่อแสดงเป็นคำแนะนำ RISC สิ่งนี้ช่วยลดความเชี่ยวชาญ x86 ของคอร์ได้บ้าง

การเข้ารหัสคำสั่งอาจไม่เป็นขนาดคงที่เนื่องจาก uops เดียวสามารถเก็บข้อมูลได้มาก ข้อมูลมากกว่าที่สมเหตุสมผลหากอินส์ทั้งหมดมีขนาดเท่ากัน uop แบบไมโครฟิวชั่นเดียวสามารถเพิ่ม 32 บิตได้ทันทีและตัวถูกดำเนินการหน่วยความจำที่ใช้โหมดการกำหนดแอดเดรสที่มีการลงทะเบียน 2 ตัวและการกระจัด 32 บิต (ใน SnB และใหม่กว่ามีเพียงโหมดการลงทะเบียนครั้งเดียวเท่านั้นที่สามารถไมโครฟิวส์กับตัวเลือก ALU)

uops มีขนาดใหญ่มากและไม่คล้ายกับคำสั่ง ARM ที่มีความกว้างคงที่มากนัก ชุดคำสั่ง 32 บิตที่มีความกว้างคงที่สามารถโหลดได้ครั้งละ 16 บิตในทันทีดังนั้นการโหลดแอดเดรส 32 บิตจึงต้องใช้คู่โหลดทันทีครึ่งต่ำ / โหลดสูงทันที x86 ไม่จำเป็นต้องทำเช่นนั้นซึ่งช่วยให้ไม่น่ากลัวด้วยการลงทะเบียน GP เพียง 15 เครื่องที่จำกัดความสามารถในการรักษาค่าคงที่ในการลงทะเบียน (15 เป็นความช่วยเหลือที่ยิ่งใหญ่ในการลงทะเบียน 7 รายการ แต่การเพิ่มขึ้นเป็นสองเท่าอีกครั้งเป็น 31 ช่วยให้น้อยลงฉันคิดว่าการจำลองบางอย่างที่พบ RSP มักไม่ใช่จุดประสงค์ทั่วไปดังนั้นจึงเหมือนกับการลงทะเบียน 15 GP และสแต็กมากกว่า)

TL; DR สรุป:

อย่างไรก็ตามคำตอบนี้ลงไปที่ "ชุดคำสั่ง x86 น่าจะเป็นวิธีที่ดีที่สุดในการตั้งโปรแกรม CPU ที่ต้องสามารถเรียกใช้คำสั่ง x86 ได้อย่างรวดเร็ว" แต่หวังว่าจะช่วยให้เข้าใจเหตุผลได้บ้าง

รูปแบบ uop ภายในใน front-end เทียบกับ back-end

ดูเพิ่มเติมไมโครฟิวชั่นและโหมดการกำหนดแอดเดรสสำหรับกรณีหนึ่งที่มีความแตกต่างกันในสิ่งที่รูปแบบ front-end กับ back-end uop สามารถแสดงบน CPU ของ Intel

เชิงอรรถ 1 : มีการลงทะเบียน "ซ่อน" บางรายการเพื่อใช้เป็นจังหวะโดยไมโครโค้ด รีจิสเตอร์เหล่านี้ถูกเปลี่ยนชื่อเช่นเดียวกับรีจิสเตอร์สถาปัตยกรรม x86 ดังนั้นคำสั่ง multi-uop จึงสามารถดำเนินการนอกลำดับได้

เช่นxchg eax, ecxใน CPU ของ Intel ถอดรหัส 3 UOPs ( ทำไม? ) และเดาที่ดีที่สุดของเราคือว่าเหล่านี้เป็น MOV เหมือน UOPs tmp = eax; ecx=eax ; eax=tmp;ที่ทำ ตามลำดับนั้นเนื่องจากฉันวัดเวลาแฝงของทิศทาง dst-> src ที่ ~ 1 รอบเทียบกับ 2 สำหรับวิธีอื่น และการย้ายเหล่านี้ไม่เหมือนกับmovคำแนะนำทั่วไป ดูเหมือนว่าพวกเขาจะไม่ได้เป็นผู้สมัครสำหรับการกำจัดการเคลื่อนที่แบบศูนย์เวลาแฝง

ดูเพิ่มเติมhttp://blog.stuffedcow.net/2013/05/measuring-rob-capacity/สำหรับการกล่าวถึงการพยายามที่จะทดลองวัดขนาด PRF และมีการบัญชีสำหรับการลงทะเบียนทางกายภาพใช้ในการเก็บรัฐสถาปัตยกรรมรวมทั้งการลงทะเบียนที่ซ่อนอยู่

ในส่วนหน้าหลังตัวถอดรหัส แต่ก่อนที่จะเกิดปัญหา / เปลี่ยนชื่อขั้นตอนที่เปลี่ยนชื่อรีจิสเตอร์ลงในไฟล์รีจิสเตอร์ฟิสิคัลรูปแบบ uop ภายในจะใช้หมายเลขรีจิสเตอร์ที่คล้ายกับ x86 reg แต่มีพื้นที่สำหรับจัดการรีจิสเตอร์ที่ซ่อนอยู่เหล่านี้

รูปแบบ uop มีความแตกต่างกันบ้างภายในแกนที่ไม่ได้รับคำสั่ง (ROB และ RS) หรือที่เรียกว่า back-end (หลังจากขั้นตอนปัญหา / เปลี่ยนชื่อ) ไฟล์ลงทะเบียนฟิสิคัล int / FP แต่ละไฟล์มี 168 รายการใน Haswellดังนั้นแต่ละฟิลด์ register ใน uop จะต้องกว้างพอที่จะจัดการกับจำนวนมากได้

เนื่องจากการเปลี่ยนชื่อมีอยู่ใน HW เราจึงน่าจะดีกว่าที่จะใช้แทนการป้อนคำแนะนำที่กำหนดเวลาไว้แบบคงที่โดยตรงไปยังส่วนหลัง ดังนั้นเราจะต้องทำงานกับชุดรีจิสเตอร์ที่มีขนาดใหญ่เท่ากับการลงทะเบียนสถาปัตยกรรม x86 + ไมโครโค้ดจังหวะไม่เกินนั้น

ส่วนหลังได้รับการออกแบบมาเพื่อทำงานร่วมกับการเปลี่ยนชื่อส่วนหน้าเพื่อหลีกเลี่ยงอันตรายจาก WAW / WAR ดังนั้นเราจึงไม่สามารถใช้งานได้เหมือนกับ CPU ตามลำดับแม้ว่าเราจะต้องการก็ตาม ไม่มีลูกโซ่เพื่อตรวจจับการอ้างอิงเหล่านั้น ที่จัดการโดยปัญหา / เปลี่ยนชื่อ

อาจจะเรียบร้อยถ้าเราสามารถป้อน uops เข้าไปในส่วนหลังโดยไม่มีปัญหาคอขวด / เปลี่ยนชื่อขั้นตอน (จุดที่แคบที่สุดในท่อส่งของ Intel สมัยใหม่เช่น 4-wide บน Skylake เทียบกับ 4 ALU + 2 load + 1 เก็บพอร์ตใน ส่วนหลัง) แต่ถ้าคุณทำเช่นนั้นฉันไม่คิดว่าคุณสามารถตั้งเวลาโค้ดแบบคงที่เพื่อหลีกเลี่ยงการลงทะเบียนซ้ำและดำเนินการตามผลลัพธ์ที่ยังคงต้องการหากการพลาดแคชหยุดการโหลดเป็นเวลานาน

ดังนั้นเราจึงจำเป็นต้องป้อน uops ให้กับปัญหา / เปลี่ยนชื่อสเตจอาจจะข้ามการถอดรหัสเท่านั้นไม่ใช่ uop cache หรือ IDQ จากนั้นเราจะได้รับ OoO exec ตามปกติด้วยการตรวจจับอันตราย ตารางการจัดสรรการลงทะเบียนได้รับการออกแบบมาเพื่อเปลี่ยนชื่อ 16 + จำนวนเต็มสองสามรายการลงทะเบียนเป็น PRF จำนวนเต็ม 168 รายการ เราไม่สามารถคาดหวังให้ HW เปลี่ยนชื่อชุดของการลงทะเบียนแบบลอจิคัลที่มีขนาดใหญ่ขึ้นเป็นจำนวนเดียวกัน ซึ่งจะใช้ RAT ที่ใหญ่กว่า

ทำไมพวกเขาไม่อนุญาตให้เรารวบรวมโปรแกรมดังนั้นพวกเขาจะข้ามคำสั่ง CISC และใช้ RISC core โดยตรง

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