OberonCore

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

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

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

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

штука в том, что мне адово не нравится молчаливое преобразование в REAL. в большинстве моих задач REAL избыточен, и вполне достаточно FLOAT (да, я задолбался писать SHORTREAL, и сделал встроеный синоним). но молча преобразовывать во FLOAT нельзя, потому что потери. ручное же преобразование чревато. вот например:
`(inta / intb AS FLOAT)` делает совсем не то, что кажется: деление будет REAL-ом, а уже результат деления — вот он будет сконверчен во FLOAT. (а это, как понимаете, не то же самое, что деление флоатов.) чтобы сразу FLOAT было, надо как-то так: `((inta AS FLOAT) / (intb AS FLOAT))`. иначе инт без явного указания опять в REAL апргейднется, по беспотерьному правилу. и, кстати, в этом месте у меня, кажется, ошибка в компиляторе.

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

сделать два разных оператора для деления 32/64 бит?
а если захочется точности по-больше (float80, float128...) - можно ещё палок накидать %)
(только у меня есть подозрение что две пьяные палки уже зарезервированы под однострочные комменты)

подозрение верное. и тоже не нравится, тоже хак. кросивое что-то хочу!

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

куда уж красивее: просто, однозначно и кратко. красивее только выпилить 32 и/или 64 битные реалы вообще (того чего нет - не может испортить вид!).

не, мне вот непонятно, например. потому что два слэша я как раз читаю как «делай FLOAT». по такой логике: «если REAL ещё раз поделить — получится FLOAT». а поскольку у Oberon/Ur есть (и будет) ровно один пользователь — мнение этого пользователя решающее. ;-)

а выпиливать нельзя, потому что REAL — это замена LONGINT, а FLOAT — потому что для игорей обычно хватает, и оно в два раза меньше.

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

алсо, имею добавить к другой теме: поняш прав, пост-крышка (`a^`) не нужна. тащемта, в Oberon/Ur её нет, например. единственное исключение — `SIZE(type^)`. и то только потому, что O/Ur на самом деле компонентный паскаль, поэтому там можно объявлять `POINTER TO RECORD` без посредников. что технически создаёт как раз скрытый тип `type^`, гыг.

во всех остальных случаях разыменование автоматическое. присваивание записей и массивов через `:=` запрещено, надо использовать `COPY()`. которое опять таки делает автоматическое разыменование.

и насчёт `SIZE(type^)` — мне не нравится это решение. возможно, более лучшим овощем будет тоже делать авторазыменование, для консистентности. а если надо размер указателя — то `@type`. или вообще ввести `SIZEPTR()`. это лучше в том числе и потому, что пост-крышка — адский хак в парзере, нужный только для вот этого одного случая (потому что парзер заточен на разбор `self.method^`).

на самом деле сейчас сделано так: `SIZE()` для `POINTER TO` обязательно требует сигила: или префиксного `@`, или постфиксного `^`. почему префиксное `@` работает как «не разыменовывать» — знает лишь мудрец мохнатый.

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

специфика в том, что кресты используют pool allocator для скорости, поэтому `delete` делает ничего. к тому же нам нужно иметь в памяти объекты TypeDef, и некоторые def-ноды, чтобы работала динамическая загрузка модулей (и Meta, которая для простоты тоже туда же подвязана). сейчас я сделал довольно криво: типы всегда в перманентном пуле, а определения клонируются после кодогенерации. плюс строки-имена и прочие временные строки в основном в постоянном пуле — мне лениво по всем исходникам бегать и правильные пулы прописывать. и некоторые клонируются по нескольку раз.

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

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

по мотивам публикаций.

совершенно не понимаю стремления людей использовать Oberon-07 вне «железной» Оберон-системы. такое впечатление, что люди самый главный завет Вирта считают самым неважным: «оберон не догма!» 07 был сделан с вполне определённой целью, и отлично туда подходит. а не туда — не отлично. а то и вовсе не подходит. как только мы вытаскиваем оберон из родной среды, и у нас появляется необходимость общаться с библиотеками на других языках — удобство 07 сразу пропадает. в O/Ur тоже не было байтов и шортов, например… а теперь есть. потому что внешнему миру надо. в принципе-то им место в SYSTEM, но… есть причины.

в общем, я совершенно не вижу смысла делать трансляторы Oberon-07: там, где надо — оно уже есть; а вне этого оно не надо. какой-либо критической массы кода, которая бы оправдала такое — тоже не имеется. а решение совместить в `CASE` две совершенно различные конструкции, и ограничение на `RETURN` — довольно спорные вещи с моей точки зрения. ну, Вирту было так удобней. я же в этом удобства не вижу.

