WEBASSEMBLY ЯК ПЕРЕНОСНИЙ АСЕМБЛЕР

Вступ: та сама задача, інша машина

x86-64 (Лекція 8) — набір інструкцій конкретного фізичного процесора: те, що вміє виконати кристал Intel чи AMD, і більше нічого. WebAssembly (WASM) розв'язує іншу задачу: дати переносний, компактний, безпечний байт-код, що однаково виконується в Chrome, Firefox, Node.js, Wasmtime чи на мікроконтролері, незалежно від того, ARM це, x86 чи RISC-V під капотом. WASM успадкував головну ідею асемблера — «мова, близька до заліза, без прихованої магії», — але заради переносності відмовився від найінтимнішого атрибута фізичного процесора: регістрів. Замість них — операційний стек.

Важливо одразу розвіяти поширену помилку: WASM — це не заміна JavaScript і не «повільніший JS, що виглядає як асемблер». Це окремий формат байт-коду з власною віртуальною машиною, і рушій браузера компілює його в нативні інструкції (JIT/AOT) так само, як компілює JS — тільки з набагато меншим простором для здогадок про типи, бо типи в WASM статичні й перевірені ще до першого виконання.

Стекова модель виконання

x86-64 обчислює вирази через іменовані регістри: movl -4(%rbp), %eax; addl -8(%rbp), %eax. WASM не має регістрів загального призначення — натомість у кожної функції є операційний стек значень (i32, i64, f32, f64), і кожна інструкція знімає з нього стільки значень, скільки їй треба, а результат кладе назад:

i32.const 2   ;; стек: [2]
i32.const 3   ;; стек: [2, 3]
i32.add       ;; зняти 2 і 3, покласти 5 -> стек: [5]

Це запис у постфіксній (зворотній польській) нотації: порядок інструкцій буквально є порядком обчислення виразу, без потреби в дужках чи пріоритеті операцій. local.get/local.set виконують ту саму роль, що звернення -4(%rbp) в асемблері x86-64 — доступ до параметрів і локальних змінних, тільки не за адресою в пам'яті, а за індексом у таблиці локальних змінних функції.

Типи значень і валідація

WASM MVP (базова специфікація) визначає чотири числові типи: i32, i64 (цілі, без розрізнення знаку — знак визначає інструкція, наприклад i32.div_s проти i32.div_u), f32, f64 (IEEE-754). Сучасні розширення (reference types, SIMD v128, GC) додають funcref, externref, v128, але базова модель курсу — саме чотири числові типи.

Головна відмінність від x86-64: модуль перевіряється (validation) ще до виконання. Рушій статично проходить кожну функцію й переконується, що на кожному кроці стек містить рівно ті типи, яких очікує наступна інструкція. Якщо .wat намагається викликати i32.add, маючи на стеку f64, модуль не завантажиться — на відміну від x86-64, де невідповідність типів на асемблерному рівні просто не існує (там усе — байти, а тип — питання інтерпретації компілятором вищого рівня). Ця валідація — одна з причин, чому WASM безпечний за замовчуванням: неможливо «випадково» виконати довільний код через переплутаний тип, як це можливо через переповнення буфера в C.

Анатомія .wat-модуля

.wat (WebAssembly Text Format) — текстове, людинозрозуміле представлення бінарного .wasm; кожна бінарна конструкція має точний текстовий відповідник, і wat2wasm/wasm2wat конвертують між ними без втрат.

(module
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add)
  (export "add" (func $add)))

