Professional Documents
Culture Documents
Morgan Kaufmann - Computer Architecture. A Quantitative Approach. 3rd Edition-Trang-301-384 (1) - Đã Nén
Morgan Kaufmann - Computer Architecture. A Quantitative Approach. 3rd Edition-Trang-301-384 (1) - Đã Nén
260 Chương 4 Khai thác song song mức hướng dẫn với các phương pháp tiếp cận phần mềm
Có thể sử dụng các kỹ thuật như giải nén vòng lặp, kết nối phần mềm và lập lịch theo dõi
để tăng lượng song song khả dụng khi hành vi của các nhánh khá dễ đoán tại thời điểm biên
dịch. Khi hành vi của các nhánh không được biết rõ, chỉ riêng các kỹ thuật trình biên dịch
Trong những trường hợp như vậy, các phụ thuộc điều khiển có thể hạn chế nghiêm trọng số
lượng ism song song có thể được khai thác. Tương tự, sự phụ thuộc tiềm tàng giữa các
lệnh kích hoạt bộ nhớ có thể ngăn cản chuyển động mã làm tăng ILP khả dụng. Phần này giới
thiệu một số kỹ thuật có thể giúp khắc phục tình trạng limi như vậy.
Đầu tiên là phần mở rộng của tập lệnh để bao gồm các hướng dẫn có điều kiện hoặc dự
đoán trước. Các hướng dẫn như vậy có thể được sử dụng để loại bỏ các nhánh chuyển đổi
sự phụ thuộc vào điều khiển thành sự phụ thuộc vào dữ liệu và có khả năng cải thiện hiệu
suất. Các cách tiếp cận như vậy rất hữu ích với các lược đồ chuyên sâu về phần cứng của
chương trước hoặc các cách tiếp cận chuyên sâu về phần mềm được thảo luận trong chương
này, vì trong cả hai trường hợp, dự đoán có thể được sử dụng để loại bỏ các nhánh.
Suy đoán phần cứng với hành vi ngoại lệ cam kết theo thứ tự được bảo toàn bằng cách
phát hiện và nâng cao ngoại lệ chỉ tại thời điểm cam kết khi lệnh không còn mang tính đầu
cơ. Để nâng cao khả năng của trình biên dịch để di chuyển mã qua các nhánh một cách suy
đoán, trong khi vẫn bảo toàn hành vi ngoại lệ, chúng tôi xem xét một số phương pháp khác
nhau, bao gồm kiểm tra rõ ràng các ngoại lệ hoặc kỹ thuật để đảm bảo rằng chỉ những ngoại
Cuối cùng, các sơ đồ đầu cơ phần cứng của chương trước đã cung cấp hỗ trợ cho việc
sắp xếp lại các tải và các cửa hàng, bằng cách kiểm tra các xung đột địa chỉ tiềm ẩn trong
thời gian chạy. Để cho phép trình biên dịch sắp xếp lại các tải và lưu trữ khi nghi ngờ
chúng không xung đột, nhưng không thể chắc chắn tuyệt đối, có thể thêm một cơ chế để kiểm
tra các xung đột đó vào phần cứng. Cơ chế này cho phép các cơ hội bổ sung để suy đoán tham
chiếu bộ nhớ.
Khái niệm đằng sau các lệnh có điều kiện khá đơn giản: Một lệnh đề cập đến một điều kiện,
được đánh giá là một phần của việc thực thi lệnh. Nếu ý tưởng là đúng, lệnh được thực
hiện bình thường; nếu điều kiện sai, việc thực thi tiếp tục như thể lệnh cấm. Nhiều kiến
trúc mới hơn bao gồm một số dạng hướng dẫn có điều kiện. Ví dụ phổ biến nhất của một lệnh
như vậy là di chuyển có điều kiện, di chuyển một giá trị từ thanh ghi này sang thanh ghi
khác nếu điều kiện là đúng. Một lệnh như vậy có thể được sử dụng để loại bỏ hoàn toàn một
4.5 Hỗ trợ phần cứng để hiển thị nhiều song song hơn tại thời gian biên dịch 261
nếu (A == 0) {S = T;}
Giả sử rằng các thanh ghi R1, R2 và R3 lần lượt giữ các giá trị của A, S và T,
hãy hiển thị mã cho câu lệnh này với nhánh và với động thái có điều kiện.
TRẢ LỜI Đoạn mã đơn giản sử dụng một nhánh cho câu lệnh này là (hãy nhớ rằng chúng ta
đang giả định là các nhánh bình thường chứ không phải bị trễ)
BNEZ R1, L
Sử dụng một bước di chuyển có điều kiện chỉ thực hiện di chuyển nếu toán hạng
thứ ba bằng 0, chúng ta có thể thực hiện câu lệnh này trong một lệnh:
Lệnh có điều kiện cho phép chúng ta chuyển đổi sự phụ thuộc điều khiển có trong
chuỗi mã dựa trên nhánh thành sự phụ thuộc vào dữ liệu. (Phép biến đổi này cũng
được sử dụng cho máy tính vectơ, nơi nó được gọi là chuyển đổi if.) Đối với bộ
xử lý pipelined, điều này di chuyển vị trí mà sự phụ thuộc phải được giải quyết
từ gần phía trước của đường ống, nơi nó được giải quyết cho các nhánh, đến
Một cách sử dụng rõ ràng cho việc di chuyển có điều kiện là thực hiện giá trị tuyệt đối
hàm: A = abs (B), được triển khai như thể (B <0) {A = -B;) else
{A = B;}. Câu lệnh if này có thể được thực hiện như một cặp di chuyển có điều kiện,
hoặc như một nước đi không điều kiện (A = B) và một nước đi có điều kiện (A = -B).
Trong ví dụ trên hoặc trong việc biên dịch giá trị tuyệt đối, có điều kiện
các bước di chuyển được sử dụng để thay đổi sự phụ thuộc điều khiển thành sự phụ thuộc vào
dữ liệu. Điều này giúp chúng tôi loại bỏ nhánh và có thể cải thiện hành vi của đường ống. Như
tỷ lệ phát hành tăng lên, các nhà thiết kế phải đối mặt với một trong hai lựa chọn: thực hiện nhiều
nhánh liên tục trên mỗi chu kỳ đồng hồ hoặc tìm một phương pháp loại bỏ các nhánh để tránh điều này
yêu cầu. Việc xử lý nhiều nhánh trên mỗi đồng hồ rất phức tạp, vì một nhánh
phải được kiểm soát phụ thuộc vào khác. Khó dự đoán chính xác
hai kết quả nhánh, cập nhật bảng dự đoán và thực hiện đúng
trình tự, cho đến nay đã khiến hầu hết các nhà thiết kế tránh các bộ xử lý thực thi nhiều
nhánh trên mỗi đồng hồ. Các bước di chuyển có điều kiện và các hướng dẫn dự đoán cung cấp một
cách giảm áp suất nhánh. Ngoài ra, một động thái có điều kiện thường có thể
loại bỏ một nhánh khó dự đoán, tăng khả năng thu được.
Các bước di chuyển có điều kiện là dạng đơn giản nhất của các lệnh có điều kiện hoặc dự
đoán, và mặc dù hữu ích cho các chuỗi ngắn, nhưng có những hạn chế. Đặc biệt, chúng tôi sử
dụng động thái có điều kiện để loại bỏ các nhánh bảo vệ việc thực hiện
các khối mã có thể không hiệu quả, vì nhiều động thái có điều kiện có thể cần phải
đã giới thiệu.
Machine Translated by Google
262 Chương 4 Khai thác song song mức hướng dẫn với các phương pháp tiếp cận phần mềm
Để khắc phục sự kém hiệu quả của việc sử dụng các động thái có điều kiện, một số kiến trúc
hỗ trợ dự đoán đầy đủ, theo đó việc thực hiện tất cả các hướng dẫn được kiểm soát bởi
dự đoán cho phép chúng ta chuyển đổi một cách đơn giản các khối mã lớn có nhiều nhánh khác
nhau. Ví dụ: một câu lệnh if-then-else trong một vòng lặp có thể hoàn toàn liên quan đến việc
thực thi dự đoán, do đó mã trong trường hợp sau đó thực thi chỉ khi
giá trị của điều kiện là đúng và mã trong trường hợp khác chỉ thực thi khi
giá trị của điều kiện là sai. Dự đoán đặc biệt có giá trị với toàn cầu
lập lịch mã, vì nó có thể loại bỏ các nhánh nonloop, điều này đáng kể
Các hướng dẫn dành riêng cũng có thể được sử dụng để di chuyển một cách suy đoán một chỉ dẫn
điều đó rất quan trọng về mặt thời gian, nhưng có thể gây ra một ngoại lệ nếu di chuyển trước một người canh gác
chi nhánh. Mặc dù có thể làm điều này với việc di chuyển có điều kiện, nhưng nó sẽ tốn kém hơn,
VÍ DỤ Đây là một chuỗi mã cho một siêu phương trình hai vấn đề có thể đưa ra một
sự kết hợp của một tham chiếu bộ nhớ và một hoạt động ALU hoặc một nhánh
Vị trí hướng dẫn đầu tiên Khe hướng dẫn thứ hai
HƠN R10, L
LW R8,0 (R10)
LW R9,0 (R8)
Trình tự này lãng phí một khe hoạt động bộ nhớ trong chu kỳ thứ hai và sẽ gây ra
sự cố phụ thuộc dữ liệu nếu nhánh không được sử dụng, vì LW giây sau nhánh phụ
thuộc vào tải trước đó. Chỉ ra cách mã có thể được cải thiện bằng cách sử dụng
dạng LW dự đoán.
TRẢ LỜI Gọi từ tải phiên bản dự đoán là LWC và giả sử tải xảy ra trừ khi toán hạng thứ
ba bằng 0. LW ngay sau nhánh có thể được chuyển đổi thành LWC và được
chuyển đến vị trí phát hành thứ hai:
Vị trí hướng dẫn đầu tiên Khe hướng dẫn thứ hai
HƠN R10, L
LW R9,0 (R8)
Machine Translated by Google
4.5 Hỗ trợ phần cứng để hiển thị nhiều song song hơn tại thời gian biên dịch 263
Điều này giúp cải thiện thời gian thực thi lên một số chu kỳ vì nó loại
bỏ một khe vấn đề về lệnh và giảm tình trạng ngưng trệ đường ống cho
lệnh cuối cùng trong chuỗi. Tất nhiên, nếu trình biên dịch xác định sai
nhánh, lệnh dự đoán sẽ không có hiệu lực và sẽ không cải thiện thời gian
chạy. Đây là lý do tại sao sự chuyển đổi là suy đoán.
Nếu trình tự theo sau nhánh ngắn, toàn bộ khối mã có thể được chuyển
đổi thành thực thi dự đoán, và nhánh elimi sẽ hoạt động.
N
Khi chúng tôi chuyển đổi toàn bộ phân đoạn mã sang thực thi dự đoán hoặc cụ thể di chuyển
một cách liên tục một lệnh và làm cho nó được dự đoán, chúng tôi sẽ loại bỏ dòng điều khiển.
hướng dẫn đảm bảo rằng chúng tôi duy trì luồng dữ liệu do chi nhánh thực thi. Để chắc chắn
rằng hành vi ngoại lệ cũng được duy trì, một lệnh dự đoán phải
không tạo ngoại lệ nếu vị từ sai. Thuộc tính không gây ra các ceptions ex là khá quan trọng,
như Ví dụ trên cho thấy: Nếu thanh ghi R10 chứa ze ro, lệnh LW R8,0 (R10) được thực thi vô
ngoại lệ bảo vệ, và ngoại lệ này sẽ không xảy ra. Tất nhiên, nếu điều kiện được thỏa mãn
(nghĩa là R10 không phải là 0), LW vẫn có thể gây ra lỗi hợp pháp và có thể tiếp tục
ngoại lệ (ví dụ: lỗi trang) và phần cứng phải có ngoại lệ khi nó
Sự phức tạp lớn trong việc thực hiện các hướng dẫn dự đoán là quyết định
khi nào thì hủy bỏ một chỉ dẫn. Các hướng dẫn dành riêng có thể bị hủy bỏ khi có vấn đề về
hướng dẫn hoặc sau đó trong quy trình trước khi chúng cam kết bất kỳ kết quả nào hoặc
nêu ra một ngoại lệ. Mỗi sự lựa chọn đều có một nhược điểm. Nếu hướng dẫn dự đoán là
bị hủy bỏ sớm trong quy trình, giá trị của điều kiện kiểm soát phải là
biết sớm để ngăn chặn nguy cơ dữ liệu bị đình trệ. Vì các phân đoạn nhánh phụ thuộc vào dữ
liệu, có xu hướng ít dự đoán hơn, là những ứng cử viên cho việc chuyển đổi sang thực thi dự
đoán trước, lựa chọn này có thể dẫn đến nhiều gian hàng đường ống hơn. Bởi vì điều này
tiềm ẩn nguy cơ dữ liệu ngăn chặn, không có thiết kế với thực thi dự đoán (hoặc di chuyển
theo điều kiện) hủy bỏ hướng dẫn sớm. Thay vào đó, tất cả các bộ xử lý hiện có sẽ bị hủy bỏ
trong các chuỗi sau này trong đường ống, có nghĩa là các lệnh bị hủy sẽ
tiêu thụ các nguồn lực của đơn vị chức năng và có khả năng có tác động tiêu cực đến mỗi hình
thức. Một loạt các kỹ thuật triển khai đường ống khác, chẳng hạn như phân vùng, tương tác
thực hiện.
Các hướng dẫn dành riêng hoặc có điều kiện cực kỳ hữu ích để triển khai
các luồng kiểm soát thay thế ngắn, để loại bỏ một số nhánh không thể đoán trước, và
để giảm chi phí lập lịch mã toàn cầu. Tuy nhiên, tính hữu ích
của các lệnh có điều kiện bị giới hạn bởi một số yếu tố:
n Hướng dẫn dành riêng bị hủy bỏ (tức là có điều kiện sai) vẫn
lấy một số tài nguyên của bộ xử lý. Một hướng dẫn dự đoán bị hủy yêu cầu
tìm nạp tài nguyên ở mức tối thiểu và trong hầu hết các bộ xử lý thực thi đơn vị chức năng
Machine Translated by Google
264 Chương 4 Khai thác song song mức hướng dẫn với các phương pháp tiếp cận phần mềm
thời gian. Do đó, việc di chuyển một lệnh qua một nhánh và làm cho nó ở trạng thái bình
thường sẽ làm chậm chương trình bất cứ khi nào lệnh được di chuyển sẽ không
đã được thực hiện bình thường. Tương tự như vậy, việc dự đoán điều khiển phụ thuộc vào
sẽ không được thực hiện. Một ngoại lệ quan trọng đối với những tình huống này là trỏ chuột
khi các chu kỳ được sử dụng bởi lệnh đã di chuyển khi nó không được thực hiện
dù sao cũng sẽ không hoạt động (như trong ví dụ superscalar ở trên). Di chuyển
một lệnh trên một nhánh hoặc chuyển đổi một phân đoạn mã thành dự đoán exe cution về cơ
bản là suy đoán về kết quả của nhánh. Có điều kiện trong str lệnh làm cho điều này dễ dàng
hơn nhưng không loại bỏ thời gian thực hiện bởi một
đoán không chính xác. Trong những trường hợp đơn giản, khi chúng tôi giao dịch một động thái có điều kiện để lấy
nhánh và một nước đi, sử dụng các nước đi có điều kiện hoặc dự đoán hầu như luôn luôn
tốt hơn. Khi các chuỗi mã dài hơn được tạo có điều kiện, lợi ích là
hạn chế hơn.
n Hướng dẫn dành riêng hữu ích nhất khi vị từ có thể được đánh giá
sớm. Nếu không thể tách riêng việc đánh giá điều kiện và các hướng dẫn dự đoán (do phụ
thuộc vào dữ liệu trong việc xác định điều kiện), thì một lệnh điều kiện có thể dẫn đến một
và đầu cơ, những gian hàng như vậy có thể tránh được, ít nhất là khi các nhánh được phân loại
n Việc sử dụng các lệnh có điều kiện có thể bị hạn chế khi dòng điều khiển ở các vol nhiều hơn
một trình tự thay thế đơn giản. Ví dụ: di chuyển một chuỗi trong qua nhiều nhánh yêu cầu
chi nhánh, yêu cầu hai điều kiện được chỉ định hoặc yêu cầu bổ sung
hướng dẫn để tính toán vị từ điều khiển. Nếu những khả năng đó không
hiện tại, chi phí chuyển đổi if sẽ lớn hơn, làm giảm lợi thế của nó.
n Hướng dẫn có điều kiện có thể có một số hình phạt về tốc độ so với hướng dẫn không có số
lượng. Điều này có thể hiển thị dưới dạng số chu kỳ cao hơn cho các chỉ thị như vậy hoặc
tốc độ đồng hồ chậm hơn nói chung. Nếu hướng dẫn có điều kiện hơn
đắt tiền, chúng sẽ cần được sử dụng một cách thận trọng.
Vì những lý do này, nhiều kiến trúc đã bao gồm một vài điều kiện đơn giản trong các lệnh (với
việc di chuyển có điều kiện là thường xuyên nhất), nhưng chỉ một số kiến trúc lưu trữ bao gồm
các phiên bản có điều kiện cho phần lớn các lệnh. Các
MIPS, Alpha, Power-PC, SPARC và Intel x86 (như được định nghĩa trong Pentium pro cessor) đều
hỗ trợ di chuyển có điều kiện. Kiến trúc IA-64 hỗ trợ cation dự đoán đầy đủ cho tất cả các
Như chúng ta đã thấy trước đó trong chương này, nhiều chương trình có các nhánh có thể
được dự đoán chính xác tại thời điểm biên dịch hoặc từ cấu trúc chương trình hoặc bằng cách sử dụng
Hồ sơ. Trong những trường hợp như vậy, trình biên dịch có thể muốn suy đoán để cải thiện
Machine Translated by Google
4.5 Hỗ trợ phần cứng để hiển thị nhiều song song hơn tại thời gian biên dịch 265
lập lịch hoặc để tăng tỷ lệ phát hành. Các hướng dẫn dành riêng cung cấp một meth od để suy đoán,
nhưng chúng thực sự hữu ích hơn khi các phụ thuộc điều khiển có thể
hoàn toàn bị loại bỏ bởi chuyển đổi if. Trong nhiều trường hợp, chúng tôi muốn chuyển
các hướng dẫn được suy đoán không chỉ trước nhánh, mà trước khi điều kiện đánh giá, và dự đoán
Như đã chỉ ra trước đó, để suy đoán một cách tham vọng cần có ba khả năng:
1. khả năng của trình biên dịch để tìm các hướng dẫn, với khả năng sử dụng đổi tên reg ister, có
thể được di chuyển một cách phỏng đoán và không ảnh hưởng đến dữ liệu chương trình
lưu lượng,
2. khả năng bỏ qua các ngoại lệ trong các hướng dẫn được suy đoán, cho đến khi chúng ta biết rằng
những trường hợp ngoại lệ như vậy thực sự nên xảy ra, và
3. khả năng hoán đổi các tải và cửa hàng một cách có suy đoán, hoặc các cửa hàng và cửa hàng,
Cái đầu tiên trong số này là khả năng biên dịch, trong khi hai cái cuối cùng yêu cầu phần cứng
vẫn bảo tồn hành vi ngoại lệ của nó. Chìa khóa để có thể làm được điều này là quan sát
rằng các kết quả của một trình tự suy đoán bị dự đoán sai sẽ không được sử dụng trong
tính toán cuối cùng, và một chỉ dẫn được suy đoán như vậy sẽ không gây ra tiếng kêu.
Có bốn phương pháp đã được nghiên cứu để hỗ trợ thêm môi trường xung quanh
suy đoán phức tạp mà không đưa ra hành vi ngoại lệ sai lầm:
1. Phần cứng và hệ điều hành hợp tác bỏ qua các ngoại lệ đối với các hướng dẫn đặc biệt. Như
chúng ta sẽ thấy bên dưới, cách tiếp cận này bảo tồn ngoại lệ
hành vi cho các chương trình đúng, nhưng không cho các chương trình không chính xác. Cách tiếp cận này có thể
được xem là không thể chấp nhận được đối với một số chương trình, nhưng nó đã được sử dụng, dưới
sự kiểm soát chuyên nghiệp, như một "chế độ nhanh" trong một số bộ xử lý.
2. Các hướng dẫn suy đoán không bao giờ nêu ra ngoại lệ được sử dụng và các kiểm tra
được giới thiệu để xác định khi nào một ngoại lệ sẽ xảy ra.
3. Tập hợp các bit trạng thái, được gọi là bit độc, được gắn vào các thanh ghi kết quả ghi mười
bởi các lệnh được suy đoán khi các lệnh gây ra ngoại lệ. Các
các bit độc gây ra lỗi khi một lệnh bình thường cố gắng sử dụng thanh ghi.
4. Một cơ chế được cung cấp để chỉ ra rằng một chỉ dẫn là suy đoán và
phần cứng đệm kết quả lệnh cho đến khi chắc chắn rằng lệnh đó là
266 Chương 4 Khai thác song song mức hướng dẫn với các phương pháp tiếp cận phần mềm
Để giải thích các lược đồ này, chúng ta cần phân biệt giữa các ngoại lệ gây ra lỗi chương
vi phạm bảo vệ và những vi phạm được xử lý và thường được tiếp tục lại, chẳng hạn như
Lỗi trang. Các trường hợp ngoại lệ có thể được tiếp tục lại có thể được chấp nhận và xử lý cho
các hướng dẫn suy đoán giống như thể chúng là các hướng dẫn bình thường. Nếu đầu cơ
hướng dẫn không nên được thực thi, việc xử lý ngoại lệ không cần thiết có thể
có một số tác động tiêu cực về hiệu suất, nhưng nó không thể gây ra việc thực thi không chính xác.
Tuy nhiên, chi phí của những ngoại lệ này có thể cao và một số bộ xử lý sử dụng
hỗ trợ phần cứng để tránh thực hiện các ngoại lệ như vậy, cũng như các bộ xử lý có đầu cơ phần
cứng có thể có một số ngoại lệ trong chế độ đầu cơ, đồng thời tránh
những người khác cho đến khi một chỉ dẫn được biết là không phải là suy đoán.
Các trường hợp ngoại lệ chỉ ra lỗi chương trình sẽ không xảy ra trong các chương trình chính xác,
và kết quả của một chương trình nhận được một ngoại lệ như vậy không được xác định rõ, ngoại trừ
có lẽ khi chương trình đang chạy ở chế độ gỡ lỗi. Nếu ngoại lệ như vậy
phát sinh trong các hướng dẫn được suy đoán, chúng tôi không thể thực hiện ngoại lệ cho đến khi chúng tôi biết rằng
Trong phương pháp đơn giản nhất để bảo toàn các ngoại lệ, phần cứng và hệ thống ing operat
chỉ cần xử lý tất cả các ngoại lệ có thể tiếp tục khi ngoại lệ xảy ra
và chỉ cần trả về một giá trị không xác định cho bất kỳ ngoại lệ nào có thể gây ra kết thúc. Nếu
thì chương trình bị lỗi. Lưu ý rằng thay vì chấm dứt chương trình,
chương trình được phép tiếp tục, mặc dù nó gần như chắc chắn sẽ tạo ra
kết quả. Nếu lệnh tạo ngoại lệ kết thúc là suy đoán, thì
chương trình có thể đúng và kết quả suy đoán sẽ đơn giản là không được sử dụng;
do đó, việc trả về một giá trị không xác định cho lệnh không thể có hại. Đây
lược đồ không bao giờ có thể khiến một chương trình chính xác bị lỗi, cho dù bạn có thực hiện
bao nhiêu đặc điểm. Một chương trình không chính xác, mà trước đây có thể đã nhận được một ngoại
lệ kết thúc, sẽ nhận được một kết quả không chính xác. Điều này có thể chấp nhận được đối với một số
các chương trình, giả sử trình biên dịch cũng có thể tạo ra một phiên bản bình thường của pro
gram, phiên bản này không suy đoán và có thể nhận được một ngoại lệ kết thúc.
VÍ DỤ : Hãy xem xét đoạn mã sau từ một câu lệnh if-then-else của biểu mẫu
nếu (A == 0) A = B; khác A = A + 4;
Giả sử mệnh đề then hầu như luôn được thực thi. Biên dịch mã bằng cách sử
dụng đầu cơ dựa trên trình biên dịch. Giả sử R14 không được sử dụng và có sẵn.
Machine Translated by Google
4.5 Hỗ trợ phần cứng để hiển thị nhiều song song hơn tại thời gian biên dịch 267
Mệnh đề then hoàn toàn được suy đoán. Chúng tôi giới thiệu một thanh
ghi tạm thời để tránh phá hủy R1 khi B được tải; nếu tải là suy đoán R14
sẽ vô dụng. Sau khi toàn bộ đoạn mã được thực thi, A sẽ ở trong R14. Mệnh
đề else cũng có thể được biên dịch theo kiểu suy đoán với một động thái
có điều kiện, nhưng nếu nhánh có khả năng dự đoán cao và chi phí thấp,
thì điều này có thể làm chậm mã, vì hai lệnh bổ sung sẽ luôn được thực
hiện trái ngược với một nhánh. N
Trong một sơ đồ như vậy, không cần thiết phải biết rằng một chỉ dẫn là suy đoán.
Thật vậy, nó chỉ hữu ích khi một chương trình bị lỗi và nhận được kết thúc
ngoại lệ trên một hướng dẫn bình thường; trong những trường hợp như vậy, nếu hướng dẫn không
được đánh dấu là đầu cơ, chương trình có thể bị chấm dứt.
Trong phương pháp này để xử lý suy đoán, như trong phương pháp tiếp theo, cần đổi tên
số 10 để ngăn các lệnh đầu cơ phá hủy các giá trị sống. Việc đặt lại tên thường bị hạn chế
đối với các giá trị đăng ký. Do hạn chế này,
mục tiêu của các cửa hàng không thể bị phá hủy và các cửa hàng không thể được đầu cơ. Nhỏ
số lượng đăng ký và chi phí tràn sẽ đóng vai trò là một hạn chế đối với
lượng đầu cơ. Tất nhiên, hạn chế chính vẫn là chi phí của việc cắt bỏ các hướng dẫn suy đoán
exe khi dự đoán rẽ nhánh của trình biên dịch không phù hợp.
Cách tiếp cận thứ hai để duy trì hành vi ngoại lệ khi suy đoán các phiên bản đầu cơ của
hướng dẫn không tạo ra các lệnh ngoại lệ kết thúc và hướng dẫn để kiểm tra các ngoại lệ đó.
VÍ DỤ Cho thấy ví dụ trước có thể được mã hóa như thế nào bằng cách sử dụng tải suy
đoán (sLD) và lệnh kiểm tra suy đoán (SPECCK) để hoàn toàn phục vụ trước
hành vi ngoại lệ. Giả sử R14 không được sử dụng và có sẵn.
268 Chương 4 Khai thác song song mức hướng dẫn với các phương pháp tiếp cận phần mềm
J L2 tàu vv
L1: Mệnh đề DADDI R14, R1, # 4; else
L2: SD 0 (R3), R14; cửa hàng A
Lưu ý rằng việc kiểm tra đầu cơ yêu cầu chúng ta duy trì một khối cơ bản cho
trường hợp sau đó. Nếu chúng ta chỉ suy đoán một phần của trường hợp thì, thì một
khối cơ bản đại diện cho trường hợp sau đó sẽ tồn tại trong bất kỳ trường hợp nào.
Quan trọng hơn, hãy lưu ý rằng việc kiểm tra một ngoại lệ có thể xảy ra yêu
cầu thêm mã. N
Cách tiếp cận thứ ba để duy trì hành vi ngoại lệ theo dõi các ngoại lệ khi chúng
xảy ra nhưng hoãn lại bất kỳ ngoại lệ kết thúc nào cho đến khi một giá trị thực sự được sử dụng,
phục vụ trước sự xuất hiện của ngoại lệ, mặc dù không hoàn toàn chính xác
thời trang. Lược đồ rất đơn giản: Một bit độc được thêm vào mọi thanh ghi và một bit khác
bit được thêm vào mọi lệnh để cho biết liệu lệnh đó có phải là suy đoán hay không.
Bit độc của thanh ghi đích được đặt bất cứ khi nào một lệnh suy đoán
dẫn đến một ngoại lệ chấm dứt; tất cả các trường hợp ngoại lệ khác được xử lý ngay lập tức.
Nếu một lệnh suy đoán sử dụng một thanh ghi có bit độc được bật, thì thanh ghi định mệnh của lệnh
chỉ đơn giản là bật bit độc của nó. Nếu một bình thường trong cấu trúc cố gắng sử dụng một nguồn
hướng dẫn gây ra lỗi. Bằng cách này, bất kỳ chương trình nào đã tạo ra một
ngoại lệ vẫn tạo ra một ngoại lệ, mặc dù ở trường hợp đầu tiên, nơi một kết quả được sử dụng bởi một
hướng dẫn không phải là suy đoán. Vì các bit độc chỉ tồn tại trên các giá trị thanh ghi
và không phải các giá trị bộ nhớ, các cửa hàng không bao giờ mang tính đầu cơ và do đó bẫy nếu một trong hai toán hạng
là "chất độc."
VÍ DỤ: Hãy xem xét đoạn mã từ trang 267 và cho biết nó sẽ được biên dịch như thế nào với các
lệnh suy đoán và các bit độc. Chỉ ra nơi mà một ngoại lệ cho tham chiếu bộ nhớ
TRẢ LỜI Đây là mã (một ”s” tiếp tục opcode chỉ ra một suy đoán trong struction):
Nếu sLD đầu cơ tạo ra một ngoại lệ kết thúc, bit độc của R14 sẽ được bật. Khi
lệnh SW không tích lũy xảy ra, nó sẽ tạo ra một ngoại lệ nếu bit độc cho R14 được
bật. N
Một vấn đề phức tạp cần phải khắc phục là cách hệ điều hành tiết kiệm regis ters của người dùng
trên một công tắc ngữ cảnh nếu bit độc được đặt. Một hướng dẫn đặc biệt là cần thiết để
lưu và đặt lại trạng thái của các bit độc để tránh sự cố này.
Machine Translated by Google
4.5 Hỗ trợ phần cứng để hiển thị nhiều song song hơn tại thời gian biên dịch 269
Cách tiếp cận thứ tư và cuối cùng được liệt kê ở trên dựa trên cơ chế phần cứng
hoạt động giống như một bộ đệm sắp xếp lại. Trong cách tiếp cận như vậy, các hướng dẫn được đánh dấu
bởi trình biên dịch dưới dạng suy đoán và bao gồm một chỉ báo về số lượng nhánh
hướng dẫn đã được chuyển qua một cách phỏng đoán và hành động nhánh nào (được thực hiện / không
lấy) trình biên dịch giả định. Phần thông tin cuối cùng này về cơ bản cho biết
phần cứng vị trí của khối mã nơi mà lệnh gốc đã được suy đoán. Trên thực tế, hầu hết lợi ích
chuyển động trên một nhánh duy nhất và do đó, chỉ một chút cho biết liệu
hướng dẫn suy đoán đến từ đường dẫn được thực hiện hoặc không được thực hiện là bắt buộc.
Ngoài ra, vị trí ban đầu của hướng dẫn suy đoán được đánh dấu bằng một chốt canh,
điều này cho phần cứng biết rằng lệnh suy đoán trước đó không còn khả thi nữa và các giá trị
Tất cả các hướng dẫn được đặt trong một bộ đệm sắp xếp lại khi được ban hành và buộc phải
cam kết theo thứ tự, như trong cách tiếp cận đầu cơ phần cứng. (Lưu ý, mặc dù không
dự đoán nhánh đầu cơ thực tế hoặc lập lịch động xảy ra.)
đệm theo dõi khi các hướng dẫn đã sẵn sàng để cam kết và trì hoãn việc "viết lại"
một phần của bất kỳ hướng dẫn đầu cơ nào. Hướng dẫn suy đoán không được phép
cam kết cho đến khi các nhánh mà chúng đã được suy đoán chuyển qua cũng
sẵn sàng cam kết, hoặc, cách khác, cho đến khi đạt được cơ quan giám sát tương ứng. Tại
điểm đó, chúng ta biết liệu lệnh được suy đoán có nên được thực thi hay không. Nếu lẽ ra nó
phải được thực thi và nó tạo ra một ngoại lệ kết thúc, thì chúng ta biết rằng chương trình
lẽ ra không được thực thi, thì ngoại lệ có thể được bỏ qua. Lưu ý rằng
trình biên dịch, chứ không phải phần cứng, có công việc đổi tên thanh ghi để đảm bảo việc sử
dụng trực tiếp kết quả được suy đoán, cũng như thực thi chương trình chính xác.
Việc di chuyển tải qua các cửa hàng thường được thực hiện khi trình biên dịch chắc chắn rằng
các trang phục quảng cáo không xung đột. Như chúng ta đã thấy với các ví dụ trong phần 4.1, các
hình thức chuyển đổi như vậy rất quan trọng để giảm độ dài đường dẫn quan trọng của một đoạn mã. Đến
cho phép trình biên dịch thực hiện chuyển động mã như vậy, khi nó không thể hoàn toàn
chắc chắn rằng một chuyển động như vậy là đúng, một hướng dẫn đặc biệt để kiểm tra địa chỉ
xung đột có thể được bao gồm trong kiến trúc. Hướng dẫn đặc biệt được để lại ở
vị trí ban đầu của hướng dẫn tải (và hoạt động như một người giám hộ) và tải là
Khi một tải suy đoán được thực thi, phần cứng sẽ lưu địa chỉ của vị trí bộ nhớ đã ngừng
ac. Nếu một cửa hàng tiếp theo thay đổi địa điểm trước khi
kiểm tra hướng dẫn, sau đó suy đoán đã thất bại. Nếu vị trí chưa được
chạm vào thì suy đoán thành công. Suy đoán thất bại có thể được xử lý trong
hai lối. Nếu chỉ có hướng dẫn tải được suy đoán, thì nó đủ để thực hiện lại
tải tại điểm của lệnh kiểm tra (có thể cung cấp thanh ghi đích
ngoài địa chỉ bộ nhớ). Nếu các hướng dẫn bổ sung phụ thuộc vào
tải cũng được suy đoán, sau đó là một trình tự sửa lỗi thực hiện lại tất cả
Machine Translated by Google
270 Chương 4 Khai thác song song mức hướng dẫn với các phương pháp tiếp cận phần mềm
hướng dẫn suy đoán bắt đầu với tải là cần thiết. Trong trường hợp này, kiểm tra trong struction chỉ
Trong phần này, chúng ta đã thấy một loạt các cơ chế hỗ trợ phần cứng. Như là
các cơ chế là chìa khóa để đạt được sự hỗ trợ tốt với trình biên dịch chuyên sâu của chương này.
Ngoài ra, một số trong số chúng có thể được tích hợp dễ dàng trong
các phương pháp tiếp cận chuyên sâu về phần cứng của chương trước và cung cấp thêm
lợi ích.
Các phương pháp tiếp cận chuyên sâu về phần cứng để suy đoán trong chương trước và
các cách tiếp cận phần mềm của chương này cung cấp các cách tiếp cận thay thế để khai thác
IL P. Một số sự cân bằng và hạn chế đối với những cách tiếp cận này được liệt kê là thấp:
n Để suy đoán rộng rãi, chúng ta phải có khả năng phân định các tham chiếu bộ nhớ.
Khả năng này rất khó thực hiện tại thời điểm biên dịch đối với các chương trình số nguyên kết
hợp con trỏ. Trong một lược đồ dựa trên phần cứng, sự phân định thời gian chạy động của
địa chỉ bộ nhớ được thực hiện bằng cách sử dụng các kỹ thuật mà chúng ta đã thấy trước đó cho Tomasulo's
thuật toán. Định dạng này cho phép chúng tôi di chuyển tải các cửa hàng trước đây trong thời gian chạy.
Hỗ trợ cho các tham chiếu bộ nhớ suy đoán có thể giúp khắc phục sự hạn chế của trình biên dịch,
nhưng trừ khi các cách tiếp cận như vậy được sử dụng cẩn thận, các cơ chế khôi phục có thể
chiếm ưu thế.
n Suy đoán dựa trên phần cứng hoạt động tốt hơn khi luồng điều khiển không thể đoán trước,
và khi dự đoán nhánh dựa trên phần cứng vượt trội hơn dựa trên phần mềm
dự đoán nhánh được thực hiện tại thời điểm biên dịch. Các thuộc tính này giữ cho nhiều số nguyên
các chương trình. Ví dụ: một công cụ dự đoán tĩnh tốt có tỷ lệ dự đoán sai là
khoảng 16% cho bốn chương trình SPEC92 số nguyên chính và một công cụ dự đoán phần cứng
có tỷ lệ sai lầm dưới 10%. Bởi vì các hướng dẫn được suy đoán có thể
làm chậm quá trình tính toán khi dự đoán không chính xác, sự khác biệt này là
có ý nghĩa. Một kết quả của sự khác biệt này là ngay cả các cessor chuyên nghiệp được lập lịch
n Suy đoán dựa trên phần cứng duy trì một mô hình ngoại lệ hoàn toàn chính xác
ngay cả đối với các hướng dẫn được suy đoán. Các phương pháp tiếp cận dựa trên phần mềm gần
n Đầu cơ dựa trên phần cứng không yêu cầu bồi thường hoặc ghi sổ kế toán
mã, thứ cần thiết bởi các cơ chế đầu cơ phần mềm đầy tham vọng.
n Phương pháp tiếp cận dựa trên trình biên dịch có thể được hưởng lợi từ khả năng nhìn xa hơn trong
trình tự mã, dẫn đến lập lịch mã tốt hơn so với một phần cứng thuần túy
Machine Translated by Google
Phần này mô tả lịch sử phát triển của nhiều phương pháp tiếp cận vấn đề,
bắt đầu với nhiều vấn đề tĩnh và tiếp tục với công việc gần đây nhất nhập vào IA-64.
Tương tự, chúng ta nhìn vào. lịch sử lâu đời của công nghệ trình biên dịch trong
khu vực này.
Hầu hết các bộ xử lý nhiều vấn đề ban đầu đều tuân theo phương pháp ap proach thiết kế
LIW hoặc VLIW. Charlesworth [1981] báo cáo về Hệ thống dấu chấm động AP-120B,
một trong những bộ xử lý lệnh rộng đầu tiên chứa nhiều hoạt động trên mỗi
hướng dẫn. Hệ thống dấu chấm động đã áp dụng khái niệm tổng hợp phần mềm trong
cả một trình biên dịch và các thư viện hợp ngữ viết tay để sử dụng trình xử lý chuyên
nghiệp một cách hiệu quả. Vì bộ xử lý là một bộ xử lý gắn liền, nhiều vấn đề khó xảy ra
khi triển khai nhiều vấn đề trong các bộ xử lý đa năng, đối với
Bộ xử lý Stanford MIPS có khả năng đặt hai hoạt động trong một lệnh sin gle, mặc dù
khả năng này đã bị loại bỏ trong các biến thể thương mại của
kiến trúc, chủ yếu vì lý do hiệu suất. Cùng với các đồng nghiệp của mình tại
Yale, Fisher [1983] đề xuất tạo ra một bộ xử lý có hướng dẫn rất rộng
(512 bit), và đặt tên cho loại bộ xử lý này là VLIW. Mã được tạo cho
bộ xử lý sử dụng lập lịch theo dõi, mà Fisher [1981] đã phát triển ban đầu
để tạo vi mã ngang. Việc thực hiện lập lịch theo dõi cho
bộ xử lý Yale được mô tả bởi Fisher et al. [1984] và bởi Ellis [1986]. Các
Bộ xử lý đa luồng (xem Colwell và cộng sự [1987]) dựa trên các khái niệm được phát triển
tại Yale, mặc dù nhiều cải tiến quan trọng đã được thực hiện để tăng
tính thực tiễn của cách tiếp cận. Trong số này có một bộ đệm lưu trữ có thể kiểm soát được
đã cung cấp hỗ trợ cho một hình thức đầu cơ. Mặc dù hơn 100 Multiflow
Bộ vi xử lý đã được bán, một loạt các vấn đề, bao gồm cả những khó khăn khi giới thiệu bộ
hướng dẫn mới từ một công ty nhỏ và sự cạnh tranh cung cấp
từ bộ vi xử lý RISC thương mại đã làm thay đổi nền kinh tế trong thị trường máy tính
mini, dẫn đến sự thất bại của Multiflow với tư cách là một công ty.
Cùng khoảng thời gian với Multiflow, Cydrome được thành lập để xây dựng một bộ xử lý
kiểu VLIW (xem Rau và cộng sự [1989]), cũng không thành công về mặt thương mại. Dehnert,
Hsu, và Bratt [1989] giải thích kiến trúc và hiệu suất của
Cydrome Cydra 5, một bộ xử lý có từ hướng dẫn rộng, cung cấp khả năng đổi tên thanh ghi
Cydra 5 là sự pha trộn độc đáo giữa phần cứng và phần mềm, bao gồm điều kiện trong cấu
trúc và xoay thanh ghi, nhằm mục đích trích xuất ILP. Cydrome dựa trên nhiều hơn
phần cứng hơn bộ xử lý Đa luồng và đạt được hiệu suất cạnh tranh
chủ yếu dựa trên mã kiểu vectơ. Cuối cùng, Cydrome gặp phải vấn đề
Machine Translated by Google
296 Chương 4 Khai thác song song mức hướng dẫn với các phương pháp tiếp cận phần mềm
tương tự như Multiflow và không phải là một thành công thương mại. Cả hai luồng
và Cydrome, mặc dù không thành công với tư cách là các thực thể thương mại, đã tạo ra một số
những người có nhiều kinh nghiệm trong việc khai thác ILP cũng như trình biên dịch nâng cao
Công nghệ; nhiều người trong số những người đó đã tiếp tục kết hợp kinh nghiệm của họ
và các phần của công nghệ trong các bộ vi xử lý mới hơn. Fisher và Rau [1993] đã biên tập một bộ
sưu tập toàn diện các bài báo bao gồm phần cứng và phần mềm của
Rau cũng đã phát triển một kỹ thuật lập lịch được gọi là lập lịch đa vòng,
là cơ sở cho hầu hết các kế hoạch tổng hợp phần mềm (xem Rau, Glaeser và
Picard [1982]). Tác phẩm của Rau được xây dựng dựa trên tác phẩm trước đó của Davidson và các đồng nghiệp của anh ấy
về việc thiết kế các bộ lập lịch phần cứng tối ưu cho bộ xử lý pipelined. Các bộ xử lý LIW hình
tượng khác của anh ấy bao gồm Apollo DN 10000 và Intel i860,
Một trong những cách tiếp cận thú vị được sử dụng trong các bộ xử lý VLIW ban đầu, chẳng hạn như
AP-120B và i860, là ý tưởng về một tổ chức đường ống yêu cầu các tiết mục opera phải được “đẩy
qua” một đơn vị chức năng và kết quả được ghi nhận tại
cuối đường ống. Trong các bộ xử lý như vậy, các hoạt động chỉ tiến hành khi khác
hoạt động đẩy chúng từ phía sau (theo trình tự). Hơn nữa, một chỉ dẫn
chỉ định đích cho một lệnh được phát hành trước đó sẽ bị đẩy ra khỏi
đường dẫn khi thao tác mới này được đẩy vào. Cách tiếp cận như vậy có lợi thế là nó không chỉ
định đích kết quả khi thao tác gặp sự cố đầu tiên
nhưng chỉ khi thanh ghi kết quả thực sự được ghi. Sự tách biệt này giúp loại bỏ
nhu cầu phát hiện các nguy cơ WAW và WAR trong phần cứng. Bất lợi là
rằng nó làm tăng kích thước mã vì có thể cần các thao tác không cần thiết để đẩy kết quả ra khi
có sự phụ thuộc vào một hoạt động vẫn đang trong quá trình thực hiện và không cần thực hiện các
hoạt động nào khác thuộc loại đó ngay lập tức. Thay vì phương pháp ap proach “push-and-catch”
được sử dụng trong hai bộ xử lý này, hầu như tất cả các nhà thiết kế đã chọn sử dụng các đường
ống thoát nước tự động chỉ định đích trong lệnh phát hành và trong
mà một hướng dẫn đã ban hành sẽ hoàn thành mà không cần thực hiện thêm hành động nào. Những lợi thế
về mật độ mã và sự đơn giản hóa trong quá trình tạo mã dường như vượt trội hơn các lợi thế quảng
Công nghệ biên dịch và phần cứng hỗ trợ lập lịch trình
Phân tích sự phụ thuộc và song song mức vòng lặp được phát triển chủ yếu bởi D.
Kuck và các đồng nghiệp của ông tại Đại học Illinois vào những năm 1970. Họ cũng
đặt ra thuật ngữ thường được sử dụng về sự chống phụ thuộc và mức độ suy giảm đầu ra và phát triển
một số bài kiểm tra sự phụ thuộc tiêu chuẩn, bao gồm cả GCD và
Kiểm tra Banerjee. Thử nghiệm thứ hai được đặt theo tên của Uptal Banerjee và có rất nhiều hương
vị. Công việc gần đây về phân tích sự phụ thuộc đã tập trung vào việc sử dụng một loạt các thử
nghiệm chính xác kết thúc bằng một thuật toán được gọi là Fourier-Motzkin, một thuật toán
thuật toán lập trình tuyến tính. D. Maydan và W. Pugh đều chỉ ra rằng chuỗi các bài kiểm tra chính
Trong lĩnh vực khám phá và lên lịch ILP, phần lớn công việc ban đầu là
kết nối với sự phát triển của bộ xử lý VLIW, được mô tả trước đó. Lâm [1988]
đã phát triển các thuật toán cho phần mềm pipelining và đánh giá việc sử dụng chúng trên Warp, một
bộ xử lý văn bản hướng dẫn rộng được thiết kế cho các ứng dụng có mục đích đặc biệt.
Weiss và JE Smith [1987] so sánh phần mềm pipelining so với việc mở vòng lặp
như các kỹ thuật lập lịch trình mã trên bộ xử lý pipelined. Rau [1994] devel đã chọn
lập lịch modulo để giải quyết các vấn đề của vòng lặp đường ống phần mềm và
đồng thời xử lý cấp phát thanh ghi.
Hỗ trợ lập lịch mã đầu cơ đã được khám phá trong nhiều ngữ cảnh khác nhau,
bao gồm một số bộ xử lý cung cấp một chế độ trong đó các ngoại lệ được chú ý, cho phép
lập lịch tải tích cực hơn (ví dụ: MIPS TFP proces sor, xem [Hsu 1994].). Một số nhóm đã
khám phá các ý tưởng để tích cực hơn
hỗ trợ phần cứng để lập lịch mã đầu cơ. Ví dụ, Smith, Horow itz và Lam [1992] đã tạo ra
một khái niệm gọi là tăng cường chứa phần cứng
cơ sở hỗ trợ đầu cơ nhưng cung cấp một cơ chế kiểm tra và khôi phục, tương tự như
trong IA-64 và Crusoe. Ý tưởng lên lịch cho lính canh,
cũng tương tự như phương pháp suy đoán và kiểm tra được sử dụng trong cả Crusoe và
Kiến trúc IA-64, được phát triển bởi các nhà nghiên cứu tại U. of Illinois và HP
Phòng thí nghiệm (xem [Mahlke et al. 1992]).
Vào đầu những năm 1990, Wen-Mei Hwu và các đồng nghiệp của ông tại Đại học Illi nois
đã phát triển một khung biên dịch, được gọi là IMPACT (xem [Chang, et al.
1991]), để khám phá sự tương tác giữa các kiến trúc nhiều vấn đề và
công nghệ trình biên dịch. Dự án này đã dẫn đến một số ý tưởng quan trọng, bao gồm: lập
lịch trình su perblock (xem [Hwu và cộng sự 1993]), sử dụng rộng rãi cấu hình để hướng
dẫn một loạt các tối ưu hóa (ví dụ: nội tuyến thủ tục) và sử dụng
bộ đệm (tương tự như ALAT hoặc bộ đệm lưu trữ được chương trình điều khiển) để phát
hiện xung đột bộ nhớ hỗ trợ biên dịch (xem [Gallagher, et. 1994]). Họ cũng đã khám phá
sự cân bằng hiệu suất giữa hỗ trợ một phần và hỗ trợ toàn bộ cho việc dự đoán trong
[Mahlke, et. al. 1995].
Các bộ xử lý RISC ban đầu đều có các nhánh bị trì hoãn, một kế hoạch lấy cảm hứng từ
vi lập trình và một số nghiên cứu về dự đoán nhánh thời gian biên dịch là
lấy cảm hứng từ các cơ chế nhánh bị trì hoãn. McFarling và Hennessy [1986] đã làm một
so sánh định lượng của nhiều lược đồ dự đoán nhánh thời gian biên dịch và thời gian
chạy. Fisher và Freudenberger [1992] đã đánh giá một loạt các lược đồ dự đoán nhánh
thời gian biên dịch bằng cách sử dụng thước đo khoảng cách giữa các tions sai.
Gốc rễ của cách tiếp cận EPIC nằm ở những nỗ lực trước đó nhằm xây dựng LIW và VLIW
máy móc – đặc biệt là những máy ở Cydrome và Multiflow – và có lịch sử lâu dài về
công việc biên dịch tiếp tục sau khi các công ty này thất bại tại HP, Đại học
của Illinois, và những nơi khác. Những hiểu biết sâu sắc có được từ công việc đó đã khiến các nhà thiết kế tại HP
đề xuất kiến trúc 64 bit kiểu VLIW để tiếp nối với lưu trữ HP-PA RISC-
Machine Translated by Google
298 Chương 4 Khai thác song song mức hướng dẫn với các phương pháp tiếp cận phần mềm
kiến trúc. Intel đang tìm kiếm một kiến trúc mới để thay thế x86 (bây giờ được gọi là
Kiến trúc IA-32) và cung cấp khả năng 64-bit. Năm 1995, họ thành lập một nership một
phần để thiết kế một kiến trúc mới, IA-64, và xây dựng các bộ xử lý dựa trên nó. Ita
nium là bộ xử lý đầu tiên như vậy. Mô tả về kiến trúc IA-64 là
có sẵn trực tuyến tại: http://devresource.hp.com/devresource/Docs/Refs/IA64ISA/.
Mô tả về những điểm nổi bật của bộ xử lý Itanium có tại: http: //
www.intel.com/design/itanium/microarch_ovw/index.htm.
BALL, T. VÀ JR LARUS [1993]. “Dự đoán chi nhánh miễn phí,” Proc. SIGPLAN 1993 Conf. về Thiết kế và Triển
khai Ngôn ngữ Lập trình Pro gramming, tháng 6, 300-313.
CHANG, PP, MAHLKE, SA, CHEN, WY, WARTER , NJ, AND WW HWU [1991], “IMPACT: An
khung kiến trúc cho các bộ xử lý vấn đề nhiều lệnh, ”Kỷ yếu của Hội nghị chuyên đề quốc tế về kiến trúc
máy tính lần thứ 18 (tháng 5), trang 266--275.
CHARLESWORTH, AE [1981]. “Một cách tiếp cận để xử lý mảng khoa học: Thiết kế kiến trúc
thuộc họ AP-120B / FPS-164, ” Máy tính 14: 9 (Tháng 9), 18–27.
DEHNERT, JC, PY-T. HSU, VÀ JP BRATT [1989]. “Hỗ trợ vòng lặp chồng chéo trên Cydra 5,”
Proc. Lời thú nhận thứ ba. về Hỗ trợ Kiến trúc cho Ngôn ngữ Lập trình và Hệ điều hành
(Tháng 4), IEEE / ACM, Boston, 26–39.
ELLIS, JR [1986]. Bulldog: Trình biên dịch cho VLIW Architectures, MIT Press, Cambridge, Mass.
FISHER, JA [1981]. “Lập lịch theo dõi: Một kỹ thuật để nén vi mã toàn cầu,” IEEE
Dịch. trên Máy tính 30: 7 (tháng 7), 478–490.
FISHER, JA [1983]. “Kiến trúc từ hướng dẫn rất dài và ELI-512,” Proc. Sympo thứ mười
sium về Kiến trúc Máy tính (Tháng 6), Stockholm, 140–150.
FISHER, JA, JR ELLIS, JC RUTTENBERG, VÀ A. NICOLAU [1984]. “Xử lý song song: Một
trình biên dịch và một bộ xử lý ngu ngốc, ” Proc. SIGPLAN Conf. trên Compiler Construction (tháng 6), Palo
Alto, Calif., 11–16.
FISHER, JA VÀ SM FREUDENBERGER [1992]. “Dự đoán các nhánh có điều kiện từ trước
chạy chương trình, ” Proc. Lời thú nhận thứ năm. về Hỗ trợ Kiến trúc cho Ngôn ngữ Lập trình và
Hệ điều hành, IEEE / ACM (tháng 10), Boston, 85-95.
FISHER, JA VÀ BR RAU [1993]. Tạp chí Siêu máy tính (tháng 1), Kluwer.
CHÂN THÀNH , CC VÀ EM RISEMAN [1972]. “Phần nhỏ mã để tăng cường điều phối song song và
thực thi, ” IEEE Trans. trên Máy tính C-21: 12 (tháng 12), 1411–1415.
GALLAGHER, DM, CHEN, WY, MAHLKE, SA, GYLLENHAAL, JC, VÀ WW HWU [1994]. "Dy định dạng bộ nhớ namic bằng cách
sử dụng bộ đệm xung đột bộ nhớ." Proc. Hội nghị Quốc tế lần thứ sáu về Hỗ trợ Kiến trúc cho Ngôn ngữ Lập
trình và Hệ điều hành (Tháng 10),
Thánh Clare.
HOPKINS, M. [2000]. “Một cái nhìn quan trọng về IA-64: Nguồn lực khổng lồ, ILP khổng lồ, nhưng liệu nó có thể phân bổ được không
P.HSU [1994]. “Thiết kế bộ vi xử lý TFP”, IEEE Micro, Vol.18 Nr.2 (tháng 4), trang 2333.
HWU, WW, MAHLKE, SA, CHEN, WY, CHANG, PP, WARTER , NJ, BRINGMANN, RA,
Machine Translated by Google
OUELLETTE, RO, HANK, RE, KIYOHARA, T., HAAB, GE, HOLM , JG và DM LAVERY
[1993]. “The superblock: Một kỹ thuật hiệu quả để biên dịch VLIW và siêu địa chỉ.” Tạp chí của
Siêu máy tính, 7 (1,2) (tháng 3),: 229--248.
LAM, M. [1988]. “Đường ống phần mềm: Một kỹ thuật lập lịch hiệu quả cho bộ xử lý VLIW,”
SIGPLAN Conf. về Thiết kế và Triển khai Ngôn ngữ Lập trình, ACM (Tháng 6), Atlanta,
Ga., 318–328.
MAHLKE, SA, HANK, RE MCCORMICK, JE AUGUST, DI AND HWU.WW [1995]. “Một con trai của Compari về Hỗ trợ thực
thi toàn bộ và một phần dành riêng cho các Bộ xử lý ILP.” Kỷ yếu ngày 22
Hội nghị chuyên đề quốc tế hàng năm về kiến trúc máy tính (tháng 6), trang 138--149, Santa Margh erita
Ligure, Ý.,
MCFARLING, S. VÀ J. HENNESSY [1986]. “Giảm chi phí của các chi nhánh,” Proc. Hội nghị chuyên đề lần thứ 13
trên Kiến trúc Máy tính (tháng 6), Tokyo, 396–403.
NICOLAU, A. VÀ JA FISHER [1984]. “Đo độ song song có sẵn cho các chỉ dẫn rất dài
từ kiến trúc, ” IEEE Trans. trên Máy tính C-33: 11 (tháng 11), 968–976.
BR RAU [1994]. “Lập lịch mô đun lặp lại: Một thuật toán cho các vòng lặp đường ống phần mềm.”
Proc. Hội nghị chuyên đề quốc tế thường niên lần thứ 27 về vi kiến trúc (tháng 11), trang 63--74, San
Jose, CA.
RAU, BR, CD GLAESER, VÀ RL PICARD [1982]. "Tạo mã hiệu quả cho chiều ngang
kiến trúc: Kỹ thuật biên dịch và hỗ trợ kiến trúc, ” Proc. Hội nghị chuyên đề lần thứ chín về Kiến trúc
Comput er (tháng 4), 131–139.
RAU, BR, DWL YEN, W. YEN, AND RA TOWLE [1989]. “Bộ đặt siêu doanh nghiệp Cydra 5: Triết lý thiết kế,
quyết định và sự đánh đổi,” IEEE Computers 22: 1 (Tháng 1), 12–34.
RISEMAN, EM VÀ CC FOSTER [1972]. “Phần nhỏ mã để tăng cường điều phối song song và
thực thi, ” IEEE Trans. trên Máy tính C-21: 12 (tháng 12), 1411–1415.
THORLIN, JF [1967]. “Tạo mã cho máy tính PIE (thực thi lệnh song song),” Proc.
Spring Joint Computer Conf. 27.
WILSON, RP VÀ MONICA S. LAM [1995]. “Phân tích con trỏ nhạy cảm theo ngữ cảnh hiệu quả cho gam
C Pro,” Proc. Hội nghị ACM SIGPLAN'95 về Thiết kế và Triển khai Ngôn ngữ Lập trình, La Jolla,
CA, Tháng 6, trang 1-12.
BÀI TẬP
Hầu hết các bài tập này vẫn tốt. Những gì chúng ta cần là các bài tập khám phá các khái niệm về dự đoán
và lập lịch đầu cơ.
Bổ sung mới: xem xét vòng lặp đơn giản trong Phần 4.1. Giả sử số lần lặp lại là không xác định, nhưng
lớn. Tìm số lần giải nén tối ưu về mặt lý thuyết bằng cách sử dụng thời gian của vòng lặp trong Phần 4.1
Gợi ý: hãy nhớ lại rằng bạn sẽ cần hai vòng lặp: một vòng lặp chưa cuộn và một vòng lặp không!
4.1 [15] <4.1> Liệt kê tất cả các phụ thuộc (output, anti và true) trong đoạn mã sau đây. Cho biết liệu các phụ thuộc
thực sự có được thực hiện theo vòng lặp hay không. Chỉ ra lý do tại sao vòng lặp là
cho (i = 2; i <100; i = i + 1) {