OberonCore

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

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

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

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

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

ну и по ходу, в очередной раз отстрадав написанием софтины на сишечке, Зоркий Глаз понял, что с этим надо что-то делать. поскольку лёгкие пути не для нас, Зоркий Глаз решил решить проблему своим, особенным путём. весь софт поставляется в исходниках (меня устраивает, я за GPL), при запуске делается так: сишный бутстраповый компилятор CP-0 раскручивает полноценный компилятор UP, а оный компилирует из исходников софтину. никаких сохранений скомпилированого кода на диск, всё в памяти.

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

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

делать 64 бита я всё ещё не вижу смысла, так что скорее всего это будет 32 бита со слоем трансляции указателей, и особым типом «native pointer», чтобы с осью общаться. идея такая, что потом на эту штуку можно будет пересадить BlackBox (если кто сомневался).

don't hold your breath, конечно: я пока ещё не решился окончательно. потому если решусь — придётся делать же, тогда пацан подписался.

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

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

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

кстати. не вижу ни одной причины, по которой надо запрещать `IN` для non-compound types. так что разрешил. оно просто отмечает параметры как read-only (опять пригодился полезный флаг! ;-). технически бесполезно, но если кому-то захочется вдруг энфорсить стиль «аргументы всегда immutable» — то можно использовать.

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

ну и раз уже есть такой хак. `VOID:Func()` — игнорировать результат. `Proc(a, b, VOID)` — можно использовать, если `OUT` (и только `OUT`) аргумент неинтересен.

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

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

и я чота передумал писать весь компилер с нуля. конечно, AST в CP2 уродливый, и остальное тоже не фонтан, и всё это надо бы сделать с нормальным наследованием вместо тэгов (привет, Гершель, если я правильно понимаю)… но это терпит. SSA-бэкэнд отлично можно прикрутить и к CP2-фронтэнду: это не так интересно, как пилить с нуля, зато практически более целесообразно. а новый компилятор потом к бэкэнду можно будет прицепить.

план сделать бэкэнд тоже независимым: спеть по дереву простейшие 3-operand opcodes, а всё остальное (преобразование в корректную SSA-форму, оптимизации, деструкцию и register alloc/spilling/instruction selection) бэкэнд делает уже самостоятельно и герметично. по интерфейсу что-то похожее на LibJIT, наверное.

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

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

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

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

и чтобы два раза не вставать: надо портануть на Quackerjack Jet Set Willy (и Manic Miner). я его с сишечки на дишечку втащил, теперь надо с дишечки на UP втащить.

Не скажу за всё, но многое уже есть в A2/ЯОС, в компиляторе Fox/Лис. Как минимум, там есть промежуточный бекэнд, из кода которого потом генерируется машинный код для каждой платформы отдельным модулем.

да, спасибо, я в курсе. но оно во-первых, совершенно impenetrable, а во-вторых, не на компоненом паскале. и если второе решаемо, то первое — увы.

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

в компонентный паскаль я упёрся потому, что мне нужен BlackBox — в том виде, в каком он у меня уже есть. я себя в нём очень комфортно чувствую, и мне лень на что-то другое перепривыкать. также лично меня устраивает x86 only; я бы и не дёргался, но есть несколько человек, которым я хочу давать мой софт без того, чтобы заставлять их прыгать через обручи, заводя поддержку 32 бит. можно, конечно, сделать эмулятор x86, достаточный для запуска выхлопа CP2, но… если уж эмулятор — то почему бы не абстрактного риска тогда. опять же, в риск можно спеть как описано в compiler construction (и как поёт в x86 CP2), но… неинтересно это. с SSA и интересней, и потенциально можно в будущем добавлять разные оптимизации, не трогая всего остального. а потом из SSA можно и в x86 петь тоже.

в общем, tl;dr: архитектура фокса в плане фронтэнда не настолько превосходит CP2, чтобы имело смысл менять. а бэкэнд всё равно придётся выкидывать. да и вообще чуть ли ни треть фокса выкидывать, в силу полной ненужности для КП. не хочу, не воодушевляет. хочу свой велосипед, с квадратными колёсами.

Was ist "impenetrable"?

Так как вы намеренно смешиваете понятия, то в ваших рассуждениях и получается "исключение". Естественно, что потребность сборщика в особенности, позволяющей не ломать корректные программы, не имеет никакого отношения к инициализации, и естественно, сама по себе она не мешает диагностике использования неинициализированных указателей (ей мешает лишь описание языка). А не воплощена она по той же причине, что и для всего остального - проще не сделать, чем сделать.
Вы же рассуждаете в духе "сгорел сарай - гори и хата", хотя даже сарай не было смысла сжигать.

impenetrable: [adjective] incapable of being penetrated or pierced. inaccessible to knowledge, reason, or sympathy. в данном случае — большое, страшное, непонятное и лаяй.

эм… простите, а что тогда делает компилятор с указателями, если не инициализирует их в NIL?

точно так же, как инициализация остальных локалов нулями этому тоже не мешает. вообще tangential thing.

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

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

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

Очевидно, что заполнение стека нулями не имеет никакого отношения к инициализации. Потому-что инициализации это приведение программы в состоянии готовности к использованию. И в этом смысле не важно, заполнен ли стек нулями или нет, если для правильной работы программы стартовое значение переменной должно быть равным 100500;
С указателями же весьма простая историю- обычно разыменование NIL отслеживается аппаратно (хотя, само значение на разных архитектурах может быть различным).

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

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

p.s.: кстати, в CP2 это называется «инициализация». прямо вот в исходных текстах:

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

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

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