Tại sao các lệnh x86-64 trên thanh ghi 32-bit lại không có phần trên của thanh ghi 64-bit đầy đủ?

Trong Chuyến tham quan hướng dẫn sử dụng Intel x86-64 , tôi đã đọc

Có lẽ sự thật đáng ngạc nhiên nhất là một lệnh chẳng hạn như MOV EAX, EBXtự động lấy 32 bit trên của RAXthanh ghi.

Tài liệu Intel (3.4.1.1 Thanh ghi Mục đích Chung ở Chế độ 64-Bit trong Kiến trúc Cơ bản thủ công) được trích dẫn tại cùng một nguồn cho chúng ta biết:

• Toán hạng 64 bit tạo ra kết quả 64 bit trong thanh ghi mục đích chung đích.
• Toán hạng 32 bit tạo ra kết quả 32 bit, không được mở rộng thành kết quả 64 bit trong thanh ghi mục đích chung đích.
• Toán hạng 8 bit và 16 bit tạo ra kết quả 8 bit hoặc 16 bit. 56 bit trên hoặc 48 bit (tương ứng) của thanh ghi mục đích chung không bị sửa đổi bởi hoạt động. Nếu kết quả của phép toán 8-bit hoặc 16-bit nhằm mục đích tính toán địa chỉ 64-bit, hãy ký-mở rộng thanh ghi một cách rõ ràng đến 64-bit đầy đủ.

Trong hợp ngữ x86-32 và x86-64, các lệnh 16 bit như

mov ax, bx

không hiển thị loại hành vi "kỳ lạ" này mà từ trên của eax là số 0.

Như vậy: lý do tại sao hành vi này được đưa ra? Thoạt nhìn nó có vẻ phi logic (nhưng lý do có thể là do tôi đã quen với những điều kỳ quặc của hội x86-32).

Tôi không phải AMD hay nói thay cho họ, nhưng tôi sẽ làm theo cách tương tự. Bởi vì việc giảm nửa cao không tạo ra sự phụ thuộc vào giá trị trước đó, nên CPU sẽ phải đợi. Các đăng ký đổi tên cơ chế cơ bản sẽ bị đánh bại nếu nó không được thực hiện theo cách đó.

Bằng cách này, bạn có thể viết mã nhanh bằng cách sử dụng các giá trị 32-bit ở chế độ 64-bit mà không cần phải phá vỡ các phụ thuộc một cách rõ ràng mọi lúc. Nếu không có hành vi này, mọi lệnh 32-bit ở chế độ 64-bit sẽ phải chờ đợi điều gì đó đã xảy ra trước đó, mặc dù phần cao đó hầu như sẽ không bao giờ được sử dụng. (Tạo int64-bit sẽ lãng phí dấu chân bộ nhớ cache và băng thông bộ nhớ; x86-64 hỗ trợ hiệu quả nhất kích thước toán hạng 32 và 64-bit )

Hành vi cho các kích thước toán hạng 8 và 16 bit là một hành vi kỳ lạ. Sự điên rồ về sự phụ thuộc là một trong những lý do mà các lệnh 16-bit bị tránh khỏi hiện nay. x86-64 kế thừa điều này từ 8086 cho 8-bit và 386 cho 16-bit, và quyết định có các thanh ghi 8 và 16-bit hoạt động theo cùng một cách ở chế độ 64-bit như ở chế độ 32-bit.

Xem thêm Tại sao GCC không sử dụng thanh ghi từng phần? để biết chi tiết thực tế về cách ghi vào các thanh ghi từng phần 8 và 16 bit (và các lần đọc tiếp theo của thanh ghi đầy đủ) được xử lý bởi các CPU thực.

Nó chỉ đơn giản là tiết kiệm không gian trong các hướng dẫn và tập lệnh. Bạn có thể di chuyển các giá trị nhỏ tức thời vào thanh ghi 64 bit bằng cách sử dụng các hướng dẫn hiện có (32 bit).

Nó cũng giúp bạn không phải mã hóa các giá trị 8 byte cho MOV RAX, 42, khiMOV EAX, 42 có thể được sử dụng lại.

Việc tối ưu hóa này không quan trọng đối với các ops 8 và 16 bit (vì chúng nhỏ hơn), và việc thay đổi các quy tắc ở đó cũng sẽ phá vỡ mã cũ.

Nếu không có số không mở rộng đến 64 bit, điều đó có nghĩa là một lệnh đọc từ raxsẽ có 2 phụ thuộc cho raxtoán hạng của nó (lệnh ghi vào eaxvà lệnh ghi vào raxtrước nó), điều này có nghĩa là 1) ROB sẽ phải có các mục nhiều phụ thuộc cho một toán hạng duy nhất, có nghĩa là ROB sẽ yêu cầu nhiều logic và bóng bán dẫn hơn, đồng thời chiếm nhiều không gian hơn và việc thực thi sẽ chậm hơn khi chờ đợi phụ thuộc thứ hai không cần thiết có thể mất nhiều thời gian để thực thi; hoặc cách khác là 2), mà tôi đoán sẽ xảy ra với các lệnh 16 bit, giai đoạn cấp phát có thể dừng lại (nghĩa là nếu RAT có phân bổ hoạt động cho một lần axghi và một lần eaxđọc xuất hiện, nó sẽ dừng lại cho đến khi việc axghi ngừng hoạt động ).

mov rdx, 1
mov rax, 6
imul rax, rdx
mov rbx, rax
mov eax, 7 //retires before add rax, 6
mov rdx, rax // has to wait for both imul rax, rdx and mov eax, 7 to finish before dispatch to the execution units, even though the higher order bits are identical anyway

Lợi ích duy nhất của việc mở rộng không bằng 0 là đảm bảo raxbao gồm các bit thứ tự cao hơn , ví dụ: nếu ban đầu nó chứa 0xffffffffffffffff, kết quả sẽ là 0xffffffff00000007, nhưng có rất ít lý do để ISA thực hiện đảm bảo này với chi phí như vậy, và nhiều khả năng lợi ích của phần mở rộng bằng không sẽ thực sự được yêu cầu nhiều hơn, vì vậy nó tiết kiệm thêm dòng mã mov rax, 0. Bằng cách đảm bảo rằng nó sẽ luôn bằng 0 được mở rộng đến 64 bit, các trình biên dịch có thể làm việc với tiên đề này trong khi thực hiện mov rdx, rax, raxchỉ phải đợi một phụ thuộc duy nhất của nó, có nghĩa là nó có thể bắt đầu thực thi nhanh hơn và rút lui, giải phóng các đơn vị thực thi. Hơn nữa, nó cũng cho phép các thành ngữ số 0 hiệu quả hơn như xor eax, eaxsố 0 raxmà không yêu cầu byte REX.