OberonCore

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

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

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

перешёл на более прямую работу с Nanojit. плюс двадцать вызовов — теперь ~120-124. ну, и строки допилил. а потом поигрался с константами, которые заведуют вайпом старого кода — и вышло 160.

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

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

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

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

тебе приснилось. никакого кода не генерируется. (ну или ты подурацки сфорулировал про использование кодовых процедур в Kernel.Call)

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

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

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

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

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

сам код, конечно, ужос ужасный, носящий все следы подхода: «хотели как лучше, а сделали как обычно». ну и фиг с ним. в Threat 2 перепишу, гыг.

прошёл два эпизода. хорошо.

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

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

имею по итогу двоякое впечатление об обязательном импорте глобалов: с одной стороны — немного задалбывает; а с другой — компилятор мне поймал несколько багов от копипасты так.

в Oberon/Ur, кстати, есть два новых уровня защиты полей записи: protected и protected with public r/o. `+` и `+-` (простите, для плюс-минус никак не придумывается сигил).

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

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

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

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

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

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

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

алсо, я Настоящий Программист. сказал «к следующей неделе» — и как мужик наплевал на это!

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

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

алсо, требуется помощь зала. может быть кто-то знает быстрый и дешёвый метод создать и дёргать thread-local variable? мне буквально одна-две нужно. собственно, указатель на голову списка карт указателей, хихи. эта штука вызывается в начале и конце каждой процедуры, поэтому мне надо БЫСТРА. и чтобы на шынде и пинусах работало. я в курсе, что на пинусах либц делает это через GS, но насколько помню — документированого метода сделать себе там переменную на лету нет. а про шынду только очень медленный апи знаю.

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

в общем, в шынде, похоже, можно попробовать напрямую читать из TIB. не совсем понял, как, но явно можно. вот почему под руками нет шынды, когда она нужна? ;-) в смысле — посмотреть дизасмы `TlsAlloc()` и компании.

в пинусах — хрен его знает, ещё не смотрел.

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

ещё попробовал сделать автоматический апгрейд calling convention до THISCALL/FASTCALL, если аргументы позволяют. а почему бы и да. в принципе даже работает.

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

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

хотя… у меня есть метод `var->ensureAddressable()`, который используется как раз когда нам нужен адрес для присваивания. как вариант — можно переделать его во `вторичный резолв`: он вернёт или оригинальную ноду, или новую. может так даже красившее.

видите, насколько я не хочу писать игровые менюшки?!

p.s.: кстати, O/Ur в итоге (с ручной помощью) генерит немного более лучший код для RIPEMD160. потому что кучу процедур-вращалок апгрейдит до FASTCALL, и в итоге не занимается сначала бережным засовыванием всего в стек, а потом доставанием оттуда. правда, инлайнер был бы ещё лучше. и, в принципе, я могу сделать инлайнер уже на уровне LIR-кода, не трогая всё остальное. надо подумать.

У меня такое ощущение, что halting problem и дерево вызовов - это две разные проблемы. Дерево-то вам что мешает построить, тем более в Обероне?

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

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

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

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

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

короче, «полноценные» потоки тупо неработоспособны. а «неполноценные»… да зачем? ну вот что мне мешает спавнуть новый процесс, в котором спокойно декодить и играть музыку? удобно, надёжно, работает. можно прямо там играть, можно получать оттуда pcm, неважно.


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

это, в общем, даже не должно быть дорого. на входе в процедуру, перед обратным бранчем: делаем `dec [mem]`, jz schedule`. код вызова шедулера, как полагается, добавляем в конец процедуры. разный для разных jz, конечно, но не страшно. таким образом всё становится почти бесплатно: счётчик загадит собой кэш, branch not taken, спекулятивка счастлива.

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

и кстати. fastcall помогает. не очень сильно, но помогает. во-первых, я разрешил моему внутреннему fastcall-у использовать три регистра для параметров. во-вторых, по возможности компилятор прозрачно процедуры до него апгрейдит. в итоге 200-250 мсек на «эксперименте» срезало. мелочь, но всё равно приятно. если сделать два регистра — будет 150-180, так что это действительно роялит.

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

я потихоньку конвертирую `ensureAddressable()` во вторичный резолвер. идея такая, что `resolveExpr()` проставляет типы и всё остальное, оптимайзит, всё вот это. и возвращает ноду типа `NodeVar`. которая на самом деле может быть `NodeLocVar`, `NodeArgVar`, и ещё кучка специальных. а потом `ensureAddressable()` в той же `NodeArgVar` может вернуть `NodeLocVar`, если у нас есть теневая копия.

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

и это. EMPTY RECORD как замена енумов оказалась довольно удобной штукой. включая значение `NIL`, которое "default/don't care". в игре, например:

и я забыл сделать `EMPTY ABSTRACT RECORD`, да. и `Phase`, и `PhasePostMission` должны быть абстрактными.

а и не надо ссылок, сам нашёл.

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

«органически растущая программа» вырастает только в органическое удобрение.

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

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

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

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

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

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

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