OberonCore

на всякий чуть разверну: FPU совершенно, полностью не нужен. есть ровно одно место, где надо забрать значение со стека FPU: x86 cdecl ABI (и другие x86 ABI, да). вся плавающая точка делается на SSE. компилятор, собственно, просто откажется запускаться, если SSE не увидит — потому что SSE-инструкции много где, в том числе и для нового типа `VEC4`. никакого смысла писать обвязки для не-SSE камней нет. соответственно, вся работа с FPU — это мёртвый код, который не будет активирован никогда вообще. из плавающих типов в O/Ur только `REAL` и `SHORTREAL` (double и float соответственно).

да, в SSE нет синусов, косинусов и прочих гитик. но в Nanojit и инструкций таких нет, это всё равно интринсики, так что даже это не теряется. есть инструкции round/trunc/ceil/floor, но я их добавил сам, и они требуют SSE4.2 (или 4.1, не помню). а при отсутствии такого SSE опять будут интринсики (пришлось, потому что мой валгринд умеет только в SSE2).

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

p.s.: «быстрее» — это примерно 500 мсек на Эксперименте. в итоге Эксперимент сейчас исполняется за 9.28 секунд (было 10.2 или около того). в общем, код определённо быстрее, чем был. с CP2 там 12 секунд, кажется.

как-то пропустил очевидное: CSE довольно часто в состоянии опредлить, что проверки на `NIL` или на корректность индекса массива одни и те же (типа `r.field1 := 1; r.field2 := 2;` — ну, вы поняли), и заменяет одинаковые условия в переходах на самое первое вычисленое. а поэтому в принципе нет никакого смысла сохранять и все такие переходы кроме первого: или первый же триггернутлся, или ни один не триггернулся.

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

забавно: в коде Threat убралось чуть больше тысячи таких переходов; и почти все они были переходами на трапы, так что и больше тысячи вызовов трапов — около 10 кб сгенерёного кода. пусть мелочь, но всё равно приятная.

более сложные штуки (типа символического анализатора и VRP), чтобы убирать проверки индексов в циклах, например, стоят намного дороже (как в плане времени, так и в плане сложности кода). пока не вижу смысла их делать.


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

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

сделал правильный трэйсер всех веток в dead store elimination. в итоге убирает чуть больше мёртвецов (в том числе в циклах). мертвецы образуются не только от явного лишнего кода, но и в результате оптимизаций — компилятор довольно часто может заменить в `a := expr; b := a + b; c := a + d; …` и так далее чтение из `a` на использование результата `expr` (до сохранения в `a`). ну, CSE такое. в итоге `a` может получиться и вовсе ненужной — вот тут придёт dead store eliminator и почистит. а потом Nanojit увидит, что выделение стека для `a` не нужно — и выделять не станет. мелочь, конечно, но пуркуа бы и да.

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

испытываю страшнейшее желание трансформировать LIR в нормальное SSA. но без фит, а в CPS. я как-то всегда фиты делал, а с CPS-видом не игрался. это желание, естественно, совершенно непродуктивное, потому что всё то же самое можно и в LIR-форме делать. впилить, что ли, вместо этого в Nanojit простенькое TCO? ну, чтобы хоть как-то унять зуд бесполезного.

кстати, по дороге отключил некоторые довольно тяжёлые валидации внутреннего состояния Nanojit. собственно, все кроме одной проверяют на предмет багов в кодогене, аллокаторе регистров и менеджере стековых слотов, и полезны только при переработке оных. оставил только чекер неосвобождённых слотов — он реально ловит баги в сгенерённом LIR (и единственный, который у меня хоть когда-то триггерился). компиляция Threat ускорилась примерно на 15 мсек: 160 → 146. а это значит что? а это значит, что у меня есть 15 мсек на бесполезные оптимизации! потому что халявные, с неба свалились.

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

p.s.: Threat с -O0 (без оптимизаций вообще) компилируется примерно 128 мсек.

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

такой идеальный расклад, конечно, удобен для теоретических исследований, но… на практике у нас всегда есть указатели — как минимум на объекты в хипе. и даже в обероне бывают и другие — хотя бы в виде `SYSTEM.ADR()` с последующими `PUT` и `GET`. которые желательно компилировать по месту, а не вызовами интринсиков.

так вот. есть интересная идея на предмет того, что делать с адресами в SSA: надо просто сделать `store` не void-ом, а возвращать оттуда новый указатель. это решение не идеально, конечно, но значительно упрощает анализ data flow.

каждый адрес используется в store ровно один раз. таким образом мы отслеживаем мутации памяти, и можем легко убирать лишние load и store обычными алгоритмами. очевидно, например, что `load p0` можно заменить на `v2`, если `p0` строго доминирует над соответствующим `load`. и `store`, результат которого нигде не используется, можно смело выкинуть (проверив, что это не для глобала или хипа).

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

p.s.: вопрос алиасинга я умышленно упустил: это отдельная тема.

я вот думаю: не заменить ли `EXTENSIBLE` на `SEALED` для записей? (ну да, O/Ur скорее форк Component Pascal, а не Oberon.)

