Làm thế nào để thiết kế hiệu quả opcode cho CPU?


12

Tôi đang xây dựng một CPU 16 bit đơn giản trong Logisim và sẵn sàng ALU và các opcode mà tôi muốn có. Bây giờ tôi rất khó tìm được mã hóa đúng cho các lệnh để các chuỗi con khác nhau (ví dụ logic, số học) không cần tất cả các dây điều khiển (xây dựng mã hóa) làm đầu vào, nhưng càng ít càng tốt. Có bất kỳ chiến lược hoặc phương pháp nào giúp thiết kế opcode hiệu quả không?

thx trước


1
Xây dựng ALU của bạn trước và xem nó cần dây điều khiển nào. Sau đó nối chúng trực tiếp vào thanh ghi "hướng dẫn hiện tại". Tương tự đối với logic điều khiển truy cập bộ nhớ và bất kỳ lớp opcodes chính nào khác. Sau đó sử dụng bất kỳ bit nào còn sót lại để chọn chuỗi con nào được kích hoạt.
dùng253751

1
Ngoài ra còn có bài báo gốc từ Ken Chapman về stHRachine lập trình 8 bit KCPSM hay còn gọi là PicoBlaze. Nó mô tả cách anh ta chọn hướng dẫn và thiết kế ISA. dc.uba.ar/materias/disfpga/2010/c2/descargas/ory
Paebbels

Câu trả lời:


9

Tôi nghĩ rằng đó là một cách tiếp cận tốt để nghiên cứu một số bộ hướng dẫn khác.

Một cái nhỏ sẽ là MSP430 từ TI, nó là Bộ xử lý 16 bit với khoảng 22 hướng dẫn.

http://www.physics.mcmaster.ca/phys3b06/MSP430/MSP430_Inocate_Set_Summary.pdf

Bạn cũng có thể xem xét các Atmel AVR, chúng cũng có một bộ hướng dẫn khá nhỏ.

Trong một dự án nhỏ của tôi, tôi đã cố gắng phát triển bộ xử lý 32 bit đơn giản trong VHDL với một bộ hướng dẫn nhỏ (14 hướng dẫn):

http://www.blog-tm.de/?p=80

Do thời gian rảnh hiện tại của tôi, nó không hoàn thành. Các hướng dẫn được thực hiện nhưng hai không được kiểm tra và có thể thiếu một số cờ trạng thái.


Nhưng tôi đã không tìm thấy thứ gì đó nơi tôi có thể thấy mã hóa thực tế là gì và tại sao nó được chọn là như thế này.
Benjoyo

Bạn có thể tìm thấy mã hóa Actuall trong repo: github.com/TM90/MISC_Processor/raw/master/Documentation/ ,. Lý do tôi chọn các bảng mã này theo cách logic trong bộ giải mã lệnh là tối thiểu.
TM90

7

Nghiên cứu (nhưng không lặp lại) phương pháp ARM để mã hóa hướng dẫn. Đó là định hướng rất nhiều tiền tố (như cách tiếp cận cây Huffman được đề xuất bởi Dzarda) và có tính thống nhất cao về mặt đăng ký chọn một phần của hướng dẫn.

Cách tiếp cận không đáng tin cậy nhưng đáng tin cậy là liệt kê tất cả các tín hiệu điều khiển mà bạn có, có thể sẽ nhiều hơn 16 bit, và sau đó cố gắng thực hiện tối thiểu hóa logic kiểu bản đồ Karnaugh trên chúng.


Tôi thực sự không hiểu ý bạn là gì bởi các tín hiệu điều khiển.
Benjoyo

Những gì tôi tìm thấy và thích về ARM là trường điều kiện, tôi sẽ bao gồm điều đó.
Benjoyo

Tín hiệu điều khiển là đầu vào cho các bộ ghép kênh khác nhau và cho phép dữ liệu trực tiếp giữa các bộ phận của CPU.
pjc50

Đối với kiến ​​trúc 16 bit, tôi không nghĩ mã hóa hướng dẫn của ARM là phù hợp. Mayby thumb2 là tốt hơn. Nhưng tôi thích cách mã hóa MIPS, đơn giản và dễ hiểu, mặc dù hơi lãng phí
phuclv

