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 допиливать не надо. собственно, когда-то ж пора и использовать же, а не только фичи добавлять. общая беда всех хороших систем, кстати: после некоторого порога они «перестают развиваться» (по современным понятиям). а потому что всё работает, всё хорошо. не идеально — но хорошо. а кто любит фичи ради фич — сбежал ещё раньше.

кстати, надо бы довести до ума двухуровневый аллокатор на основе идей из TLSF, и инкрементальный GC на основе quad-color algo от Mike Pall. у меня есть PoCи, надо будет в реальную систему сажать. пишу сюда как в блокнотик-напоминашку. ;-)

конечно, в компилятор придётся добавить нормальные write barriers (а не ручками для тестов, как сейчас ;-), но в четырёхцветном GC они весьма дешёвые. а TLSF умеет в больше разных корзинок при той же скорости O(1), потому фрагментация меньше. для полноты картины ещё инкрементальный sweep нужен — и почти рилтайм-система будет, хихи.

алсо, если у кого-то ещё свербит «популяризация оберона» — то смиритесь: это невозможно. мы тут по результатам некоторых обсуждений выяснили две коренных обероновских проблемы:
1. оберон слишком простой.
2. оберон слишком сложный.
обе наблюдаются одновременно.

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

жиза, как говориться ))

ещё какая. в итоге это приводит к утверждению: «оберон слишком сложный потому что слишком простой!»

на самом деле оно даже не так парадоксально, как кажется на первый взгляд: современный погромист не может ничего написать без огромной кучи библиотек (включая стандартную, куда навалено хлама выше эвереста), шаблончиков-генериков, синтаксического сахара типа `foreach` (за который они почему-то сражаются отчаянней всего) и прочего хлама.

им реально сложно. от идеи сделать руками простой двусвязный список, а не использовать для этой неподъёмной задачи «стандартный контейнер» — приходят в ужас. с их точки зрения оберон — это такой стрёмный ассемблер, который придумали мазохисты для мазохистов (или садисты для мазохистов, тут консенсуса нет). с ужасным time-to-market.

а, и ещё оберон УЖАСНО КРИЧИТ НА ПРОГРАММИСТА!

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

А подсветка криптосинтаксисов - это норм... Снежинки...

ага. вообще, очень смешно видеть, что большинство не понимает, почему обероновский КАПС — это точно та же самая «подсветка синтаксиса», только ещё и редакторонезависимая, и волшебно не требующая дополнительного кода.

впрочем, это претензия из того же детсадика, что и: «там ужасный синтаксис, фигурные скобочки удобные, а BEGIN/END писать тяжело и некрасиво!»

вообще, единственная претензия, которая более-менее имеет смысл — это отсутствие генериков. и та сова на глобусе. я тут где-то на форуме писал, как можно сделать шаблоны просто обёртками над читалками документов, если надо. мне, правда, до сих пор не понадобилось, и я не сделал. ;-)

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

генерики в некоторых вариантах оберона есть

в oo2c. и мне они не нравятся. ;-)

Во всех вариантах Oberon есть дженерики, или как вариант — дженериков нет, но они работают.

Clojure рулит! И, конечно, Factor.

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