2012-11-17 15 views
12

Tại sao lệnh x86 INC (gia tăng) và DEC (giảm) không ảnh hưởng đến CF (mang cờ) trong FLAGSREGISTER?lý do tại sao các hướng dẫn INC và DEC không ảnh hưởng đến cờ mang theo?

+1

@AndreasBrinck Câu hỏi đó không phải là về "tại sao?", Cũng như không trả lời câu trả lời cho câu hỏi về lựa chọn thiết kế. –

+4

ĐÂY KHÔNG PHẢI LÀ THUẾ CHÍNH XÁC. Câu hỏi khác hỏi làm thế nào để * sử dụng * INC/DEC và chỉ đơn giản là quan sát carry không được cập nhật. Câu hỏi này hỏi * tại sao * nó không được cập nhật. Tôi thấy thực tế rằng một số người sẵn sàng đóng câu hỏi như là một bản sao chính xác khi nó không phải là, một dấu hiệu cho thấy "người kiểm duyệt" đang nhảy súng. Đó không phải là IMHO hữu ích cho SO. –

Trả lời

23

Để hiểu tại sao bạn có thể cần nhớ các CPU "x86" hiện tại có giá trị 32 bit và 64 bit bắt đầu cuộc sống như nhiều máy 8 bit giới hạn hơn, quay lại Intel 8008. (Tôi đã mã hóa trong thế giới này trở lại 1973, tôi vẫn nhớ (ugh) nó!).

Trong thế giới đó, sổ đăng ký là quý và nhỏ. Bạn cần inc/dec cho các mục đích khác nhau, điều khiển vòng lặp phổ biến nhất. Nhiều vòng liên quan đến việc thực hiện "số học đa độ chính xác" (ví dụ: 16 bit trở lên!) Bằng cách có inc/dec thiết lập bit Z, bạn có thể sử dụng chúng để kiểm soát các vòng lặp khá độc đáo; bằng cách nhấn mạnh các hướng dẫn điều khiển vòng lặp không thay đổi bit mang, việc thực hiện được bảo toàn qua các vòng lặp và bạn có thể thực hiện các phép toán đa nhân mà không cần viết tấn mã để nhớ trạng thái thực hiện.

Điều này làm việc khá tốt, một khi bạn đã quen với tập lệnh xấu xí. Trên các máy hiện đại hơn với kích thước chữ lớn hơn, bạn không cần điều này là nhiều, vì vậy INC và DEC có thể tương đương ngữ nghĩa với ADD ..., 1 vv. Trên thực tế là những gì tôi sử dụng khi tôi cần carry set: -}

Chủ yếu, tôi tránh xa INC và DEC bây giờ, vì chúng cập nhật mã điều kiện một phần, và điều này có thể gây ra các quầy vui nhộn trong đường dẫn, và ADD/SUB thì không. Vì vậy, nơi nó không quan trọng (hầu hết các nơi), tôi sử dụng ADD/SUB để tránh các quầy hàng. Tôi chỉ sử dụng INC/DEC khi giữ mã nhỏ, ví dụ: lắp vào một dòng bộ nhớ cache có kích thước của một hoặc hai hướng dẫn tạo đủ sự khác biệt cho vấn đề. Điều này có lẽ là vô nghĩa nano [nghĩa đen!] - tối ưu hóa, nhưng tôi khá cũ trường học trong thói quen mã hóa của tôi.

Giải thích của tôi cho chúng tôi biết lý do INC/DEC đặt bit không. Tôi không có lời giải thích hấp dẫn đặc biệt là vì sao INC/DEC đặt ký hiệu (và số chẵn lẻ? Bit).

EDIT tháng 4 năm 2016: Dường như vấn đề gian hàng được xử lý tốt hơn trên các x86 hiện đại. Xem INC instruction vs ADD 1: Does it matter?

0

Vì không cần ảnh hưởng. Nó là khá đủ để kiểm tra cờ Zero. Vì vậy, sau khi hướng dẫn inc và dec cờ mang theo vẫn giữ nguyên và trong một số trường hợp là hữu ích này.

4

Các câu hỏi về lý do tại sao dấu khi bạn đã zero cờ được thiết lập bởi inc/dec là tốt nhất giải quyết với câu hỏi: bạn thích làm gì mà không lựa chọn một?

a) for (n=7;n>=0;n--) // translates to `dec + jns` 
b) for (n=8;n>0;n--) // translates to `dec + jnz` 

Như Ira Baxter đã làm rõ, Thực cờ được sử dụng trong rất nhiều các thuật toán - không chỉ multiprecision số học, mà còn để chế biến bitmap nói trong đơn sắc/CGA/EGA kỷ nguyên: này chuyển 80 pixel chiều rộng đặt hàng một pixel right ...

 mov cx, 10 
begin: lodsb 
     rcr al,1 // this is rotate though carry: 
     stosb  // for the algorithm to work, carry must not be destroyed 
     LOOP begin // 

Nhưng sau đó: tại sao tính chẵn lẻ?

Tôi tin rằng câu trả lời là lý do tại sao không. Tập lệnh này là từ cuối những năm 70, khi các bóng bán dẫn bị khan hiếm. Việc từ chối việc tính cờ chẵn lẻ cho một số lệnh cụ thể sẽ không có ý nghĩa gì, nhưng chỉ cần thêm vào sự phức tạp của CPU.

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