Базовый CS с нуля
От машинного кода к языку: проследи программу вниз по лестнице
Читать про лестницу от machine code к языку — не то же самое, что самому провести одну программу по каждой ступени. Возьми одну крошечную программу, прогони её через assembly, compiler, interpreter и JIT и своими глазами увидь, как одно и то же намерение становится разными вещами на разных слоях.
Преврати ментальную модель юнита в конкретный, подкреплённый доказательствами эксперимент: возьми одну небольшую программу, понаблюдай отображения один-к-одному и многие-к-одному, сравни compilation с interpretation, увидь runtime в работе и проследи полный конвейер от исходника до исполнения от начала до конца.
Возьми одну крошечную программу — вычислить и напечатать результат арифметического выражения, например (a + b) * c — и проследи её вниз по каждой ступени лестницы, документируя реальным выводом инструментов, как одно и то же намерение становится assembly, нативным machine code, интерпретируемым исполнением и JIT-скомпилированным кодом.
- Таблица трёх путей бок о бок со столбцами: какой артефакт производится, когда происходит трансляция и переносимость — заполненная по тому, что ты реально наблюдал, а не по памяти.
- Короткий аннотированный листинг assembly, где минимум три строки сопоставлены с той одной машинной инструкцией, в которую каждая превращается, плюс число инструкций для одного выбранного высокоуровневого оператора.
- Именованный список минимум трёх использованных сервисов runtime и того, какой runtime (libc, CPython, V8/Node) даёт каждый.
- Однопараграфный разбор шести стадий конвейера для программы на C, называющий реальный инструмент или компонент ОС на каждой стадии (compiler, linker, loader ОС, стартовый код runtime C, CPU).
- Добавь версию на Java или C#, компилирующуюся в bytecode; изучи bytecode (javap -c для Java) и объясни, чем он отличается и от нативного machine code, и от текста исходника.
- Замерь время тесного цикла с упором в CPU во всех версиях и объясни порядок, который наблюдаешь — compiled быстрее всех, interpreted медленнее всех, JIT улучшается после прогрева — связав каждое число со стратегией трансляции.
- Кросс-компилируй программу на C под вторую архитектуру CPU (например ARM) и подтверди, что получившийся бинарник не запустится на исходном CPU, продемонстрировав, что бинарник специфичен для CPU, а исходник переносим.
- Используй инструмент вроде ldd (Linux) или otool -L (macOS), чтобы перечислить разделяемые библиотеки, с которыми твой бинарник на C линкуется во время работы, и свяжи этот вывод обратно со стадиями линковки и загрузки.
Это эксперимент, который превращает лестницу из схемы в то, к чему ты прикоснулся: одна программа, четыре пути, один набор наблюдений. Ты увидел, как assembly отображается один-к-одному в machine code, как один высокоуровневый оператор разворачивается во много инструкций, как compiler произвёл бинарник заранее, а interpreter не произвёл ни одного и JIT произвёл нативный код во время работы, как runtime тихо делает за тебя работу с памятью, библиотекой и call stack, и как шестистадийный конвейер доносит текст исходника до самого цикла CPU fetch-decode-execute.