You are on page 1of 16

Machine Translated by Google

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

4.5 Hỗ trợ phần cứng để hiển thị nhiều hơn


Song song tại thời gian biên dịch

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

có thể không phát hiện ra nhiều ILP.

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

lệ phát sinh mới được tạo ra.

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ớ.

Hướng dẫn có điều kiện hoặc định trước

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

nhánh trong các chuỗi mã đơn giả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 261

VÍ DỤ : Hãy xem xét đoạn mã sau:

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

THÊM R2, R3, R0


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:

CMOVZ R2, R3, R1

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

cuối đường ống nơi ghi thanh ghi xảy ra.


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

một vị ngữ. Khi vị từ là false, lệnh sẽ trở thành no-op. Đầy

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ể

làm phức tạp việc lập lịch hướng dẫn.

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,

như chúng ta khám phá trong các bài tập.

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

của chính nó, mỗi chu kỳ:

Vị trí hướng dẫn đầu tiên Khe hướng dẫn thứ hai

LW R1.40 (R2) THÊM R3, R4, R5

THÊM R6, R3, R7

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

LW R1.40 (R2) THÊM R3, R4, R5

LWC R8,20 (R10), R10 ADD R6, R3, R7

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.

Tạo mã chính xác và thực thi có điều kiện của dự đoá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ô

điều kiện có khả năng gây ra

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ó

biết rằng điều kiện kiểm soát là đúng.

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

với các hướng dẫn dự đoán làm phức tạp thêm

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

từng đoạn mã và loại bỏ một nhánh có thể làm chậm bộ xử lý nếu mã đó

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

nguy cơ dữ liệu bị đình trệ. Với dự đoán chi nhánh

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

trước một cách chính xác.

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

làm cho nó có điều kiện trên cả hai

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

hướng dẫn, như chúng ta sẽ thấy phần 4.7.

Đầu cơ trình biên dịch với hỗ trợ phần cứng

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

không thể đạt được điều này.

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ó thể có xung đột địa chỉ.

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

hỗ trợ mà chúng tôi khám phá tiếp theo.

Hỗ trợ phần cứng để bảo tồn hành vi ngoại lệ


Để suy đoán một cách tham vọng, chúng ta phải có khả năng di chuyển bất kỳ loại hướng dẫn nào và

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à

không còn đầu cơ.


Machine Translated by Google

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

trình và thường gây ra kết thúc, chẳng hạn như bộ nhớ

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

hướng dẫn không còn mang tính đầu cơ.

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

lệnh tạo ngoại lệ kết thúc không phải là suy đoán,

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;

trong đó A ở 0 (R3) và B ở 0 (R2):

LD R1.0 (R3) ; tải A

BENEZ R1, L1 ; kiểm tra A

LD R1.0 (R2) ; mệnh đề then


J L2 tàu vv
L1: DADDY R1, R1, # 4 ; mệnh đề khác
L2: SD 0 (R3), R1 ; cửa hàng A

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

TRẢ LỜI Đây là mã mới:

LD R1,0 (R3); tải A


LD R14,0 (R2); tải suy đoán B
BEQZ R1, L3 ; nhánh khác của if

DADDI R14, R1, # 4; mệnh đề khác


L3: SD 0 (R3), R14; cửa hàng không tích lũy

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ệ đó.

Sự kết hợp này bảo tồn

hành vi ngoại lệ chính xác.

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.

TRẢ LỜI Đây là mã đạt được điều này:

LD R1.0 (R3) ; tải A


sLD R14,0 (R2); đầu cơ, không kết thúc
BENEZ R1, L1 ; kiểm tra A

SPECCK 0 (R2) ; thực hiện kiểm tra đầu cơ


Machine Translated by Google

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

đăng ký với bit độc của nó được bật,

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ớ

suy đoán sẽ được nhận dạng.


Giả sử R14, không được sử dụng và có sẵn.

TRẢ LỜI Đây là mã (một ”s” tiếp tục opcode chỉ ra một suy đoán trong struction):

LD R1.0 (R3) ; tải A


sLD R14,0 (R2) ; tải trọng đầu cơ B
BEQZ R1, L3 ;

DADDY R14, R1, # 4 ;


L3: SD 0 (R3), R14 ; ngoại lệ cho LW đầu cơ

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

của việc đầu cơ thu được bằng cách cho phép

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ị

có thể được cam kết.

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

nên được kết thúc. Nếu hướng dẫn

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.

Hỗ trợ phần cứng cho đầu cơ tham chiếu bộ nhớ

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à

chuyển lên trên một hoặc nhiều cửa hàng.

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ỉ

định địa chỉ nơi chứa mã sửa lỗi.

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.

4.6 Các vấn đề về cắt ngang

Cơ chế đầu cơ phần cứng so với phần mềm

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

tĩnh thường bao gồm các bộ dự báo nhánh động.

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

đây đã thêm hỗ trợ đặc biệt để cho phép điều này.

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

4.11 Quan điểm lịch sử và tài liệu tham khảo 295

4.11 Quan điểm lịch sử và tài liệu tham khảo

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.

Sự phát triển của các bộ xử lý nhiều vấn đề

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

ví dụ, bộ nhớ ảo và xử lý ngoại lệ, có thể được bỏ qua.

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

dy namic và hỗ trợ bổ sung cho đường dẫn phần mềm. Các

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

hai bộ xử lý quan trọng này.

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,

cả hai đều có thể phát hành kép FP và hoạt động số nguyên.

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áo của cấu trúc khác thường hơn.

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

xác là một giải pháp thực tế.


Machine Translated by Google

4.11 Quan điểm lịch sử và tài liệu tham khảo 297

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.

EPIC và Phát triển IA-64

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.

Người giới thiệu

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.

COLWELL, RP, RP NIX, JJ O'DONNELL, DB PAPWORTH, VÀ PK RODMAN [1987]. "MỘT


Kiến trúc VLIW cho trình biên dịch lập lịch theo dõi, ” Proc. Lời thú nhận thứ hai. 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 3), Palo Alto, Calif.,
180–192.

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

ờ? ” Báo cáo bộ vi xử lý, tháng 2

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

4.11 Quan điểm lịch sử và tài liệu tham khảo 299

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, WY CHEN, W.-M. HWU, BR RAU, VÀ MS SCHLANSKER [1992]. “Sentinel


lập lịch cho các bộ xử lý VLIW và superscalar, ” 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 (tháng 10), Boston, IEEE / ACM, 238–247.

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à

không song song.

cho (i = 2; i <100; i = i + 1) {

You might also like