Câu hỏi Tại sao Intel ẩn lõi RISC nội bộ trong bộ xử lý của họ?


Bắt đầu với Pentium Pro (vi kiến ​​trúc P6), Intel đã thiết kế lại bộ vi xử lý của nó và sử dụng lõi RISC bên trong theo hướng dẫn CISC cũ. Vì Pentium Pro tất cả các lệnh CISC được chia thành các phần nhỏ hơn (uops) và sau đó được thực thi bởi lõi RISC.

Lúc đầu nó đã được rõ ràng cho tôi rằng Intel đã quyết định ẩn mới kiến ​​trúc nội bộ và lực lượng lập trình để sử dụng "vỏ CISC". Nhờ vào quyết định này, Intel có thể thiết kế lại hoàn toàn kiến ​​trúc vi xử lý mà không phá vỡ tính tương thích, nó hợp lý.

Tuy nhiên tôi không hiểu một điều, tại sao Intel vẫn giữ một hướng dẫn RISC nội bộ được thiết lập ẩn trong nhiều năm? Tại sao họ không để các lập trình viên sử dụng các lệnh RISC như sử dụng các lệnh CISC cũ x86 được thiết lập?

Nếu Intel giữ khả năng tương thích ngược quá lâu (chúng ta vẫn có chế độ 8086 ảo bên cạnh chế độ 64 bit), Tại sao chúng không cho phép chúng ta biên dịch chương trình để chúng bỏ qua các chỉ lệnh CISC và sử dụng lõi RISC trực tiếp? Điều này sẽ mở ra cách tự nhiên để từ bỏ các lệnh x86 được thiết lập, hiện không còn được dùng nữa (đây là lý do chính tại sao Intel quyết định sử dụng lõi RISC bên trong, phải không?).

Nhìn vào dòng sản phẩm Core i 'mới của Intel mà tôi thấy, chúng chỉ mở rộng các hướng dẫn của CISC khi cài đặt thêm AVX, SSE4 và các thiết bị khác.


76
2018-04-27 15:27


gốc




Các câu trả lời:


Không, tập lệnh x86 chắc chắn không được chấp nhận. Nó là phổ biến hơn bao giờ hết. Lý do Intel sử dụng một tập hợp các hướng dẫn vi mô giống RISC trong nội bộ là vì chúng có thể được xử lý hiệu quả hơn.

Vì vậy, một CPU x86 hoạt động bằng cách có một bộ giải mã khá nặng trong giao diện người dùng, nó chấp nhận các lệnh x86 và chuyển đổi chúng thành một định dạng nội bộ được tối ưu hóa, mà backend có thể xử lý.

Đối với việc hiển thị định dạng này cho các chương trình "bên ngoài", có hai điểm:

  • nó không phải là một định dạng ổn định. Intel có thể thay đổi nó giữa các mô hình CPU để phù hợp nhất với kiến ​​trúc cụ thể. Điều này cho phép họ tối đa hóa hiệu quả, và lợi thế này sẽ bị mất nếu họ phải giải quyết trên một định dạng hướng dẫn cố định, ổn định để sử dụng nội bộ cũng như sử dụng bên ngoài.
  • không có gì để đạt được bằng cách làm nó. Với CPU lớn, phức tạp ngày nay, bộ giải mã là một phần tương đối nhỏ của CPU. Việc giải mã các lệnh x86 làm cho phức tạp hơn, nhưng phần còn lại của CPU không bị ảnh hưởng, vì vậy tổng thể, chỉ có rất ít thu được, đặc biệt là vì lối vào x86 vẫn phải ở đó, để thực thi mã "kế thừa" . Vì vậy, bạn thậm chí sẽ không lưu các bóng bán dẫn hiện đang được sử dụng trên lối vào x86.

Đây không phải là một sự sắp xếp hoàn hảo, nhưng chi phí là khá nhỏ, và đó là một lựa chọn tốt hơn nhiều so với việc thiết kế CPU để hỗ trợ hai các tập lệnh hoàn toàn khác nhau. (Trong trường hợp đó, họ có thể sẽ phát minh ra một thứ ba thiết lập các micro-op để sử dụng nội bộ, chỉ vì chúng có thể được tinh chỉnh một cách tự do để phù hợp nhất với kiến ​​trúc bên trong của CPU)


78
2018-04-27 15:38



