Свой генератор машинного кода — примерно месяц, и на доказуемость не влияет

Оценка объёма, чтобы вопрос «сколько это займёт» имел числовой ответ.

Что надо написать (одна архитектура, x86-64): выбор инструкций, распределение регистров, вывод объектного файла (ELF), соглашение о вызовах; связывание можно отдать системному линкеру, это экономит много.

Точки отсчёта (по памяти, не замер):

По темпу проекта: за один день написано около 24 000 строк в шести генераторах, все сверены побайтово. По объёму наивный генератор — одна-две цели печати, недели две-три.

Ловушка, из-за которой дольше, чем кажется по строкам. Весь метод стоит на byte-for-byte-comparison, а для машинного кода сравнивать не с чем. Проверять придётся запуском и сравнением поведения — в разы медленнее и ловит меньше.

Итог: наивный генератор, одна архитектура, без оптимизаций, код в 3–10 раз медленнее C — примерно месяц. Догнать C по скорости — годы.

И главное: на доказуемость это не влияет ни на грамм. Убирает зависимость от cc и даёт контроль над скоростью. Полезно, но не про цель — what-is-deferred.

Замерено 18 августа 2026, ветка work/native-x86-backend, отчёт docs/native-x86-backend.md. Оценка объёма подтвердилась (5 350–9 200 строк), две величины выше поправлены:

• «в 3–10 раз медленнее» — на самом деле 1.20× на работе компилятора и 2.30× на арифметике (cc -O0 против cc -O2 на одной и той же точке раскрутки): форму кода задаёт sizeof(fl_value) = 32 байта, а не качество оптимизатора;
• «убирает зависимость от cc» — не убирает. Уходит cc1 (37.5 МБ из 42.0 МБ чужой цепочки), остаются ld, 11 146 строк ручного рантайма на C и glibc — последняя по существу: fl_number_text ищет кратчайшую запись числа перебором через snprintf и strtod.

Связано: byte-for-byte-comparison, games-and-video-are-not-our-case