потому что 07 — это не «очередное улучшение оберона», а «один из диалектов оберона». не ultimate replacement. так же, как O/Ur — это диалект компонентного паскаля, но никак не замена оного.

а раздумья по тому, что бы ещё выкинуть из оберона… это сферические философствования в вакууме. minimalistic Oberon и practical Oberon — вещи разные; первая от второй отличается тем, что никто добровольно на первой писать не станет. лично я вижу оберон прежде всего как язык для практического применения. и применяю вот — сейчас в основном в виде O/Ur. не потому что BBCB плохой — а просто для разных задач разные инструменты.

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

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

пора очередной релиз делать, думаю.

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

а если финализатору не хватит? а что делать если финализатор сфейлится по другой причине? коллектор не взорвётся от трапа?

так-то там TRY стоит, просто трапы поймает. я вообще TRY именно для финализаторов делал. а если стека не хватит — будет сегфолт, там guard page для этого. тогда рыдать, менять в Kernel.GC флажок с TRUE на FALSE, перезапускать.

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

и кстати о байтах: в O/Ur как раз можно `byte := int;`. потому что кто-то задолбался постоянно кастовать. компилятор даже делает вид что умный, и понимает, что простейшие MOD/SHR проверять на переполнение не надо. хотя как я уже тут писал — проверка стоит ничего. (elven commas, bitches!)

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

кстати, `ORD(bool)` и `BITS(bool)` тоже разрешено. булы превращаются или в `0`, или в `-1`. да, я считаю, что `-1` намного логичней и удобней `1`. внутри компилятора и в памяти, правда, булы всё ещё единички. а не надо предполагать, что у них какие-то определённые числовые значения, пока не кастанул, не надо!

p.s.: и unrelated: появился файл unspecs.txt. в нём описаны примерно три с половиной новые фичи O/Ur.

алсо, таки очень рекомендую ввести в язык две дополнительных видимости: «protected» (as `+`), и «protected, public r/o» (as `+-`). очень удобно для избегания лишних геттеров и сеттеров. «protected» работает точно так, как написано на упаковке; `+-` выглядит уродливо, но из вида сразу очевидно, что он комбинирует свойства `+` и `-`.

вообще, наличие read-only полей в записях — мощнейшая обероновская идея: реально уменьшает количество дурацкого boilerplate. кто-то, конечно, может возразить, что явные геттеры лучше: а вдруг, де, в будущем нам захочется заменить переменную на что-то другое? и придётся вводить геттер, и весь код сломается! на что я отвечу: это не баг, это фича. если у меня там вместо поля стал геттер — значит, он очевидно медленней простого ld, и я хочу, чтобы компилятор любезно потыкал меня носом во все места, где надо внимательно почитать. в каких-нибудь крестах это, конечно, будут Боль и Страдания, потому что полтора часа рекомпиляции с портянками недешифруемых ошибок; но на то они и кресты, на то мы туда и не ходим.

p.s.: наличие «protected» позволяет нарушить защиту объекта, да: никто не мешает сделать методы для чтения/изменения защищённого поля публичными. это не баг, это опять фича. в LC мне такой финт понадобился, например (в реализации Window). собственно, сами методы не были публичными, но благодаря тому, что внутри модуля защита на идентификаторы, в этом же модуле введённые, не распространяется…

Ну я считаю неявный каст мисфичей. Если оно сидит в SYSTEM то никаких притензий.
Но в контексте оберон-07 оно есть всегда. И не такие уж и дешевые проверки на том же оберон-риск.

я тоже. но конкретно в O/Ur мне оказалось так удобней.

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

как понимаешь, эта архитектура меня совершенно не волнует. вот когда начнёт волновать и будет критично — сделаю VRP. к тому же `MOD (<=100H)` компилятором и так уже опознаётся. как и штуки типа `DIV n * n` (что не более чем маскировка младших разрядов при n как power of two). `ODD(a DIV n)` тоже может преобразоваться в test. и так далее. это я к тому, что то, что я вижу в своём реальном коде — более-менее оптимизируется.

опять Денис истину глаголет: «…правильный подход состоит не в том, чтобы подпиливать отдельные заусенцы в сделанном Виртом, а в том, чтобы делать под новые задачи - новые языки.»

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

это я не к тому, что Великий Я Снисхожу, нет. это к тому, что уже не в первый раз человек, с которым я во многих фундаментальных вещах не согласен, и который с моей точки зрения Делает Всё Неправильно — тем не менее оказывается одним из самых разумных и интересных собеседников. правда, в ещё большем числе случаев это оказываются genuine morons, и оно ужасно неудобно: перед тем как заигнорить — приходится читать и вникать; а ну как это тот один стоящий внимания?

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