Tại sao (a% 256) khác với (a & 0xFF)?

Tôi luôn cho rằng khi thực hiện (a % 256)trình tối ưu hóa sẽ tự nhiên sử dụng thao tác bitwise hiệu quả, như thể tôi đã viết (a & 0xFF).

Khi thử nghiệm trên trình biên dịch explorer gcc-6.2 (-O3):

// Type your code here, or load an example.
int mod(int num) {
    return num % 256;
}

mod(int):
    mov     edx, edi
    sar     edx, 31
    shr     edx, 24
    lea     eax, [rdi+rdx]
    movzx   eax, al
    sub     eax, edx
    ret

Và khi thử mã khác:

// Type your code here, or load an example.
int mod(int num) {
    return num & 0xFF;
}

mod(int):
    movzx   eax, dil
    ret

Có vẻ như tôi hoàn toàn thiếu một cái gì đó. Có ý kiến ​​gì không?

Nó không giống nhau. Hãy thử num = -79, và bạn sẽ nhận được kết quả khác nhau từ cả hai hoạt động. (-79) % 256 = -79, trong khi (-79) & 0xfflà một số tích cực.

Sử dụng unsigned int, các hoạt động là như nhau, và mã có thể sẽ giống nhau.

PS- Ai đó đã bình luận

Chúng không nên giống nhau, a % bđược định nghĩa là a - b * floor (a / b).

Đó không phải là cách nó được định nghĩa trong C, C ++, Objective-C (tức là tất cả các ngôn ngữ mà mã trong câu hỏi sẽ biên dịch).

Câu trả lời ngắn

-1 % 256sản lượng -1và không phải 255là -1 & 0xFF. Do đó, việc tối ưu hóa sẽ không chính xác.

Câu trả lời dài

C ++ có quy ước rằng (a/b)*b + a%b == a, điều này có vẻ khá tự nhiên. a/bluôn trả về kết quả số học mà không có phần phân số (cắt ngắn về 0). Kết quả là, a%bcó cùng dấu ahoặc là 0.

Việc phân chia -1/256sản lượng 0và do đó -1%256phải -1đáp ứng điều kiện trên ( (-1%256)*256 + -1%256 == -1). Điều này rõ ràng là khác nhau từ -1&0xFFđó là 0xFF. Do đó, trình biên dịch không thể tối ưu hóa theo cách bạn muốn.

Phần có liên quan trong tiêu chuẩn C ++ [expr.mul §4] kể từ N4606 nêu rõ:

Đối với các toán hạng tích phân, toán /tử mang lại thương số đại số với bất kỳ phần phân số nào bị loại bỏ; nếu thương số a/bcó thể biểu thị theo loại kết quả, (a/b)*b + a%bbằng a[...].

Kích hoạt tối ưu hóa

Tuy nhiên, sử dụng unsignedcác loại, tối ưu hóa sẽ hoàn toàn chính xác , đáp ứng quy ước trên:

unsigned(-1)%256 == 0xFF

Xem thêm này .

Những ngôn ngữ khác

Điều này được xử lý rất khác nhau trên các ngôn ngữ lập trình khác nhau khi bạn có thể tra cứu trên Wikipedia .

Vì C ++ 11, num % 256phải không dương nếu numâm tính.

Vì vậy, mẫu bit sẽ phụ thuộc vào việc triển khai các loại đã ký trên hệ thống của bạn: đối với đối số đầu tiên phủ định, kết quả không phải là trích xuất 8 bit có ý nghĩa nhỏ nhất.

Sẽ là một vấn đề khác nếu numtrong trường hợp của bạn là unsigned: những ngày này tôi gần như mong đợi một trình biên dịch sẽ thực hiện tối ưu hóa mà bạn trích dẫn.

Tôi không có cái nhìn sâu sắc về khả năng ngoại cảm đối với lý luận của nhà soạn nhạc, nhưng trong trường hợp %cần phải xử lý các giá trị âm (và các vòng chia về 0), trong khi &kết quả luôn là 8 bit thấp hơn.

Các sarâm thanh hướng dẫn với tôi như "chuyển số học đúng", làm đầy lên các bit bỏ trống với giá trị dấu bit.

Về mặt toán học, modulo được định nghĩa như sau:

a% b = a - b * sàn (a / b)

Điều này ngay tại đây sẽ làm rõ nó cho bạn. Chúng ta có thể loại bỏ sàn cho số nguyên vì phép chia số nguyên tương đương với sàn (a / b). Tuy nhiên, nếu trình biên dịch sử dụng một thủ thuật chung như bạn đề xuất, thì nó sẽ cần phải hoạt động cho tất cả a và tất cả b. Thật không may, đây không phải là trường hợp. Về mặt toán học, thủ thuật của bạn là chính xác 100% đối với các số nguyên không dấu (Tôi thấy một câu trả lời trạng thái ký số nguyên bị phá vỡ nhưng tôi có thể xác nhận cũng không phủ nhận điều này là -a% b nên dương). Tuy nhiên, bạn có thể làm thủ thuật này cho tất cả b? Chắc là không. Đó là lý do tại sao trình biên dịch không làm điều đó. Xét cho cùng, nếu modulo dễ dàng được viết dưới dạng một thao tác bitwise, thì chúng ta sẽ chỉ cần thêm một mạch modulo như để thêm và các hoạt động khác.