Як працює 128-розрядний цілий `i128` Руста на 64-бітній системі?

Іржа має 128-бітні цілі числа, вони позначаються типом даних i128(і u128для непідписаних вкладишів):

let a: i128 = 170141183460469231731687303715884105727;

Як Rust змушує ці i128значення працювати в 64-бітній системі; наприклад, як це робить арифметику на них?

Оскільки, наскільки я знаю, значення не може вміститися в одному реєстрі процесора x86-64, чи компілятор якось використовує 2 регістри для одного i128значення? Або вони замість цього використовують якусь велику цілу структуру для їх представлення?

Усі цілі типи Руста складені в цілі числа LLVM . Абстрактна машина LLVM дозволяє цілі числа будь-якої ширини бітів від 1 до 2 ^ 23 - 1. * Інструкції LLVM зазвичай працюють на цілі числа будь-якого розміру.

Очевидно, що там не так багато 8388607-бітових архітектур, тож коли код компілюється в нативний машинний код, LLVM повинен вирішити, як його реалізувати. Семантика подібної абстрактної інструкції addвизначається самим LLVM. Як правило, абстрактні інструкції, що мають еквівалент однонаправленої інструкції в кодовому коді, будуть складені до цієї нативній інструкції, тоді як ті, що не будуть імітуватися, можливо, з декількома нативними інструкціями. Відповідь mcarton демонструє, як LLVM компілює як рідні, так і емульовані інструкції.

(Це стосується не лише цілих чисел, які можуть підтримувати вбудована машина, але й тих, які менші. Наприклад, сучасні архітектури можуть не підтримувати нативну 8-бітну арифметику, тому може бути емуляція addінструкції щодо двох i8s при більш широкій інструкції додаткові біти відкидаються.)

Чи компілятор якось використовує 2 регістри для одного i128значення? Або вони використовують якусь велику цілу структуру для їх представлення?

На рівні ІР LLVM відповідь не є жодним: i128вписується в єдиний реєстр, як і будь-який інший однозначний тип . З іншого боку, щойно переведений на машинний код, насправді різниці між ними не існує, тому що структури можуть бути розкладені на регістри так само, як цілі числа. Однак, виконуючи арифметику, це досить безпечна ставка, що LLVM просто завантажить всю справу в два регістри.

* Однак, не всі пакети LLVM створюються рівними. Ця відповідь стосується x86-64. Я розумію, що підтримка бекенда для розмірів, більших за 128, та двох не потужностей, є плямистими (що частково може пояснити, чому Руст виставляє лише 8, 16-, 32-, 64- та 128-бітні цілі числа). За даними est31 про Reddit , rustc реалізує 128-бітні цілі числа в програмному забезпеченні під час націлювання на бекенд, який не підтримує їх на самому світі.

Компілятор буде зберігати їх у декількох регістрах і використовувати численні інструкції, щоб виконати арифметику цих значень, якщо потрібно. Більшість ISA мають інструкцію щодо додаткового перенесення, як x86,adc що робить її досить ефективною для додавання / підрозділу з цілою цілою чисельністю.

Наприклад, дано

fn main() {
    let a = 42u128;
    let b = a + 1337;
}

компілятор створює наступне при компілюванні для x86-64 без оптимізації:
(коментарі додав @PeterCordes)

playground::main:
    sub rsp, 56
    mov qword ptr [rsp + 32], 0
    mov qword ptr [rsp + 24], 42         # store 128-bit 0:42 on the stack
                                         # little-endian = low half at lower address

    mov rax, qword ptr [rsp + 24]
    mov rcx, qword ptr [rsp + 32]        # reload it to registers

    add rax, 1337                        # add 1337 to the low half
    adc rcx, 0                           # propagate carry to the high half. 1337u128 >> 64 = 0

    setb    dl                           # save carry-out (setb is an alias for setc)
    mov rsi, rax
    test    dl, 1                        # check carry-out (to detect overflow)
    mov qword ptr [rsp + 16], rax        # store the low half result
    mov qword ptr [rsp + 8], rsi         # store another copy of the low half
    mov qword ptr [rsp], rcx             # store the high half
                             # These are temporary copies of the halves; probably the high half at lower address isn't intentional
    jne .LBB8_2                       # jump if 128-bit add overflowed (to another not-shown block of code after the ret, I think)

    mov rax, qword ptr [rsp + 16]
    mov qword ptr [rsp + 40], rax     # copy low half to RSP+40
    mov rcx, qword ptr [rsp]
    mov qword ptr [rsp + 48], rcx     # copy high half to RSP+48
                  # This is the actual b, in normal little-endian order, forming a u128 at RSP+40
    add rsp, 56
    ret                               # with retval in EAX/RAX = low half result

де ви бачите, що значення 42зберігається в raxі rcx.

(Примітка редактора: x86-64 C виклики викликів повертають 128-бітні цілі числа в RDX: RAX. Але це mainвзагалі не повертає значення. Усі надлишкові копіювання виходять виключно з відключення оптимізації, і що Rust насправді перевіряє наявність переповнення в налагодженні режим.)

