OberonCore

а. и сразу отвечу на вопрос, который никто не задавал: «зачем ещё один компилятор оберона? их и так немеряно, и они всё равно никому не нужны!»

ответ, тащемта, простой: а потому что могу! я уже где-то упоминал, что мне просто нравится писать компиляторы — вот и вся причина.

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

и вот кстати: явный импорт глобалов — хорошо! нашёл в тестах пару опечаток, где вместо локала глобал был. конечно, Сознательные Программисты скажут, что надо просто соблюдать naming conventions — и таких проблем никогда не будет. а я отвечу, что пинок от компилятора всё равно лучше.

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

такую фиготень можно писать где угодно, так что быстроимпорт пары процедур «по месту» вполне себе сработает.

константа, конечно, не обязательна, можно и строковый литерал.

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

а заодно прибил гвоздями ключевые слова после `END`. теперь обязательно `END IF`, `END WHILE`, `END FOR`. иба ваистену. конечно, не надо писать кучу вложеной ерунды, но мир не идеален. кто читал лесенки с IF/WHILE/FOR, тот оценит.

«эксперимент» даже скомпилялся (без GC), но не работает. но скомпилялся. ну, то есть, он запустился и сделал ничего за «0.006464 secs.» есть мнение, что надо так и оставить — и тогда мой компилер будет самым быстрым обероном на диком западе!

p.s.: и ну, как минимум не сегфолтнулся. это уже хорошо.

да блин! ну кто б мог подумать (я, например), что Nanojit не делает за меня важную работу. в частности — не перетасовывает индексы параметров функции так, чтобы опкод `paramp` к ним обращался правильно?

непонятно? а я поясню, я такой. вот мы берём, например, и передаём `REAL`. который восьмибайтовое плавающее. и что происходит? происходит то, что его кладут на стек, и он занимает два стековых слота. о чём Nanojit в курсе (потому что генерит правильный асм-код вызова), но подрихтовать взятие параметра — неа. надо ручками помнить, что один слот скипается.

угадайте, кто в компилере на это забил, и брал `b` из `paramp(1)`?

на самом деле всё ещё хуже, потому что эти штуки зависят от архитектуры и ABI. вот для x86 и `FASTCALL` первые два аргумента, которые ЦЕЛЫЕ — передаются в ECX и EDX. то есть, вы поняли прикол? с `FASTCALL` будет так:

что, страшно? а вот потому что при `fastcall` первые два `paramp` — всегда ECX и EDX. иба. вот так Nanojit устроен. хоть убейся.

и самый кайф в том, что никакого API для выяснения как количества аргументов в регистрах, так и того, какие аргументы куда попадают и сколько занимают — нет. предполагается, что пользователь Nanojit залепит кучу ифдефов и сделает всё это сам. опа-опа, зелёная ограда.

в общем, пришлось запилить растусовку аргументов руками. теперь fastcall и thiscall нормально работают. и Эксперимент даже одну строку чисел выводит. а потом падает. как говорится: «эксперимент, очевидно, неудачный.»

и я там сверху ошибся: где «fastcall» — там надо читать «thiscall». а при fastcall `paramp(1)` вообще будет неиспользованый.

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

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

для сравнения: ящиковский вариант у меня работает тридцать секунд. вариант на O/Ur всё ещё быстрее: в районе нескольких миллисекунд! ну и что, что считает ерунду? зато быстро-то как!

эт-то я, однако, мощно влупил, перепутав приоритеты сложения и умножения. ай да я, ай да сукин сын!

в общем, эксперимент отработал, вроде бы даже приблизительно вывод похож на блэкбоксовский (плюс-минус округления). быстрее на десять секунд: за двадцать. правда, у меня нет проверок на NIL pointer dereference, я полагаюсь на ось. и память я освобождаю руками, а не через GC.

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

проверки на выход за диапазона массива есть, конечно.

добавил в кодоген проверки на NIL. ухудшилось на две секунды, всё ещё быстрее, чем BB.

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

конечно, код эксперимента довольно грустный, и его можно сильно улучшить — но цель-то не в этом.

удержаться, конечно, невозможно: заменил везде массивы на статические, получил 15 секунд вместо 22. и BBCB выиграл на полторы секунды, лол.

да блин! вспомнил, что забыл сделать `(expr AS TypeName)` — это у нас dynamic cast. соответственно, а кто мешает сделать `(expr AS REAL)`, например, для преобразования (а не перекрашивания) выражения в другой тип? единообразие! и никаких конфликтов значений с `CAST`.

и получается, что `ORD(charexpr)` — это тупо короткий синоним `(charexpr AS INTEGER)`. а почему бы и да? в принципе, тогда есть смысл просто уничтожить `ORD()`, `BITS()` и прочие: легаси-кода на Oberon/Ur не существует; а код с других оберонов всё равно чинить надо. да, длинно. а не надо динкастить направо и налево потому что. `ENTIER()` тоже не нужен, кстати. и это хорошо, потому что у меня пока нет лонгинтов (потом сделаю, сейчас лень).

