OberonCore

(((-8Ж второйна...

алсо, да: там есть сырцы всего. кто не угадает пароль к архиву с дополнительными сырцами максимум с четырёх раз… ну, зачем вам эти сырцы тогда? ;-)

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

и конечно, в Threat всякие мелкие починки. скорость анимации, например. кстати, там есть внутриигровая консоль. а в ней автодополнение.

ёлки. очень захотелось переименовать в Oberon/LSD: отличное название. жаль, что сразу не догадался. но всё-таки это часть Ur-семейства — не будем обижать семью. к семье нужно относиться с уважением.

надо бы, кстати, забрать из LC бинды к GnuTLS, и сделать веб-сервер на сопрограммах. относительно практическая задача, которая вдобавок позволит обкатать реализацию сопрограмм. а то я её сделал, конечно, но в серьёзном бою ещё не испытывал.

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

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

спасибо. я виноват, повёлся.

p.s.: вынесу оттуда полезное: СуперСложныйПароль к архиву с исходниками, который надо угадать — «1234». мне это кажется смешной шуткой. кому нет — простите.

привинтил экспериментальный мультитаскер. если тупо всунуть в «experiment» (это такая числодробилка, долгая и упорная) переключение задач, то в общем — замедление примерно на 500 мсек из ~11 секунд. конечно, свитчилка делает ничего; если туда добавлять код — будет медленней. но в целом — не так уж плохо, чо.

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

это, конечно, «ненастоящий» мультитаскер — ну и что? зато дёшево, сердито и лаяй.

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

кстати, вставить такое же в CP2 тоже несложно. даже, пожалуй, проще, чем в O/Ur: в CP2 компилятор не делает глобальное выделение регистров. мне пришлось вставлять весь код инлайном вместо `dec [cnt]; jz do_the_real_work`, в силу специфики кодогенератора; а в CP2 можно как раз жампы, и будет ещё пошустрее.

по ходу портанул live checker (на самом деле def/use checker) из halfmoon. чекер меня сразу же обозвал нехорошими словами. ну, в одном случае он явно неправ, а вот в остальных… вопрос.

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

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

с табличкой всё просто. с деревом — сначала генерируется весь код выбора, и только потом тела веток. а вот с линейным перебором всё плохо: тела веток генерируются сразу после проверок. и это приводит к тому, чего Nanojit очень не любит: к бранчам назад. потому что внутри для штук типа `| 1, 3, 5:` генерируются полноценные ветки. просто у веток для `3` и `5` вместо тела стоит указатель на ветку `1`. это без проблем разрешимо, когда мы сначала генерируем все проверки (или строим табличку), но вот когда линейно идём — нет. поэтому получается проверка уловия, и потом может случиться переход на ветку, тело которой сгенерировано раньше.

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

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

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

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

итог: любите чекеры! они стараются помочь. а если и ошибаются — то всё равно стараются помочь. помоги своему чекеру — и чекер поможет тебе. в данном случае он таки убедил меня переписать некрасивую кашу.

ах, да. каша появилась вследствие «органического роста». сначала CASE был очень простой и всегда линейный… а потом я обнаружил, что забыл реализовать штуки типа `| 1, 3, 5: …`. появились ветки-редиректы, и красивый линейный генератор перестал быть линейным. тут-то его надо было переписать, но… но проще ж добавить хак и убежать. он, кстати, ещё и ужасно неэффективен в таком виде: Nanojit не может в полной мере использовать регистры (они грязные после тел).

а ещё чекер нашёл забавную ошибку: при деоптимизации `INC/DEC` некоторые инструкции не попадали в список. ссылки на них были, Nanojit (по счастливой случайности) нормально работал, но…

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

на самом деле красивого варианта решения я не придумал; в этом конкретном случае я использовал хак. поскольку я точно знаю, что `maddi` и `msubi` проходят все оптимизаторы «насквозь» (то есть, ничего важного там не меняют, и нигде не запоминаются), а также не имеют результата, то можно просто временно откусить хвост списка: пусть Nanojit думает, что добавляет инструкции в конец, а не в середину. когда всё нагенерено — подцепить хвост списка обратно.

такой финт невозможен в оригинальном Nanojit, но я добавил явные поля `prev` и `next`, поэтому у меня стало возможно.

кстати. надо бы добавить `WSTRING` для UTF-16. а почему бы и да. и `WCHAR`. технически, компилятору вообще без разницы что в строке, а `WCHAR` уже есть в виде `SHORTUINT`.

заодно починить и LC, позволив на пинусах работать с именами файлов не в utf-8. как? а так же, как чикен схема, например, или питон: использовать «low surrogate» для хранения «плохих» байтов. собственно, просто расширить кодек utf-8 для поддержки этой штуки. рисоваться оно, конечно, будет квадратиками, но работать с такими файлами станет вполне возможно. а полные суррогаты можно использовать для импорта/экспорта текста в клипбоарде. таким образом покроем весь юникод, и не надо растягивать CHAR в четыре байта. ну да: обработка потребует усилий, но хотя бы не будет потерь при преобразованиях.

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

таки проапгрейдил CFG builder и def/use checker. заодно перенёс их в главную библитеку Nanojit (потому что им место именно там). и ускорил чуть-чуть. чтобы понятны были тайминги:

билд Threat (~400 кб кода игры, около 100 кб кода поддержки):
без анализатора: 159 msecs.
со старым анализатором: 189 msecs.
с ускореным анализатором: 169 msecs.

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

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

как минимум первое, что можно будет сделать на этой основе — избавиться от ручной пометки живых инструкций: она нужна для Nanojit при переходах «вверх» (на начало циклов). анализатор сейчас занимается проверкой на предмет забытых `LIR_live` — но никто же не мешает вместо ругани в консоль просто эти штуки добавлять в код. оригинальный Nanojit не умел произвольно модифицировать список инструкций, а Nanojit из Oberon/Ur умеет — так что даёшь автоматизацию! собственно, это ничто иное как пост-фактум расстановка фита-инструкций (kind of). ну, и ещё много-много всего можно делать легко и свободно, имея нормальную информацию о доминаторах.

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

теперь после имени модуля в IMPORT, после VAR, CONST, TYPE, PROCEDURE — можно в квадратных скобках указывать не только атрибуты всякие, но и селектор условной компиляции. селектор — простое логическое выражение, типа: `[linux & bits32]`. а также там можно использовать константы, которые на момент селектора известны, и являются простыми константами-литералами. то есть, штуки типа `CONST DEBUG=TRUE;` и потом `[DEBUG]`.

и ещё появился static if: `IF [selector] THEN … END IF`. простой `IF DEBUG THEN` тоже можно, при `DEBUG=FALSE` он кода не сгенерит. однако же код хоть и будет потом выкинут, но всё равно должен быть корректным и компилироваться. а если у нас объявлена переменная как `VAR [DEBUG] …`, например — то упс. поэтому static if: он просто слепо всё скипает, если селектор ложь.

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

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

эх. не хотелось, а пришлось. как ни крути — а иногда от внешних библиотек надо получать `int64_t`. передавать-то можно было, а вот получать — фигушки. для начала пришлось доработать Nanojit. а потом… ну, раз уж мы так умеем — то добавил таки `LONGINT`. внутри оно просто запись с двумя полями, и компилятор знает как это распаковать для передачи, и упаковать при получении. так что он просто переписывает операции с лонгинтами в вызовы интринсиков. ну да, медленно. ну и фиг с ним.

а вот надо код читать!

оказывается, Nanojit отлично понимает, зачем нужна инструкция типа `eqd(ins, ins)` (fp-сравнение с самим собой), и генерирует совершенно верные машинные команды. а я руками проверял, побитово…

эх… гори и хата! зря, что ли, Nanojit умеет в SIMD на четырёхэлементных векторах? я поразмыслил — и решил не учить компилятор плохому (автовекторизации), а вместо этого просто добавил тип `VEC4`. он такая странная не-совсем-запись: поддерживает доступ к элементам через точку и swizzling (тоже через точку). и математика с ним работает.

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

документация лжёт! не верьте документации! по крайней мере на современные CPU.

итогом возни с SSE стало ускорение Experiment на 300 мсек, но… но не так, как казалось. чтобы два раза не вставать, я сделал зануление стека и `OUT`, а также `COPY()` через `movups`. то бишь, по 16 байтов за раз. вот это и дало ускорение. игры же с векторизацией вычислений оказались где-то в пределах статистической погрешности. хотя интел обещала, что на новых камнях (и даже на моём) `rep stosb/movsb` внутри очень оптимизируется, ну прямо-прямо как SSE store, и даже лучше. политрук лжёт!

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

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

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


p.s.: в следующем релизе даже появится волшебный файл "whatsnew.txt". бесполезный, но может кому-то интересный.

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

раз уж теперь есть автоматический построитель CFG — то сделал и расстановку live hints автоматическую. во-первых, это упрощает компилятор. а во-вторых, открывает путь ко всяким переписываниями кода — которые раньше были проблематичны из-за риска потерять хинты. а если потерять хинты — Nanojit запутается. ну, хинты здесь — это некий аналог фита-нод, только тоже «задомнаперёдный».

то есть, теперь, в принципе, можно будет — когда появится желание и отступит лень — делать обычные для SSA оптимизации. всякие там dead store elimination, loop code motion, и прочие страшные слова. и value range propagation, чтобы убирать лишние проверки диапазонов и индексов.

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

p.s.: кстати, в Nanojit был рудиментарный код для VRP. но недоделаный, и отключеный. я, в принципе, его так и оставил отключеным с целью когда-то использовать. но в итоге его проще выкинуть и сделать заново.

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

Не стоит. Всё, что поломано, желательно починить. C "тормозами", скорее всего, придётся мириться.

а зачем мне FPU-то? это адовый хак, нано толком не умеет детектить переполнение стека и делать спилы… и я совершенно точно никогда это чинить не буду ввиду полной ненужности. бедный нано даже на a+b иногда с ассертами вылетает. какой смысл делать вид, что где-то у кого-то остались стоящие внимания камни без SSE?