Điểm tốt. RISC là một kiến ​​trúc cốt lõi tốt, nơi GOOD có nghĩa là chạy nhanh và có thể triển khai đúng, và ISA x86 có lịch sử kiến ​​trúc CISC, chỉ đơn thuần là một tập lệnh với lịch sử lớn và sự giàu có tuyệt vời của phần mềm nhị phân. , cũng như hiệu quả cho việc lưu trữ và xử lý. Nó không phải là một vỏ CISC, đó là ISA tiêu chuẩn của ngành công nghiệp defacto. - Warren P
@ Warren: về phần cuối cùng, tôi thực sự không nghĩ như vậy. A được thiết kế tốt Tập lệnh CISC hiệu quả hơn về mặt lưu trữ, vâng, nhưng từ một vài thử nghiệm tôi đã thấy, lệnh x86 "trung bình" là khoảng 4,3 byte rộng, đó là hơn hơn bình thường trong kiến ​​trúc RISC. x86 mất rất nhiều hiệu quả lưu trữ bởi vì nó được thiết kế và mở rộng một cách hời hợt trong nhiều năm. Nhưng như bạn nói, sức mạnh chính của nó là lịch sử và số lượng lớn mã nhị phân hiện có. - jalf
mặc dù đó chỉ là một bài kiểm tra mà tôi đã đọc vài năm trước, vì vậy tôi không chắc nó chính xác như thế nào. :) - jalf
Tôi không nói đó là "CISC được thiết kế tốt", chỉ là "lịch sử khổng lồ". Các bộ phận TỐT là bộ phận thiết kế chip RISC. - Warren P
@jalf - Từ kiểm tra các tệp nhị phân thực tế, kích thước lệnh trong x86 là trung bình khoảng 3 byte. Dĩ nhiên có nhiều hướng dẫn dài hơn, nhưng những hướng dẫn nhỏ hơn có khuynh hướng thống trị trong sử dụng thực tế. - srking


Nếu Intel giữ khả năng tương thích ngược   quá lâu (chúng tôi vẫn có ảo   Chế độ 8086 bên cạnh chế độ 64 bit), Tại sao   họ không cho phép chúng tôi biên dịch chương trình   vì vậy họ sẽ bỏ qua hướng dẫn CISC   và sử dụng lõi RISC trực tiếp? Điều này sẽ   mở cách tự nhiên để từ từ bỏ x86   hướng dẫn được đặt, không được dùng nữa   ngày nay (đây là lý do chính tại sao   Intel quyết định sử dụng lõi RISC bên trong,   đúng?).

Bạn cần phải nhìn vào góc độ kinh doanh của điều này. Intel đã thực sự cố gắng tránh xa x86, nhưng đó là ngỗng đẻ trứng vàng cho công ty. XScale và Itanium không bao giờ đến gần mức độ thành công mà doanh nghiệp x86 cốt lõi của họ có.

Những gì bạn đang yêu cầu cơ bản là cho Intel để slit cổ tay của mình để đổi lấy các fuzzies ấm áp từ các nhà phát triển. Phá hoại x86 không phải là lợi ích của họ. Bất cứ điều gì làm cho nhiều nhà phát triển không phải chọn nhắm mục tiêu x86 làm xói mòn x86. Điều đó, đến lượt nó, làm xói mòn chúng.


15
2018-04-27 15:43



Đúng vậy, khi Intel cố gắng làm điều này (Itanium), thị trường chỉ phản ứng với một cái nhún vai. - Warren P


Câu trả lời thực sự rất đơn giản.

Yếu tố chính đằng sau việc thực hiện bộ vi xử lý RISC là giảm độ phức tạp và tăng tốc độ. Nhược điểm của RISC là mật độ lệnh giảm, điều đó có nghĩa là cùng một mã được thể hiện trong RISC như định dạng cần nhiều hướng dẫn hơn mã CISC tương đương.

Tác dụng phụ này không có nghĩa là nhiều nếu CPU của bạn chạy ở cùng tốc độ với bộ nhớ, hoặc ít nhất là nếu cả hai chạy với tốc độ tương tự.

Hiện tại tốc độ bộ nhớ so với tốc độ CPU cho thấy sự khác biệt lớn về đồng hồ. CPU hiện tại đôi khi nhanh gấp năm lần bộ nhớ chính.

Trạng thái của công nghệ này ưu tiên một mã dày đặc hơn, một cái gì đó mà CISC cung cấp.

Bạn có thể lập luận rằng cache có thể tăng tốc CPU RISC. Nhưng cùng có thể nói về CISC cpus.

Bạn nhận được một cải thiện tốc độ lớn hơn bằng cách sử dụng CISC và cache hơn RISC và cache, vì cùng một bộ nhớ cache kích thước có hiệu lực hơn trên mã mật độ cao mà CISC cung cấp.

Một hiệu ứng phụ khác là RISC khó thực hiện trình biên dịch hơn. Nó dễ dàng hơn để tối ưu hóa các trình biên dịch cho CPU CISC. v.v.

Intel biết họ đang làm gì.

Điều này đúng là ARM có chế độ mật độ mã cao hơn được gọi là Thumb.


13
2018-03-23 23:07



