Tại sao MIPS bao gồm shamt và phân biệt func / opcode?

Tôi bối rối về lý do tại sao các nhà thiết kế MIPS sẽ bao gồm 5 bit dành riêng cho việc dịch chuyển và có các bit opcode và hàm riêng biệt.

Bởi vì MIPS rất RISC, tôi cho rằng việc chuyển đổi sẽ được thực hiện theo một vài hướng dẫn, vì vậy 5 bit đó có vẻ như đang lãng phí không gian khi chúng có thể được đưa vào ngay lập tức. Tôi giả sử rằng opcodes và func là riêng biệt để phân biệt các hướng dẫn loại R và I, nhưng điều này có thể được thực hiện bằng cách mở rộng opcode thêm 1 bit. Với cả hai hướng dẫn loại R này có thể dài 22 bit. Điều này sẽ không hoạt động nếu các hướng dẫn loại I và J muốn giữ địa chỉ và địa chỉ ngay lập tức, nhưng cả hai dường như không cần thiết.

Có một vài sự đánh đổi khác nhau đang diễn ra ở đây.

Đầu tiên, chúng tôi muốn các hướng dẫn có chiều rộng cố định (32 bit). Điều này đảm bảo rằng các hướng dẫn là khối bộ đệm và trang được căn chỉnh để đơn giản hóa bộ đệm và kiểm tra sự hiện diện của trang và bộ đệm.

Thứ hai, chúng tôi muốn các trường lệnh khác nhau ( opcode/ source regs/ immediates) có chiều rộng cố định và vị trí cố định. Điều này làm cho chúng nhanh hơn / ít logic hơn để giải mã và chúng cần thiết trong giai đoạn đầu của đường ống. (Thanh destinationghi không cần thiết cho đến khi kết thúc đường ống, vì vậy nó có thể ở các vị trí Rvà Ihướng dẫn khác nhau .) Vị trí và độ rộng của functiontrường ít quan trọng hơn vì cần kiểm soát chức năng của ALU, nhưng đó là trong giai đoạn đường ống thứ ba, vì vậy bạn có một ít thời gian để làm việc với nó nếu cần.

IJJ$2^{28}$$2^{28}$Ihướng dẫn cũng là tốt đẹp cho các nhà văn trình biên dịch / liên kết. (Trên SPARC, trong đó trường ngay lập tức chỉ có 12 bit, họ phải thêm toàn bộ load-highlớp hướng dẫn đặc biệt với 20 bit ngay lập tức.)

$2^6=64$JRI

Nhưng điều đó để lại một số phòng ngọ nguậy với các Rhướng dẫn. Ngoài opcode 6 bit, các bit này chỉ cần 15 bit bổ sung cho đặc tả thanh ghi, để lại 11 bit cho opcode mở rộng và / hoặc lượng dịch chuyển.

Bạn nên nghĩ về functiontrường như là một opcode mở rộng cho Rhướng dẫn. Chỉ có một Rmã lệnh, nhưng có 64 mã khác nhau functionsmà Rlệnh có thể thực hiện.

Được chứ. Chúng tôi có 60 Ihướng dẫn khác nhau và 64 Rhướng dẫn khác nhau , vậy chúng tôi nên đặt ca làm việc ngay lập tức ở đâu?

Chà, không chỉ có ít Ihướng dẫn hơn , mà còn có nhiều cách chúng ta muốn làm với I hướng dẫn. Hãy nhớ lại rằng tất cả các hướng dẫn chi nhánh cần phải là Ihướng dẫn bởi vì chúng có phần bù (tương đối) ngay lập tức. Ngoài ra tất cả các hướng dẫn tải và lưu trữ là Iđịnh dạng trên MIPS. Và cuối cùng chúng ta cần hướng dẫn tải trên ngay lập tức để trở thành một Ihướng dẫn. Không chỉ vậy, nhưng các Rhướng dẫn vẫn có thêm 5 bit không được sử dụng, (đó là những gì chúng ta cần cho sự thay đổi ngay lập tức trên kiến ​​trúc này), vì vậy điều này mang lại sự khuyến khích hơn nữa để biến dịch chuyển thành các Rhướng dẫn đặc biệt (kỳ lạ) .

Rất nhiều trong số những quyết định này mang tính nghệ thuật hơn khoa học, nhưng có một logic cơ bản có thể nhận ra. Mục tiêu chính là không làm cho số lượng hướng dẫn càng nhỏ càng tốt, đó là làm cho hiệu suất caođường ống phù hợp trên một con chip duy nhất (để các công ty nhỏ, như MIPS và Sun vào những năm 1980, có thể cạnh tranh với IBM và DEC). (Cái tên RISC, được phát minh bởi David Patterson, có phần đáng tiếc. Nó gây chú ý vì nó dễ thương, không phải vì "hướng dẫn rút gọn" là một mô tả chính xác về những gì các kiến ​​trúc MIPS và SPARC đã thực sự cố gắng thực hiện.) Vì vậy, bạn muốn hướng dẫn độ rộng cố định (và tương đối nhỏ để bạn có hành vi I-cache tốt hơn) để tìm nạp, phân trang và giải mã đơn giản và nhanh hơn. Bạn muốn các phần của hướng dẫn cần được giải mã sớm (opcode, hai thanh ghi nguồn và ký hiệu được gia hạn ngay lập tức) có chiều rộng cố định và ở vị trí cố định. Bạn muốn ngay lập tức càng lâu càng tốt, và bạn muốn càng nhiều loại hướng dẫn khác nhau sẽ phù hợp, với tất cả những ràng buộc khác.

