Чому (% 256) відрізняється від (a & 0xFF)?

Я завжди припускав, що, роблячи (a % 256)оптимізатор, природно, буде використовувати ефективну побітну операцію, як ніби я писав (a & 0xFF).

Під час тестування на компіляторі 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

І при спробі іншого коду:

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

mod(int):
    movzx   eax, dil
    ret

Здається, я щось зовсім пропускаю. Будь-які ідеї?

Це не те саме. Спробуйте num = -79, і ви отримаєте різні результати від обох операцій. (-79) % 256 = -79, в той час (-79) & 0xffяк деяке додатне число.

Використовуючи unsigned int, операції однакові, і код, ймовірно, буде однаковим.

PS- Хтось прокоментував

Вони не повинні бути однаковими, a % bвизначається як a - b * floor (a / b).

Це не так, як це визначено в C, C ++, Objective-C (тобто у всіх мовах, з яких збирається код у запитанні).

Коротка відповідь

-1 % 256врожайність, -1а не те, 255що є -1 & 0xFF. Тому оптимізація була б неправильною.

Довга відповідь

C ++ має умову про те (a/b)*b + a%b == a, що здається цілком природним. a/bзавжди повертає арифметичний результат без дробової частини (зрізається в бік 0). Як наслідок, a%bмає такий самий знак, що aабо 0.

Підрозділ -1/256дає 0і , отже , -1%256має бути -1, щоб задовольнити цю умову ( (-1%256)*256 + -1%256 == -1). Це явно відрізняється від того, -1&0xFFщо є 0xFF. Тому компілятор не може оптимізувати потрібний вам спосіб.

У відповідному розділі стандарту C ++ [expr.mul §4] станом на N4606 зазначено:

Для інтегральних операндів /оператор отримує алгебраїчний коефіцієнт з відхиленою дробовою частиною; якщо показник a/bє репрезентативним за типом результату, (a/b)*b + a%bдорівнює a[...].

Включення оптимізації

Однак, використовуючи unsignedтипи, оптимізація була б цілком правильною , задовольняючи вищезгаданій умові:

unsigned(-1)%256 == 0xFF

Дивіться також це .

Інші мови

Це обробляється дуже різними для різних мов програмування, оскільки ви можете шукати у Вікіпедії .

Оскільки C ++ 11, num % 256має бути непозитивним, якщо numнегативним.

Таким чином, бітова модель залежатиме від реалізації підписаних типів у вашій системі: для першого негативного аргументу результатом є не вилучення найменш значущих 8 біт.

Було б іншим питанням, якби numу вашому випадку було unsigned: в ці дні я майже очікував, що компілятор здійснить оптимізацію, яку ви цитуєте.

У мене немає телепатичного розуміння міркувань компілятора, але у випадку %є необхідність впоратися з негативними значеннями (і ділити круги до нуля), тоді як &у результаті завжди є нижчі 8 біт.

Ці sarзвуки команд мені , як «зрушення арифметичного права», заповнюючи звільнилися біти зі знаком бітового значення.

Математично кажучи, модуль визначається таким чином:

a% b = a - b * підлога (a / b)

Це прямо тут має зрозуміти це для вас. Ми можемо ліквідувати підлогу для цілих чисел, оскільки ціле ділення еквівалентно поверху (a / b). Однак, якби компілятор використав загальний трюк, як ви пропонуєте, він повинен працювати для всіх a і all b. На жаль, це просто не так. Математично кажучи, ваш трюк на 100% правильний для непідписаних цілих чисел (я бачу, що у відповіді зазначено, що підписані цілі числа розбиваються, але я можу підтвердити і не спростувати це, оскільки -a% b має бути позитивним). Однак чи можете ви зробити цей трюк для всіх b? Напевно, ні. Ось чому компілятор цього не робить. Зрештою, якби модуль був легко записаний як одна побітова операція, то ми просто додамо модульну схему, як для додавання, так і інші операції.