Ngoài ra một lõi RISC nội bộ làm giảm số lượng transistor trên một CPU CISC. Thay vì dây cứng mọi hướng dẫn CISC, bạn có thể sử dụng microcode để thực thi chúng. Điều này dẫn đến việc tái sử dụng các hướng dẫn mã hóa RISC cho các hướng dẫn CISC khác nhau do đó sử dụng ít diện tích chết hơn. - Sil


Đáp án đơn giản. Intel không phát triển CPU cho nhà phát triển! Họ đang phát triển chúng cho những người tạo ra thu mua quyết định, mà BTW, là những gì mọi công ty trên thế giới đều làm!

Intel từ lâu đã thực hiện cam kết rằng, (trong lý do, tất nhiên), CPU của họ sẽ vẫn tương thích ngược. Mọi người muốn biết rằng, khi họ mua một máy tính dựa trên Intel mới, tất cả các phần mềm hiện tại của họ sẽ chạy chính xác giống như trên máy tính cũ của họ. (Mặc dù, hy vọng, nhanh hơn!)

Hơn nữa, Intel biết chính xác cam kết quan trọng như thế nào, bởi vì họ đã từng cố gắng đi theo một cách khác. Chính xác có bao nhiêu người làm bạn biết với một CPU Itanium?!?

Bạn có thể không thích nó, nhưng đó là một quyết định, để ở lại với x86, là những gì làm cho Intel một trong những tên doanh nghiệp dễ nhận biết nhất trên thế giới!


4
2017-10-10 00:27



Tôi không đồng ý với sự đánh giá rằng các bộ vi xử lý của Intel không thân thiện với nhà phát triển. Khi đã lập trình PowerPC và x86 trong nhiều năm, tôi đã tin rằng CISC thân thiện với lập trình viên hơn nhiều. (Tôi làm việc cho Intel bây giờ, nhưng tôi đã quyết định về vấn đề này trước khi tôi được thuê.) - Jeff
@ Jeff Đó không phải là ý định của tôi chút nào! Câu hỏi đặt ra là, tại sao Intel không mở tập lệnh RISC để các nhà phát triển có thể sử dụng nó. Tôi không nói bất cứ điều gì về x86 không thân thiện với nhà phát triển. Những gì tôi nói là các quyết định như thế này không được quyết định với các nhà phát triển trong tâm trínhưng, đúng hơn, là những quyết định kinh doanh nghiêm túc. - geo


Câu trả lời của jalf bao gồm hầu hết các lý do, nhưng có một chi tiết thú vị mà nó không đề cập đến: lõi nội bộ giống RISC không được thiết kế để chạy một bộ lệnh như ARM / PPC / MIPS. Thuế x86 không chỉ được trả trong các bộ giải mã có sức mạnh, mà ở mức độ nào đó trong toàn bộ lõi. tức là không chỉ mã hóa lệnh x86; đó là mọi hướng dẫn với ngữ nghĩa kỳ lạ.

Hãy giả vờ rằng Intel đã tạo ra một chế độ hoạt động, nơi dòng lệnh là một cái gì đó khác với x86, với các hướng dẫn ánh xạ trực tiếp hơn đến các uops. Chúng ta cũng giả sử rằng mỗi mô hình CPU có ISA riêng cho chế độ này, vì vậy chúng vẫn tự do thay đổi nội bộ khi chúng thích và phơi bày chúng với một số lượng tối thiểu các bóng bán dẫn để giải mã lệnh của định dạng thay thế này.

Có lẽ bạn vẫn chỉ có cùng số lượng thanh ghi, ánh xạ tới trạng thái kiến ​​trúc x86, vì vậy các hệ điều hành x86 có thể lưu / khôi phục nó trên các thiết bị chuyển mạch ngữ cảnh mà không cần sử dụng bộ hướng dẫn CPU cụ thể. Điều này có lẽ không quá khó, vì phần cứng đổi tên đăng ký đã tồn tại. (Uops nội bộ thực sự tham chiếu đến tệp đăng ký vật lý, nhưng ISA RISC giả định của chúng ta sẽ không phải).


Nếu chúng ta chỉ có bộ giải mã thay thế mà không có thay đổi đối với các giai đoạn đường ống sau này (đơn vị thực hiện), ISA này sẽ vẫn có nhiều lập dị x86.  Nó sẽ không phải là một kiến ​​trúc RISC rất đẹp. Không có hướng dẫn đơn lẻ nào sẽ rất phức tạp, nhưng một số sự điên rồ khác của x86 vẫn sẽ ở đó.