Để hiểu các định dạng hướng dẫn MIPS I, bạn cần hiểu đường ống MIPS và cũng nghĩ lại về công nghệ triển khai CPU vào khoảng năm 1985. Nếu bạn nhìn vào sơ đồ (bạn biết cái này), bạn sẽ thấy việc đọc tệp đăng ký nằm trong Giai đoạn ID, ngay sau IF.

Với mục đích của hướng dẫn loại R, giai đoạn ID cần thực hiện các tác vụ sau:

1. Xác định rằng nó thực sự là một lệnh loại R.
2. Nếu vậy, hãy báo cho tệp đăng ký để tải các giá trị từ các thanh ghi.

Với mục đích của cuộc thảo luận này, đây là nhiệm vụ đầu tiên mà bạn phải suy nghĩ. Nếu có rất nhiều công việc giải mã hướng dẫn mà bạn phải thực hiện để thậm chí giải quyết nếu bạn cần bất kỳ giá trị nào từ các thanh ghi, điều này làm tăng độ trễ trước khi bạn có thể bắt đầu đọc đăng ký. Nó cũng làm tăng sự phức tạp của giai đoạn ID. Bằng cách đặt trước một mã opcode cho tất cả các hướng dẫn loại R, bạn giữ mức độ phức tạp ở mức tối thiểu.

Có vẻ hơi lạ khi bạn dành năm bit chỉ để thay đổi. Tôi có thể nghĩ về một vài lời giải thích có thể. Một là nó đơn giản hóa việc định tuyến (năm bit đó LUÔN được đưa thẳng vào tệp đăng ký, năm bit đó LUÔN được đưa vào bộ dịch chuyển thùng, sáu bit đó LUÔN LUÔN được chuyển qua ALU để xác định chức năng nào sẽ thực hiện).

Họ có thể đã nghĩ đến việc giới thiệu các hướng dẫn thay đổi kết hợp giữa trái và thêm trong tương lai. Điều này có lẽ sẽ có dạng:

$d = $s + ($t << shamt)

$2^s+1$$s$

Ngày nay, có lẽ chúng ta sẽ không nghĩ hai lần về việc có một giai đoạn giải mã phức tạp hơn, đặc biệt là khi các truy cập tệp đăng ký có xu hướng xảy ra sau đó trong đường ống của một CPU siêu lớp điển hình. Nhiều CPU hiện đại thậm chí còn thực hiện một số giải mã lệnh thô tại thời điểm một lệnh được chèn vào bộ đệm L1 . Bạn làm cho các dòng I-cache rộng hơn một vài bit để lưu trữ thông tin bổ sung (nhờ Định luật Moore, bạn có rất nhiều bóng bán dẫn bị lãng phí) để thực hiện giải mã lệnh "đúng" đơn giản và nhanh hơn.

Một lý do tại sao họ có thể muốn giữ trường opcode nhỏ nhất có thể là vì nó không phạt các hướng dẫn loại J quá mức. Như bạn có thể biết, hướng dẫn loại J sử dụng địa chỉ giả trực tiếp. Vì lợi ích của bất kỳ ai chơi cùng ở nhà, tôi sẽ giải thích ngắn gọn về nó.

Trường địa chỉ của lệnh loại J là 26 bit. Vì các hướng dẫn luôn được căn chỉnh 4 byte, bạn không cần lưu trữ hai bit có ý nghĩa ít nhất, điều đó có nghĩa là bạn thực sự có 28 bit địa chỉ. Tuy nhiên, không gian địa chỉ trong MIPS I là 32 bit. Vì vậy, bốn bit trên cùng của vị trí nhảy được lấy từ bộ đếm chương trình.

Điều này có nghĩa là bạn không thể trực tiếp nhảy đến một vị trí có bốn bit quan trọng nhất của vị trí PC khác nhau. Thay vào đó, bạn sẽ phải thực hiện một bước nhảy ba hướng đắt tiền hơn thông qua một thanh ghi đầu:

lui $r,target >> 16
    ori $r,$r,target & 0xFFFF
    jr $r

Điều đó không quá tệ ngày hôm nay, nhưng vào năm 1985, đó là rất nhiều chu kỳ đồng hồ.

Ăn cắp một chút từ trường địa chỉ sẽ làm giảm phạm vi hiệu quả của một cú nhảy trực tiếp hơn nữa. Bạn có thể thấy làm thế nào điều này có thể là một cái giá quá cao để trả.