4

Có lần tôi đã thử làm CPU 4 bit với lõi có độ dài lệnh 8 bit trong Logisim. Kết thúc với một máy trạng thái đơn giản, hơn cả CPU, thực sự.

Những điều ngẫu nhiên để tìm kiếm

  • Cây Huffman
  • Độ dài cố định hoặc mã hóa biến?
  • Đây có phải là một thiết kế von Neumann với không gian địa chỉ duy nhất, hoặc theo phong cách Harvard với dữ liệu / chương trình riêng biệt?

Video tuyệt vời trên Computerphile về cây Huffman:

https://www.youtube.com/watch?v=umTbivyJoiI


Mã hóa Huffman sẽ không hoạt động đối với mã hóa có độ dài cố định, phải không?
Benjoyo

@Benjoyo Tôi có thể tưởng tượng một kịch bản với các bit dự phòng được sử dụng cho các biến thể của các hướng dẫn được sử dụng nhiều nhất, do đó cung cấp nhiều chức năng hơn.
Dzarda

Nhưng tôi không nhận được loại tối ưu hóa này mang lại. Nó không giúp tôi với thiết kế mạch. Mục tiêu khi sử dụng mã hóa Huffman cho opcode là gì?
Benjoyo

4

ISA tôi đã viết cho lớp đã từng có mã op 4 bit như vậy: 1XXX ALU instructions 01XX jump, jump register, call etc 001X branch not equal, branch equal zero 000X 0 - load, 1 - store

Thay vì là tối ưu nhất, đây là một trong những kiểu dễ dàng hơn để xây dựng / thiết kế cổng vì tín hiệu đầu vào của một bit có thể điều khiển hoàn toàn đường dẫn logic được thực hiện. Ngoài ra, bạn có thể Huffman Code các ký hiệu được sử dụng nhiều nhất của bạn và không đệm chúng để lấy mã op có độ dài cố định.


Loại tối ưu hóa này là những gì tôi đang tìm kiếm tại thời điểm này. Nhưng tôi có một opcode 5 bit và tôi đấu tranh với việc nhóm các lệnh lại với nhau để nó có ý nghĩa trong mạch.
Benjoyo

@Benjoyo bạn có thể có một loạt các hướng dẫn ALU khác với tập bit trên. Ngoài ra, phạm vi điều kiện nhảy của tôi khá yếu và hầu hết các nhánh bình thường sẽ cần hai hướng dẫn. Nói chung, tôi nghĩ về các loại như: Toán học / Kiểm soát / Bộ nhớ

3

Một điều bạn sẽ cần xem xét là liệu có cho phép bất kỳ hình thức hướng dẫn nhiều từ nào, hoặc bất cứ điều gì có thể "hành động" như một hướng dẫn nhiều từ; nếu bạn làm như vậy, thì bạn có thể muốn xem xét nên sử dụng các từ chỉ dẫn bổ sung theo hướng dẫn chính hay các từ tiền tố trước nó. Việc cho phép các tiền tố và các từ tiếp theo có thể làm tăng sự phức tạp của việc xử lý ngắt, nhưng nó có thể tránh sự cần thiết phải phù hợp với các hướng dẫn hiếm khi được sử dụng trong cùng một không gian opcode như các cách sử dụng thông thường.

Nếu các hướng dẫn được tìm nạp trên chu kỳ trước khi chúng thực thi, người ta có thể có một lệnh "nhánh có điều kiện", điều này sẽ làm cho từ lệnh tiếp theo bị bỏ qua hoặc nếu không thì nội dung của nó được chuyển trực tiếp vào bộ đếm chương trình; một thiết kế như vậy có thể tăng thêm độ phức tạp để gián đoạn trình tự, nhưng nó có thể giảm bớt nhu cầu sử dụng một phần lớn không gian opcode cho các hướng dẫn "nhánh", "nhảy" và "gọi", trong khi cho phép phạm vi điều kiện nhánh rộng hơn nhiều hơn là có thể Vì một nhánh được lấy thường sẽ yêu cầu một chu kỳ chết sau khi thực hiện lệnh đó bất kể địa chỉ đó đến từ đâu, có địa chỉ đến từ từ sau đã được tìm nạp nhưng sẽ không được thực hiện không tốn thêm bất kỳ chi phí nào thời gian.