• (module ...) — корінь дерева; усе, що є в модулі, вкладено сюди у вигляді S-виразів (та сама дужкова нотація, що в Lisp — кожен вузол дерева синтаксису явний);
• (func $ім'я (param ...) (result ...) тіло) — функція з обов'язковою типізованою сигнатурою; $ім'я — символічний ідентифікатор, який компілюється в числовий індекс у бінарному форматі;
• (export "назва" (func $ім'я)) — робить функцію видимою ззовні модуля, для виклику з JavaScript чи іншого хоста; без експорту функція існує, але недосяжна;
• (import "модуль" "ім'я" (func ...)) — дзеркальна конструкція: імпорт функції (чи пам'яті, таблиці, глобальної змінної) з хост-середовища всередину модуля.

Керування потоком: структурованість замість довільних стрибків

x86-64 має jmp/jcc на довільну мітку — будь-яку адресу коду. WASM свідомо цього не дозволяє: керування потоком структуроване, вкладене, як дужки в мові програмування.

(func $sum_to_n (param $n i32) (result i32)
  (local $i i32) (local $acc i32)
  (block $break
    (loop $continue
      local.get $i
      local.get $n
      i32.ge_s
      br_if $break        ;; вихід з block, якщо i >= n
      local.get $acc
      local.get $i
      i32.add
      local.set $acc
      local.get $i
      i32.const 1
      i32.add
      local.set $i
      br $continue))       ;; повернутися на початок loop
  local.get $acc)

• block ... end — іменована ділянка коду; br $мітка виходить із неї одразу (аналог break);
• loop ... end — на відміну від block, br всередині нього повертається на початок (аналог continue), а не виходить назовні;
• br_if — умовний варіант: знімає i32 зі стека, і якщо він не нуль — виконує br;
• є ще if ... else ... end для структурованого розгалуження без явних міток.

Ця структурованість — не стилістичний вибір, а гарантія: неможливо стрибнути в середину чужої функції чи на довільне зміщення в пам'яті коду, як це технічно можливо (хоч і небезпечно) у x86-64 через самомодифікований код чи пошкоджену адресу повернення. Компілятори (LLVM для Rust/C/C++) генерують ці конструкції автоматично з for/while/loop вихідної мови — вручну писати їх, як у Лекції 8, потрібно лише для навчання самій моделі.

Лінійна пам'ять

Окремо від операційного стека кожен інстанс модуля має лінійну пам'ять (linear memory) — суцільний, адресований з нуля масив байтів, спільний для всіх функцій модуля:

(memory (export "mem") 1)      ;; 1 сторінка = 64 КіБ, зростає динамічно

(func $store_and_load (result i32)
  i32.const 0        ;; адреса
  i32.const 42        ;; значення
  i32.store            ;; memory[0..4] = 42 (little-endian)
  i32.const 0
  i32.load)            ;; читає ті самі 4 байти назад

Пам'ять росте сторінками по 64 КіБ через memory.grow (повертає попередній розмір у сторінках або -1 при відмові — типова точка, де забувають перевірити помилку). Доступ — за i32-адресою через i32.load/i32.store (і 8-, 16-бітні варіанти з суфіксами 8/16). Рядки, масиви, будь-які складні структури живуть саме тут, а не в локальних змінних чи операційному стеку — це прямий аналог того, як у x86-64 масиви й структури живуть за адресами відносно %rbp, тільки замість регістра-бази — фіксована база 0 та єдиний спільний адресний простір модуля.

Критична відмінність від C/асемблера: вихід за межі виділеної пам'яті — це trap (контрольоване переривання виконання з помилкою), а не невизначена поведінка (UB). Рушій завжди перевіряє межі при кожному load/store; заплатити за це доводиться швидкістю (перевірка на кожен доступ), натомість отримуємо гарантію, що модуль фізично не може прочитати чи записати пам'ять поза власною лінійною областю — навіть якщо код усередині модуля містить логічну помилку.

Порівняння з нативним x86-64

Пісочниця (sandbox): модель безпеки за замовчуванням

WASM-модуль не може виконати системний виклик, відкрити файл чи звернутися до мережі напряму — у нього немає інструкції «syscall». Єдиний спосіб взаємодіяти зі світом поза власною лінійною пам'яттю — явно оголошені імпорти, які надає хост (host — браузер чи Node.js) під час інстанціювання. Це капабіліті-модель: модуль отримує рівно ті можливості, які йому явно передали, і жодних інших. У поєднанні зі структурованим керуванням потоком (неможливо стрибнути в довільне місце) і перевіркою меж лінійної пам'яті (неможливо прочитати чужу пам'ять) це робить WASM природним кандидатом для виконання недовіреного коду — саме тому браузер може безпечно запустити модуль, завантажений з довільного сайту.

Живий приклад: .wat у браузері

wat2wasm add.wat -o add.wasm

<script type="module">
  const { instance } = await WebAssembly.instantiateStreaming(fetch('add.wasm'));
  console.log(instance.exports.add(2, 3));   // 5
</script>

instantiateStreaming компілює модуль паралельно з завантаженням байтів по мережі — рушій не чекає, доки файл довантажиться повністю, щоб почати компіляцію перших функцій.

Підводні камені

• Забути export — функція існує в модулі, компілюється, валідується, але недосяжна з JS, доки не оголошена в (export ...).
• Плутати i32.add з i32.div_s/i32.div_u — цілі типи WASM не мають вбудованого знаку; знак визначає інструкція, а не сам тип значення.
• Розраховувати на UB при виході за межі пам'яті, як у C, — WASM завжди робить trap, а не «читає щось випадкове»; це інша модель помилки, яку треба явно ловити на боці хоста.
• Не перевіряти результат memory.grow — при відмові повертається -1 (сторінок), а не викид виключення; код, що ігнорує це, продовжує роботу з пам'яттю, яка насправді не виросла.
• Ігнорувати вирівнювання (align=) як обов'язкову вимогу — це лише підказка рушію для оптимізації, доступ спрацює й без правильного вирівнювання, просто повільніше.
• Намагатися стрибнути на довільну мітку, як у x86-64 jmp — WASM цього структурно не дозволяє; переписувати логіку доведеться через block/br, а не через мітки-адреси.

Розширення специфікації: SIMD, reference types, exception handling

Базова специфікація (WASM MVP, 2017) визначала лише чотири числові типи й структурований потік керування, описані вище. Відтоді специфікація розширилась кількома важливими доповненнями, які станом на 2026 рік підтримує кожен сучасний рушій: reference types (funcref, externref — типізовані посилання на функції та host-об'єкти, потрібні, зокрема, для wasm-bindgen), SIMD (v128 — 128-бітний вектор для паралельної обробки чисел, критичний для кодеків і графіки), tail calls (оптимізація рекурсії без росту стека) і exception handling (нативні try/catch на рівні байт-коду, а не емуляція через коди повернення). Для навчальної моделі курсу достатньо чотирьох базових числових типів — саме вони формують фундамент, на якому побудовані всі розширення.

Підсумок

WebAssembly переносить головну ідею асемблера — пряме, без прихованої магії відображення обчислення на інструкції машини — у формат, незалежний від фізичного процесора. Замість регістрів — операційний стек; замість довільних переходів — структурований block/loop/br; замість «будь-яка адреса процесу» — ізольована, перевірена на межі лінійна пам'ять; замість «довіряй байтам» — валідація типів при завантаженні. Це той самий словник, яким ми говорили в Лекції 8, перекладений на мову, яку розуміє кожен браузер, сервер і мікроконтролер одночасно — і саме ця переносність, разом із вбудованою пісочницею, робить WASM природним місцем призначення для коду, скомпільованого з Rust, який ми розглянемо в Лекції 10.