2015-06-19 12 views
5

Câu hỏi của tôi phát sinh từ sự tò mò đơn giản:Lắp ráp: tại sao một số mã x86 không hợp lệ trong x64?

Tại sao x64 một số mã không hợp lệ (06, 07 chẳng hạn), trong khi x86 được sử dụng cho hướng dẫn khá cơ bản (06 và 07 là push và pop)? Tôi cho rằng những hướng dẫn đơn giản nhất đó sẽ làm tốt trong cả hai kiến ​​trúc.

Tại sao họ vô hiệu hóa một số hướng dẫn đơn giản trong x64? Tại sao họ không làm việc? Tại sao họ vô hiệu hóa một số opcodes, tạo lỗ trong danh sách opcode, khi họ có thể thay vì gán chúng cho các phiên bản x64 của hướng dẫn?

tham khảo:

http://ref.x86asm.net/coder32.html

http://ref.x86asm.net/coder64.html

+1

Đăng ký phân khúc Push/popping chỉ không có ý nghĩa gì ở chế độ x64. –

Trả lời

8

Các 06 và 07 opcodes ở chế độ 32-bit là hướng dẫn PUSH ESPOP ES. Trong chế độ 64 bit, phân khúc đăng ký CS, DS, ES và SS không còn được sử dụng để xác định địa chỉ bộ nhớ: bộ xử lý giả định địa chỉ cơ sở là 0 và không có giới hạn kích thước. Vì hiện tại không có lý do gì cho các ứng dụng (ngoài chính hệ điều hành) để truy cập vào các thanh ghi này, các opcodes cho việc thay đổi và truy cập chúng đã bị loại bỏ.

Thanh ghi phân khúc FS và GS vẫn có thể đặt địa chỉ cơ sở ở chế độ 64 bit, do đó các mã opcodes liên quan đến chúng chưa bị xóa.

+0

CS vẫn được sử dụng thực sự. – harold

+0

@harold Bạn nói đúng, nó vẫn được sử dụng để đặt thuộc tính cho đoạn mã (chẳng hạn như bật chế độ 64 bit), nhưng không còn được sử dụng để xác định địa chỉ bộ nhớ. – interjay

3

Đối với tất cả các CPU, có thứ gì đó giống như "không gian opcode". Ví dụ, nếu một CPU sử dụng 8-bit opcodes thì sẽ có một max. trong số 256 hướng dẫn có thể có. Các opcodes lớn hơn là nhiều opcodes bạn có thể có, nhưng khó khăn hơn để lấy và giải mã chúng một cách nhanh chóng.

80x86 là kiến ​​trúc tương đối cũ. Nó bắt đầu với một không gian opcode khiêm tốn bao gồm chủ yếu là 1-byte và 2-byte opcodes. Mỗi khi các nhà sản xuất CPU thêm một tính năng mới, nó sẽ mất nhiều opcodes hơn từ không gian opcode. Họ chạy ra khỏi opcodes. Họ nhanh chóng chạy ra ngoài.

Để giải quyết vấn đề, họ bắt đầu thực hiện những việc như thêm mã thoát và tiền tố để mở rộng không gian opcode giả tạo. Ví dụ, đối với các hướng dẫn AVX gần đây bạn đang xem tiền tố VEX theo sau là mã thoát cũ/tái chế (ví dụ 0xF0), tiếp theo là tiền tố kích thước địa chỉ/toán hạng cũ/tái chế (ví dụ 0x66), tiếp theo là 4 byte khác . Nó không đẹp.

Đồng thời có hướng dẫn cũ hiếm khi được sử dụng hiện nay (AAD, AAM, v.v.) và hướng dẫn có nhiều opcodes dư thừa (INC/DEC) đã tiêu thụ opcodes "1 byte" có giá trị. Những không thể/không thể được loại bỏ hoàn toàn do khả năng tương thích ngược.

Tuy nhiên; khi 64-bit được thiết kế, đơn giản là không có mã 64-bit nào tương thích với - khả năng tương thích ngược không quan trọng. Các opcode 1-byte được tiêu thụ bởi các lệnh "không quan trọng" có thể được tái chế; làm cho các lệnh đó không hợp lệ trong mã 64 bit (nhưng giải phóng một số mã opcode 1 byte có giá trị).

Hầu hết các mã vạch 1 byte này (toàn bộ nhóm INC/DEC 1 byte nếu tôi nhớ đúng) đã được tái chế ngay lập tức cho tiền tố REX cần để hỗ trợ các toán hạng 64 bit. Một số không và đã trở thành "miễn phí cho các phần mở rộng trong tương lai" (với sự hạn chế rằng phần mở rộng chỉ có thể làm việc trong mã 64-bit bởi vì những hướng dẫn vẫn còn hợp lệ trong mã 16-bit và 32-bit).

+0

Có các hướng dẫn khác có thể đã bị xóa cho chế độ AMD64. Họ thậm chí có thể đã thiết kế lại hoàn toàn mã hóa nhị phân. Tôi cho rằng lý do * không * tạo ra nhiều thay đổi là vì vậy silicon tương tự có thể giải mã chế độ 32 và 64 bit, mà không có nhiều logic điều kiện phụ thuộc vào chế độ CPU nào đang ở. –

Các vấn đề liên quan