Для порівняння, тут розміщено Asm для 64-розрядних цільових чисел Rust на x86-64, де не потрібні додатки з перенесенням, лише один регістр або слот стека для кожного значення.

playground::main:
    sub rsp, 24
    mov qword ptr [rsp + 8], 42           # store
    mov rax, qword ptr [rsp + 8]          # reload
    add rax, 1337                         # add
    setb    cl
    test    cl, 1                         # check for carry-out (overflow)
    mov qword ptr [rsp], rax              # store the result
    jne .LBB8_2                           # branch on non-zero carry-out

    mov rax, qword ptr [rsp]              # reload the result
    mov qword ptr [rsp + 16], rax         # and copy it (to b)
    add rsp, 24
    ret

.LBB8_2:
    call panic function because of integer overflow

Постановка / тест все ще є надлишковим: jc(стрибнути, якщо CF = 1) буде добре працювати.

При включеній оптимізації, компілятор Іржа не перевіряє переповнення так +працює як .wrapping_add().

Так, так само, як оброблялися 64-бітні цілі числа на 32-бітних машинах, або 32-бітні цілі числа на 16-бітних машинах, або навіть 16- і 32-бітні цілі числа на 8-бітних машинах (все ще застосовні до мікроконтролерів! ). Так, ви зберігаєте номер у двох регістрах чи місцях пам'яті, або будь-якому іншому (це не має значення). Додавання та віднімання тривіально, беручи дві інструкції та використовуючи прапор перенесення. Для множення потрібні три множення та деякі доповнення (для 64-бітових чіпів звичайно вже операція множення 64x64-> 128, яка виводиться на два регістри). Ділення ... вимагає підпрограми і є досить повільним (за винятком випадків, коли ділення на константу може бути перетворене на зсув або множення), але воно все одно працює. Побітові та / або / xor повинні бути виконані на верхній і нижній половинах окремо. Зсуви можна здійснити за допомогою обертання та маскування. І це в значній мірі охоплює речі.

Щоб надати більш чіткий приклад, на x86_64, складеному з -Oпрапором, функцію

pub fn leet(a : i128) -> i128 {
    a + 1337
}

компілює до

example::leet:
  mov rdx, rsi
  mov rax, rdi
  add rax, 1337
  adc rdx, 0
  ret

(У моєму початковому дописі було u128не те, про що i128ви просили. Функція комбінує той самий код у будь-якому випадку. Хороша демонстрація того, що додані підписи та без підпису є однаковими в сучасному процесорі.)

Інший перелік видав неоптимізований код. Можна безпечно перейти через налагоджувач, оскільки він гарантує, що ви можете поставити точку перерви в будь-якому місці та перевірити стан будь-якої змінної в будь-якому рядку програми. Це повільніше і важче читати. Оптимізована версія набагато наближається до коду, який фактично працюватиме у виробництві.

Параметр aцієї функції передається в парі 64-бітових регістрів, rsi: rdi. Результат повертається в іншій парі регістрів, rdx: rax. Перші два рядки коду ініціалізують суму до a.

Третій рядок додає 1337 до низького слова введення. Якщо це переповнюється, він несе прапор 1 в переносному процесорі. Четвертий рядок додає нуль до високого слова вводу — плюс 1, якщо воно було здійснено.

Ви можете подумати про це як просте додавання одноцифрового числа до двоцифрового числа

  a  b
+ 0  7
______
 

але в базі 18,446,744,073,709,551,616. Ви все ще додаєте спочатку найнижчу цифру, можливо, переносите 1 у наступний стовпець, потім додаєте наступну цифру плюс переносити. Віднімання дуже схоже.

Множення повинно використовувати тотожність (2⁶⁴a + b) (2⁶⁴c + d) = 2¹²⁸ac + 2⁶⁴ (ad + bc) + bd, де кожне з цих множень повертає верхню половину продукту в один регістр, а нижню половину товару в інший. Деякі з цих термінів будуть відмінені, оскільки біти вище 128-го не вписуються в а u128та відкидаються. Незважаючи на це, для цього потрібна низка інструкцій з машини. Відділ також здійснює кілька кроків. Для підписаного значення, множення та ділення додатково потрібно було б перетворити знаки операндів і результат. Ці операції взагалі не дуже ефективні.

В інших архітектурах це стає простіше або складніше. RISC-V визначає 128-розрядне розширення набору інструкцій, хоча, наскільки мені відомо, ніхто не реалізував його в кремнію. Без цього розширення посібник з архітектури RISC-V рекомендує умовну гілку:addi t0, t1, +imm; blt t0, t1, overflow

SPARC має контрольні коди, як прапори керування x86, але для їх встановлення вам потрібно використовувати спеціальну інструкцію add,cc. MIPS, з іншого боку, вимагає перевірити, чи сума двох непідписаних цілих чисел суворо менша, ніж один із операндів. Якщо так, додаток переповнилося. Принаймні, ви можете встановити інший регістр для значення переносу без умовної гілки.