Mặc dù việc di chuyển địa chỉ đích ra khỏi các hướng dẫn chi nhánh sẽ làm giảm bao nhiêu không gian opcode mà chúng ngấu nghiến, định dạng opcode 16 bit vẫn khá chặt chẽ. Sử dụng hướng dẫn tiền tố có thể giúp với điều đó. Ví dụ, nếu một người muốn có 32 thanh ghi, cho phép bất kỳ thanh ghi nào được chỉ định độc lập như source1, source2 và đích sẽ cần 15 bit trong opcode, cho phép tổng cộng hai lệnh. Không hữu ích lắm. Mặt khác, việc có thể sử dụng bất kỳ trong số 32 thanh ghi cho mỗi trong ba toán hạng sẽ là tốt. Người ta có thể cân bằng hai mục tiêu bằng cách có bất kỳ hoạt động ALU nào không có tiền tố sử dụng tám bit để thực hiện hai lựa chọn đăng ký một trong mười sáu, nhưng có một hoạt động ALU ngay sau tiền tố sử dụng một số bit trong tiền tố với tám từ hướng dẫn sau đây, để cho phép lựa chọn độc lập cả hai nguồn và đích từ toàn bộ 32. Các hướng dẫn sử dụng các thanh ghi trên sẽ mất hai từ / chu kỳ thay vì một, nhưng trong một số trường hợp, một sự đánh đổi như vậy có thể rất đáng giá. Khó khăn lớn nhất khi sử dụng tiền tố là người ta phải ngăn chặn sự xuất hiện giữa tiền tố và lệnh tiếp theo hoặc nếu không thì đảm bảo rằng nếu một ngắt xảy ra ở đó thì lệnh sau tiền tố vẫn sẽ sử dụng các thanh ghi bên phải [ví dụ: có chương trình -count lưu logic lưu trữ địa chỉ của lệnh không tiền tố cuối cùng được thực hiện]. nhưng trong một số trường hợp, một sự đánh đổi như vậy có thể rất đáng giá. Khó khăn lớn nhất khi sử dụng tiền tố là người ta phải ngăn chặn sự xuất hiện giữa tiền tố và lệnh tiếp theo hoặc nếu không thì đảm bảo rằng nếu một ngắt xảy ra ở đó thì lệnh sau tiền tố vẫn sẽ sử dụng các thanh ghi bên phải [ví dụ: có chương trình -count lưu logic lưu trữ địa chỉ của lệnh không tiền tố cuối cùng được thực hiện]. nhưng trong một số trường hợp, một sự đánh đổi như vậy có thể rất đáng giá. Khó khăn lớn nhất khi sử dụng tiền tố là người ta phải ngăn chặn sự xuất hiện giữa tiền tố và lệnh tiếp theo hoặc nếu không thì đảm bảo rằng nếu một ngắt xảy ra ở đó thì lệnh sau tiền tố vẫn sẽ sử dụng các thanh ghi bên phải [ví dụ: có chương trình -count lưu logic lưu trữ địa chỉ của lệnh không tiền tố cuối cùng được thực hiện].

Sử dụng các hướng dẫn nhiều từ sẽ làm cho một số khía cạnh của thiết kế trở nên khó khăn hơn, nhưng nó có thể làm giảm nhu cầu đưa ra các quyết định khó khăn khác.


0

Anh chàng này có các chi tiết tốt nhất để hiểu về phần cứng được mã hóa phần cứng của Bộ giải mã, giải thích các dòng điều khiển cho CPU được mã hóa cứng: http://minnie.tuhs.org/CompArch/Tutes/week03.html Như bạn có thể thấy, sự lựa chọn trong Opcodes thực sự ảnh hưởng đến mức độ phức tạp của logic Giải mã.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.