Ví dụ: các thay đổi bên trái / phải để lại cờ Tràn không xác định, trừ khi số lần dịch chuyển là một, trong trường hợp OF = phát hiện tràn qua đã ký thông thường. Tương tự như điên cuồng cho quay. Tuy nhiên, các hướng dẫn RISC tiếp xúc có thể cung cấp các thay đổi ít cờ hơn và nhiều hơn nữa (cho phép sử dụng chỉ một hoặc hai trong số nhiều uops thường đi vào một số lệnh x86 phức tạp). Vì vậy, điều này không thực sự giữ lên như đối số chính.

Nếu bạn định tạo một bộ giải mã hoàn toàn mới cho một ISA RISC, bạn có thể chọn nó và chọn các phần của các lệnh x86 được hiển thị như các lệnh RISC. Điều này giúp giảm thiểu sự chuyên môn hóa x86 của lõi.


Mã hóa lệnh có thể không có kích thước cố định, vì các uops đơn có thể chứa rất nhiều dữ liệu. Nhiều dữ liệu hơn có ý nghĩa nếu tất cả các insns có cùng kích thước. Một uop vi hợp nhất duy nhất có thể thêm 32 bit ngay lập tức và toán hạng bộ nhớ sử dụng chế độ địa chỉ với 2 thanh ghi và chuyển vị 32 bit. (Trong SnB và sau đó, chỉ có các chế độ địa chỉ đăng ký đơn có thể kết hợp vi mô với các phép ALU).

uops là rất lớn, và không phải rất giống với cố định chiều rộng ARM hướng dẫn. Một bộ hướng dẫn 32 bit cố định chiều rộng chỉ có thể tải 16bit ngay lập tức tại một thời điểm, do đó, việc tải một địa chỉ 32bit yêu cầu một cặp nửa thấp ngay lập tức / tải trọng cao ngay lập tức. x86 không cần phải làm điều đó, điều này sẽ giúp nó không quá khủng khiếp khi chỉ có 15 thanh ghi GP giới hạn khả năng giữ các hằng số xung quanh trong thanh ghi. (15 là một trợ giúp lớn hơn 7 thanh ghi, nhưng tăng gấp đôi lần nữa lên 31 sẽ giúp ích rất nhiều, tôi nghĩ rằng một số mô phỏng được tìm thấy. RSP thường không phải là mục đích chung, vì vậy nó giống như 15 thanh ghi GP và ngăn xếp).


Tóm tắt TL, DR:

Dù sao, câu trả lời này tóm tắt thành "tập lệnh x86 có lẽ là cách tốt nhất để lập trình một CPU có khả năng chạy các lệnh x86 một cách nhanh chóng", nhưng hy vọng làm sáng tỏ một số lý do.


2
2017-09-30 13:00





Tại sao họ không cho phép chúng tôi biên dịch chương trình để họ sẽ bỏ qua các chỉ dẫn CISC và sử dụng lõi RISC trực tiếp?

Ngoài các câu trả lời trước, lý do khác là phân khúc thị trường. Một số hướng dẫn được cho là được thực hiện trong microcode thay vì trong phần cứng, vì vậy cho phép bất cứ ai thực thi các vi điều khiển tùy ý có thể làm suy yếu việc bán cpus mới với các lệnh CISC mới "có hiệu suất cao hơn".


-3
2017-10-15 15:49



Tôi không nghĩ rằng điều này có ý nghĩa. RISC có thể sử dụng microcode, đặc biệt nếu chúng ta đang nói về việc chỉ thêm bộ giải mã RISC vào giao diện x86. - Peter Cordes
Điều đó vẫn sai. Các hướng dẫn mới AES (và các hướng dẫn SHA sắp tới) và các thứ khác như PCLMULQDQ có phần cứng chuyên dụng. Trên Haswell, AESENC giải mã thành một uop đơn (agner.org/optimize), do đó, nó chắc chắn không phải microcoded ở tất cả. (Bộ giải mã chỉ cần kích hoạt trình tự mã hóa ROM vi mã để biết hướng dẫn giải mã cho hơn 4 người chết.) - Peter Cordes
Bạn nói đúng rằng một số hướng dẫn mới chỉ sử dụng chức năng hiện có theo cách không có sẵn với hướng dẫn x86. Một ví dụ tốt sẽ là BMI2 SHLX, cho phép bạn thực hiện các thay đổi về số lượng thay đổi mà không đặt số đếm trong CL và không phát sinh thêm số tiền cần thiết để xử lý ngữ nghĩa cờ x86 crappy (cờ không được sửa đổi nếu số lần dịch là 0, vì vậy SHL r/m32, cl có một phụ thuộc đầu vào trên CỜ, và giải mã thành 3 uops trên Skylake. Mặc dù vậy, nó chỉ là 1 uop trên Core2 / Nehalem, theo thử nghiệm của Agner Fog.) - Peter Cordes
Cảm ơn bạn đã bình luận của bạn. - KOLANICH