OberonCore

В ящике есть какой-то профайлер, может его можно приспособить для поиска таких мест и делать подсказки кодогену для следующей компиляции.

в ящике нет никакого профайлера. то, что там есть — это профанация; завезено для галочки «мы типа как взрослые». посмотри в его код — и очень ох… умилишься.

Ну сделать "как у взрослых". Проблема чтоли.
Для микрооптимизаций он и не делался.

он вообще делался непонятно для чего, потому что реально показывает инфу с потолка. может попадёт на мелкую часто вызываемую процедуру, может нет, может иногда… я с таким же успехом могу и костяшку кинуть: результат по надёжности не будет сильно отличаться.

эту чушь надо просто выкинуть, и ввести в компилятор режим создания «инструментированого» кода.

впрочем, идея использовать подобную информацию (статически собраную фиг знает при каком workflow) для микрооптимизаций кривая в самой своей основе. опять-таки можно просто костяшку кинуть. проще добавить в компилятор специальный флаг (которым можно отмечать циклы), и пусть программер дальше сам думает, когда его ставить, а когда нет.

итак, форт-система теперь генерирует честный машинный код. пока тупой, сейчас буду делать для неё промежуточное представление, и SSA-кодоген.

а потом сделать компилятор компонентного паскаля на форте, и пересадить ящик на это Чудовище, хихихи. ну, или просто кодоген для стековой вм, которую использует компилятор форта.

вообще, кстати, если подумать — то зачем ящик сохраняет сгенерированый машинный код на диск? какой смысл? даже символьные файлы — и те не особо нужны (хотя они удобны для определения изменений в модулях). ну, нужен базовый образ: ядро и минимальный набор модулей поддержки, плюс компилятор. всё остальное можно тупо компилировать в память при необходимости, не сохраняя на диск вообще. скорость компиляции сейчас быстрее, чем запись на внешний носитель, лол.

ну да, производители проприетарщины, любящие зажать исходники, рыдают кровавыми слезами. их проблемы. пусть делают монолитные бинарники со всеми модулями внутри, и отказываются от динамической загрузки.

а вы знали, знали?! часть очередная.

а вы знаете, что инструкция xchg reg32, reg32 на том, что сейчас называется x86 — адовый тормоз? обменивать регистры местами при помощи трёх mov и промежуточного регистра быстрее. причём ощутимо быстрее. судя по таймингам, в интеле посчитали, что это совершенно бесполезная инструкция, и выкинули её в микрокод. не удивлюсь, если она вообще не взаимодействует нормально с register remapper'ом, адово сталит и всё ломает.

спасибо, интели, низкий вам поклон! головы себе в микрокод засуньте, они ж вам всё равно не нужны.

p.s.: я в курсе про автолочку на xchg с памятью. но два регистра никакой автолочки не делают. (хахахаха, так написано в официальной документации, вот ты лох, ведёшься до сих пор!)

мой форт, если что, переключает стеки через "xchg ebp, esp". блин. да, замена на три "mov" дала выигрыш на всём, начиная с пересборки самой системы.

и пэпээс: я не в состоянии читать талмуды Агнера Фокса: у меня для этого слишком маленький мозг. не помещается.

опытным путём выяснено: равнять начало цикла на 4 байта смысл есть. небольшой, но есть. равнять сильнее смысла нет никакого, разница в пределах статпогрешности. вот это вполне можно в CP2 засунуть.

по итогам живых наблюдений совсем неоптимального генератора машинного кода я пришёл к выводу, что CP2 даже чересчур оптимизирует. потому что он иногда способен запомнить значение регистра после выражения, и использовать в следующем — шибко уж умный.

а старательная оптимизация для современных x86 имеет очень мало смысла. ну вот, 38 кб довольно прямолинейного peephole (который даже не весь код сканирует, а только последние несколько инструкций после инлайна) всего примерно в 2.5 раз медленней, чем сотни мегабайт gcc -O2. это на самом деле очень прискорбно с учётом моей любви к написанию компиляторов. в peephole примерно 20 паттернов, если что, и код всё ещё выглядит как куча push и pop (форт потому что).

в общем, сканирование файла в 2гб, разбитие его на строки, и создание двух aa-деревьев на сишечке занимает ~1.5 секунды, а на Beast: Devastator — ~3.9. код более-менее одинаковый, структуры данных тоже. даже файл оба читают порциями по 4 кб. и, естественно, оба кода при непрогретых кэшах одинаково упираются в i/o, и оба пыхтят примерно 15 секунд.

в общем, лично себе я экспериментально и на реальном коде доказал, что при необходимости проще переписать пару процедур и горячих циклов на асме, нежели пытаться учить компилятор оптимизировать сложнее, чем описано в Compiler Construction.

удивительное дело: как только плюнул слюной на стандарт форта — мой код сразу стал переносимым. вот давеча делал форт для z80 — взял, например, кусок x86-системы, который парзер (это и разбор буфера, и парзинг чисел с кучей фич, много, короче) — и оно Просто Скомпилилось. и заработало, как только я поправил баги в паре примитивов. как-то не особо парясь, что с 32 бит на 16 перетащили. и всё это без идиотии типа "CELL" и прочих «стандартных механизмов обеспечения переносимости», которые стандартизаторы считают обязательными.

это я, собственно, к тому, что рулят правильные API, и забота о ненарушении границ абстракций.

кстати сказать, мои любимые конструкции парнаса тоже мигрируют из системы в систему практически без изменений. дёшево, удобно, сердито. реально офигеть какая удобная штука. как будет очередное Великое Допиливание CP2 — обязательно добавлю.

если что — у меня пока что Всё Работает, поэтому BBCB допиливать не надо. собственно, когда-то ж пора и использовать же, а не только фичи добавлять. общая беда всех хороших систем, кстати: после некоторого порога они «перестают развиваться» (по современным понятиям). а потому что всё работает, всё хорошо. не идеально — но хорошо. а кто любит фичи ради фич — сбежал ещё раньше.