и да: `LONG()` и `SHORT()` тоже в мусорку тогда. они мне никогда не нравились: совершенно неочевидно, какой в итоге тип получается. приходится смотреть на объявление переменной. неудобно. всё по заветам Вирта: убираем лишнее, заменяем на единообразную конструкцию.

и про ассерты. ассерты — хорошо. очень хорошо. а чтобы это было реально так, можно (и нужно) добавить в компилер правило: если в начале кода есть `ASSERT(p # NIL);` — то дальше проверки на NIL можно не делать (пока `p` что-то не присвоили, натурально).

и, кстати. во-первых, надо запретить присваивание `self`у в методах. во-вторых, в виртуальных методах, где `self` — указатель, проверки селфа тоже не нужны. по очевидной причине.

ещё неплохо бы убирать проверки на выход за пределы массива в FOR. ну, где обе границы очевидны (не только числа, но и, например, `0 TO LEN(arr) - 1`).

с другой же стороны — это усложняет компилятор, а реального выигрыша… в оригинальном эксперименте убирание всех проверок на NIL ускоряет всё на две секунды (22 -> 20). убирание проверок индексов (всех) — тоже две секунды. окей, 17 секунд vs 22 секунды. в версии же со статическими массивами и статическим объектом ускорение (общее) примерно секунды полторы. не вижу смысла усложнять компилер.

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

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

а! я понял, кажись! если я убираю насильственное зануление локалов — то O/Ur быстрее ящика даже со всеми проверками (примерно на секунду). это довольно странно, потому что я проверял на LC, а в LC у меня тоже включено насильственное зануление ВСЕХ локалов.

сделал зануление стека как делает CP2 (инлайновым кодом) — скорость сравнялась. таки ой.

запилил, наконец, модуль `SYSTEM`. не поверите просто сколько всякой фигни можно сделать совсем без него! (шутейка за полтос.) есть тип `SYSTEM.ADDRESS` (беззнаковый), арифметика с ним, `SYSTEM.ADR()`, `SYSTEM.GET()`, `SYSTEM.PUT()`, `SYSTEM.CAST()`.

кастование не делает перекрашивание пока, а только кастует указатели в адреса и обратно. а, нет, делает: можно перекрасить `SHORTREAL` в `SET` и взад. остальное сделаю по мере надобности.

добавил буилтин `ERASE(@var)`. собственно, просто зануляет переменную/записть/массив. поскольку строки нужно предвалительно декрефнуть — то это не просто аналог заполнения нулями. мне эта штука внутри понадобилась для автозануления `OUT`ов на входе в процедуру — ну и сделал её доступной, почему бы и да.

и, кстати, для копирования массивов и записей обязательно использовать `COPY(@src, ^dest)`.

до сих пор стараюсь не вводить в язык постфиксный `^`: везде, где надо, дереф сделают автоматически. для того и `COPY()`, кстати — оно тоже сделает автодереф. собственно, единственное место, где может понадобиться явный дереф — это `TYPEID(a)` и `TYPEID(a^)` — но я лучше вместо этого сделаю отдельные процедуры: `TYPEID()` всегда автодерефает, а `RAWTYPEID()` — нет.

собственно, крышка-дереф действительно в языке совершенно не нужна. поскольку у нас бывают указатели только на записи и массивы, то вполне очевидно, что `a # NIL` — дереф не нужен. а если есть десигнатор (`a.b`, `a[n]`) — то нужен. при передаче указателя туда, где нужна запись/массив — тоже не нужно явно указывать, там всё очевидно и однозначно. в общем, это рудимент, правильно его в CP2 сделали почти ненужным. следующий логичный шаг — убрать вообще.

даже с указателями на процедуры получается красиво. `a: POINTER TO PROCEDURE;` всё ещё парзится однозначно, потому что такую штуку можно вызвать только как statement; если оно в expression — то очевидно, что вызов не нужен. а функции нельзя вызывать без `()` всё равно.

и кстати. на третий месяц Зоркий Глаз заметил, что в Nanojit есть такие забавные инструкции:

правда, с флоатами такой же фигни нет. а жаль.

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

в принципе, можно начинать пилить Kernel. и потихоньку менять компилер, чтобы вместо сишных типа-интринсиков звал процедуры оттедова, из кернелю. а! надо опкод для чтения EBP. можно, конечно, адрес стековой переменной взять, но EBP культурней.

и надо, кстати, научить Nanojit записывать дебаг-инфу. там даже инструкции есть для этого, но они делают ничего.

ужасно не хватает хороших статей по тому, как нано использовали. не в смысле документации, а design rationale. лазить в исходники тамарина и halfmoon мне напряжно, а некоторые интересные инструкции немного озадачивают.

кстати. борюсь с искушением сделать встроеный тип `VEC4`. в нано для него опкоды есть, чтобы дотпродукт считать. и на удивление, для vec4 есть какие-то `min` и `max`. и сравнения. хоть бери и встраивай в O/Ur Крутое Симд, лол.

а! и статик ассерты надо сделать. разрешить ассерты на константы и `SIZE()` (который у меня гарантировано вычисляется во время компиляции) вне процедур.