Компіляторна інженерія Vocabulary: From Lexer to Code Generation
Всеосяжний словник англійської мови для інженерів- компіляторів, який охоплює весь конвейєр від лексики і аналізу до IR, оптимізації і створення коду.
Англійська мова в компіляторі Pipeline
Компіляторна інженерія має багатий і точний словник, який накопичився за десятиліття досліджень і реалізації. Для інженерів, які працюють над компіляторами — чи то пишуть проходження в LLVM, чи роблять внесок в GCC, чи будують мовний фронтенд — спілкування в цьому словнику з плавністю і точністю є необхідним для перегляду коду, обговорення дизайну і документації.
Цей підручник описує процес компіляції з фронт- енд до сервера, описуючи англійські терміни, які використовуються на кожному етапі.
Front-End Vocabulary: Lexing and Parsing (англійською)
Фронт- енд компілятора перетворює текст коду у структуроване представлення.
| Term | Definition |
|---|---|
| Lexer (tokeniser) | The component that reads source characters and produces a stream of tokens |
| Token | A categorised unit of source text, such as an identifier, literal, or keyword |
| Lexeme | The actual character sequence that matched a token pattern |
| Parser | The component that reads a token stream and constructs a parse tree or AST |
| Grammar | A formal description of the syntactic rules of a language |
| Production rule | A single rule in a grammar defining how a non-terminal can be expanded |
| Lookahead | The number of tokens the parser examines ahead of the current position to make a decision |
| Ambiguity | A property of a grammar where a single input can be parsed in multiple ways |
| Abstract Syntax Tree (AST) | A tree representation of the syntactic structure of source code, with implementation detail removed |
При перегляді реалізації аналізатора, поширеним спостереженням є: * “Це правило виробництва є неоднозначним - нам потрібно документувати конвенцію попередження або реструктуризувати граматику.” *
Середній кінець лексики: IR і оптимізація
Середній кінець працює на проміжному представленні (IR), яке є внутрішньою мовою компілятора для аналізу і оптимізації.
| Term | Definition |
|---|---|
| Intermediate Representation (IR) | A language-independent, architecture-independent representation of program semantics |
| Static Single Assignment (SSA) form | An IR property where every variable is assigned exactly once and use-def chains are explicit |
| Phi node (φ-node) | An SSA construct that selects a value based on which predecessor basic block was executed |
| Basic block | A straight-line sequence of instructions with a single entry and single exit |
| Control flow graph (CFG) | A graph where nodes are basic blocks and edges represent possible transfers of control |
| Data flow analysis | A technique for computing properties of values at each program point |
| Dominator | A node D dominates node N if every path to N passes through D |
| Alias analysis | Analysis that determines whether two pointers could refer to the same memory location |
| Inlining | Replacing a function call with a copy of the called function’s body |
| Loop invariant code motion (LICM) | Moving computations out of a loop when their result does not change across iterations |
LLVM-специфічний словник
LLVM має власний набір термінів і конвенцій, що використовуються в обговореннях, документації і перегляді коду.
| Term | Definition |
|---|---|
| Pass | A transformation or analysis that operates on the IR; LLVM programs are optimised by a sequence of passes |
| Analysis pass | A pass that computes information about the IR without modifying it |
| Transform pass | A pass that modifies the IR to improve it in some way |
| Pass manager | The infrastructure that schedules and runs passes efficiently |
| Canonicalise | To transform an IR construct into a standard, normalised form that is easier to reason about |
| Emit | To produce output — either a new IR form or target machine code |
| Legalization | The process of transforming IR operations into forms the target machine supports |
| Instruction selection | The mapping of IR instructions to target machine instructions |
| Register allocation | The assignment of IR virtual registers to physical machine registers |
| Spill | To move a value from a register to memory because there are insufficient registers available |
У перегляді коду LLVM, «canonicalise» є часто використовуваною інструкцією: «Перед оптимізацією цього шаблону, канонізуйте його до форми, яку очікує середній кінець.»
Back-End Vocabulary: Визначення регістрів і генерація коду
| Term | Definition |
|---|---|
| Virtual register | An unlimited, abstract register used in IR before register allocation |
| Calling convention | The protocol governing how arguments, return values, and registers are managed across function calls |
| Prologue / Epilogue | The function entry/exit code that sets up and tears down the stack frame |
| Peephole optimisation | A local optimisation that examines a small window of instructions and replaces them with more efficient equivalents |
| Instruction scheduling | Reordering instructions to improve performance, typically to avoid pipeline stalls |
| Relocation | A reference in object code that must be resolved to an address at link time |
| Object file | The output of the assembler, containing machine code and metadata for the linker |
Приклади висловлювань
- “Поточний лексер неправильно обробляє ідентифікатори Unicode — нам потрібно оновити правила класифікації токенів до наступного випуску.”
-
- “Після побудови SSA всі вузли phi у блоку вводу є тривіальними і їх можна вилучити — прохід mem2reg повинен обробляти це автоматично.” *
- “Це перетворення канонізує всі інструкції GEP до нормалізованої форми, що робить подальший аналіз псевдонімів більш точним.”
-
- “Реєстр розподілу агресивно розливається у цій гарячій петлі; нам слід перевірити тиск регістра і розглянути розділення петлі на дві фази.” *
- “Базова частина LLVM видає пролог функції, який є непотрібно великим для функцій листка — ми можемо застосувати оптимізацію функції листка, щоб виключити налаштування вказівника кадру.”
Інформаційні технології для інженерів
Під час обговорення вади компілятора, розрізняйте між ** помилкою компіляції ** (компілятор створює неправильний код) і ** аварією компілятора ** (компілятор не може створити вивід). Вони мають різні підходи до зневадження і різні рівні тяжкості.
Під час написання документації про проходження або коментарів до коду, віддавайте перевагу активному голосу і наказовому настрою: “Це проходження перетворює… Аналіз обчислює… Викликає це проходження після…” — а не “Це проходження використовується для перетворення…”
Дієслово **« lower » ** має певне значення у словнику компілятора: замінити конструктор IR високого рівня більш конкретним, ближчим до машини- цілі. * « Ми знижуємо внутрішні властивості до вбудованих властивостей, специфічних для платформи, на стадії легалізації. » * Уникайте використання цього слова у повсякденному сенсі під час написання документації компілятора.
Наприклад, слово «філософія» має такі значення: практичне застосування та загальна лексика
Будьмо чесними – «лексичний аналіз» не йде з мови. Як інженер-компілятор, ви не просто * розумієте * ці терміни; вам потрібно ефективно їх пояснити, як у документації, так і під час обговорення з колегами. Часто найбільша перешкода - це не технічні деталі, а сама фраза. Це про передачу точності без звучання надто академічним або жаргонним.
Часта фраза, яку ви почуєте, особливо під час перегляду роботи іншого інженера, — це « сформований код потребує більш агресивної оптимізації ». Це не просто « поганий код ». Це конкретний запит, пов’ язаний з * результатом * — продуктивністю. Аналогічно, сказати «ІР може отримати користь від розгортання петлі» не критикує дизайн; це пропонує поліпшення, яке відповідає меті проміжного представлення. Сфокусування на впливі рішень, а не тільки на самому процесі, є ключовим для чіткого спілкування. Подумайте про зміни в плані вимірюваних результатів - “зменшення сліду пам’яті на X%” або “покращення паралельності рівня інструкцій”
Іншою областю, де нюанс має значення, є обговорення помилок. Замість того, щоб сказати « Лексер зазнав невдачі », більш корисним і професійним буде сказати: « Лексер зустрів несподівану послідовність символів, що призвело до помилки аналізу ». Ця подробиця надає контекст, не здаваючись одночасно технічним повідомленням про проблему. Аналогічно, під час перегляду коду, замість того, щоб просто сказати « це потребує виправлення », розгляньте щось на зразок « продуктивність цієї секції можна поліпшити за допомогою переробки структури даних ». Це стосується пропонування конструктивної пропозиції з чіткими аргументами.
Нарешті, не соромтеся використовувати активний голос – це робить ваші пояснення яснішими і більш прямими. Замість « Код був створений… », скажіть « Ми створили код… » Це ненадовго змінює відповідальність і підкреслює дію.
Ось приклад, який показує, як використовувати clang-format для забезпечення послідовності стилів:
clang-format -i my_source.cЦя команда автоматично переформатує вміст my_source.c, забезпечуючи, що він буде відповідати вказаним правилам форматування — практичне застосування для розуміння створення коду і пов’ язаних з ним інструментів. Це про те, щоб взяти контроль, а не просто пасивно приймати результат.