в принципе — какой смысл запрещать расширение записей по умолчанию? довольно часто бывает удобно добавить в запись пару полей по личным нуждам — так что в итоге я почти во всех публичных записях всё равно втыкаю `EXTENSIBLE`. но иногда забываю, матерюсь, иду и втыкаю постфактум. O/Ur всё равно запрещает передачу записей по значению и возврат записей как результатов функции. при передаче записи по ссылке всё равно всегда передаётся скрытый аргумент — typeid, так что никакой экономии кода даже. не, ну можно `typeid` не передавать для нерасширяемых, если они ни от чего не унаследованы, но смысл? экономия мизерная, только лишние проверки в компиляторе.

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

кстати, немного поэкспериментировал с «ручной мультизадачностью»: в принципе, оно даже похоже на юзабельное. добавил в Experiment, сделал простейший алгоритм адаптации длины таймслайса — получил приблизительно 500 микросекунд между переключениями; общее замедление — около 500 миллисекунд (9 → 9.5). шедулер просто смотрит на количество подряд идущих слишком коротких или слишком длинных слайсов, и соответственно рихтует счётчик до переключений.

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

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

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

на удивление, идут вот тесты (тупой фуззер), результаты сишного и обероновского кода вполне совпадают.

ну, будем честными: там нет обероновского кода, там сишный код, который пытается прикидываться обероном. но какая разница? компилируется же, и работает! ;-)

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

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

портануть ради интереса твитнакл, что ли? хотя технически — надо только салсу, 25519 key derivation же вроде как есть уже.

заодно и cryptoprng докинул. который сидируется из `getrandom (2)` или `RtlGenRandom()`, а потом крутит ISAAC+.

кстати, Денис про опасный `WITH` напомнил. у меня есть мнение, что проблема с ним решается. как я решаю её в O/Ur, например:

1. `WITH` запрещён для всего, что не локальная переменная и не аргумент. а не надо, не надо.
2. передача указателей как `VAR` с расширением типов запрещена (присваивание считается частным случаем такой передачи).
3. `NEW()` с расширеным типом внутри `WITH` запрещено.

`WITH` в O/Ur сделано через прокси-ноду в AST, тип оригинальной переменной никогда не перекрашивается.

таким образом:

не, не выйдет, компилятор обругает.


тоже не выйдет, тоже обругает.

а вот такое можно:

это безопасный финт: базовый тип всегда меньше.

и соображение из другой оперы: надо сделать бэкэнд, который выплёвывает сишечку. может даже не из оберона, а из Nanojit LIR. чтобы в конце концов перейти на селф-хостинг, не теряя при этом фичи «я принципиально не пишу скомпиленый код на диск, исходники наше всё!»

по ходу, экспериментально портировал `Comm` из LC. без TLS пока: мне не нравится там дизайн, это было такое ad-hoc решение. сокетные потоки в LC получше стандартных, если что: они на линуксах умеют в асинхронное разрешение имен, например.

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

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

а в O/Ur и вовсе других вариантов нет, потому что там нет главного цикла. так что пришлось сделать интерфейс для ожидания событий.

У тебя WITH не просто опасный, а совсем кривой.
В переменной типа Rec1 при нормальных условиях никогда не может быть указателя Rec0 и его альтренативных расширений, не говоря уже о том что в Rec1 есть всё тоже что и у Rec0.
Так что каст в Rec0 не имеет смысла как и дальнейшие костыли по тексту.

В репорте КП такое поведение не обозначено явно, но в блэкбоксе твои тесты не соберутся т.к. тип Rec0 не является расширением типа Rec1.

А вот так?

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

у меня он такой для некоторых странных финтов, которые никому использовать не надо, но иногда… в общем, там есть возможность (о которой я никому не скажу) заэнфорсить не только тип, но и его VMT.

но я как-то забыл, что не все такие извращенцы, да, и что только у меня разрешается кроме уточнения ещё и расширение (widening) типа обратно. это мисфича, конечно.

p.s.: а так-то ты прав, конечно. мисфича осталась в наследство от тёмного прошлого зарождения жизни, и вместо чтобы пытаться сделать с ней hardening — её надо просто аннигилировать.

кстати, надо бы — по уму — Nanojit переименовать. а то вот некоторые считают, что это «почти интерпретатор», не понимая, что от кодогена, например, CP2, нано отличается только тем, что иногда чуть лучше регистры распределяет. пужаит, панимаишь, народ страшное буквие «jit». бедный gcc: его с gccjit тоже из высшей лиги надо вычеркнуть, наверное.

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

правда, с очередной стороны — я там многие вещи переделал довольно значительно. это всё ещё Nanojit, без сомнения, и любой, увидев код, «узнает в лицо». но другой.

и с финальной стороны: а я имя красивое придумать не могу!

и раз уж…

Oberon/Ur, release 00d: misfeatures and misconceptions.

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

я знаю, что никто в здравом уме этим пользоваться не будет (я не в здравом, не считается), однако считаю долгом предупредить: объявлен месяц оптимизаций, количество багов удваивается!

на самом деле это никакой не релиз, а обычный WIP, но… мой проект: что хочу — то релизом и называю!

не пытайтесь пробовать Comm на винде (даже если разберётесь, как): соответствующего Impl нет. я вообще винду поддерживаю исключительно чтобы Threat там запускался, а ему Comm не нужно.

Curve25519 в поставку входит, если что. ;-)