OberonCore

потому что на винде есть дх

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

надо бы добавить в редактор фичу. две даже.

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

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

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

кстати, нашёл интересную сишную библиотечку для Ed25519. она во-первых, маленькая (около 40 кб исходника), а во-вторых, для каких-то контроллеров, поэтому использует только инты в 32 бита (единственное место, где 64 бита — SHA-2). надо бы портануть, мне в некоторых местах эти подписи нужны.

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

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

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

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

собственно, никто не мешает в тот же житер запихивать и оптимизаторы: разобрать риск-код в SSA, пооптимизировать, собрать из SSA натив. итоговый натив может выйти даже быстрее, чем у теперешнего CP2. и чёткое отделение кодогена компилятора, кодогена в натив, и оптимизаторов. компилятор, кстати, значительно упростится в области кодогена. а жит для начала можно вообще сделать на LibJIT или GNU lightning.

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

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

Juice?

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

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

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

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

p.s.: в принципе, можно трактовать указатели на tagged и untagged как две разных сущности (всё равно компилятор их различает). untagged заворачивать в сложные коробочки, tagged — в простые. для 32 бит вообще можно без коробочек обойтись. а для 64 различать указатели от начала образа в памяти, и нативные. например, при помощи последнего бита, или ещё как-нибудь.

Виртовский RISK5?

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

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

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

p.s.: и вообще, правильно их называть не хоткеи, а кейбинды.

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

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

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

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

это последнее утверждение, конечно несколько экстремистское и спорное: даже наш любимый CP2 иногда умудряется реюзнуть регистр, и иногда даже между границами выражений (что, по сути, примитивная форма CSE). и я, как compiler guy, тоже постоянно хочу Такой-То Оптимизатор. (мы любим писать оптимизаторы!) но вот как пользователь компилятора я хочу предсказуемости. хочу быть увереным, что машина увидит именно то, что я написал, а не то, что по мотивам моего кода напел оптимизатор. потому что у рабиновича иногда нет ни слуха, ни голоса, и «битлз» в его исполнении не звучит.

всегда бесило, что почти во всех языках в выражении `func1() + func2()` порядок вызова неопределён. алё, ну как же он неопределён, если вот всё написано? мы читаем слева направо (ну, как минимум в случае исходника ;-), и любой нормальный хуманс сходу скажет, что сначала `func1()`, потом `func2()`, не наоборот.

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

Идея: в цикле Дейксиры ветвь (-и) с WAIT обрабатывать всегд прследней.
Первую из осташихся выбирать по RANDOM().
Если условие FALSE одну за другой проверять остальные "non WAIT " ветви.

Этот алгоритм позволит обходить закрытый (-ые) семафоры.
Так как обращения к данным охранямым семафором возможно при проверке условий (?) цикла.

Что может быть хуже неопределённого поведения? Плохо определённое поведение. Можно долго ратовать за всё хорошее против всего плохого, но поставленное в узкие рамки большинство разработчиков предпочтёт плохо определённое поведение, отказываясь от неидеальной диагностики ошибок ради воспроизводимости поведения дурного кода, как, например, в Java. Можно только порадоваться, что разработчики КП всего лишь выключили по умолчанию генерацию проверок арифметического переполнения, а не внесли в язык обязанность отсекать старшие разряды в дополнительном коде.

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

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

и да, печально, что в CP выключили проверки на переполнение целых. но фиг с ним, они и автоматическое зануление переменных тоже выключили, всё во имя более быстрого кода. я вот думаю о том, чтобы хотя бы зануление в UP вернуть обратно. да, это не лучший вариант, лучше было бы сразу трапаться при обращении к неинициализорованной переменной, но хотя бы устраняет одно UB. пока что меня останавливает только реальное проседание скорости. потому что я-то буду знать про «лишний» код, и очень сложно станет себя убедить в том, что надо не реюзать какую-то перменную, а заводить новую. в общем, сначала надо data flow analysis запилить. а по AST это неудобно.

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

но категорически не согласен, что «не радует» хуже UB. что угодно лучше UB, даже если при сложении MAX(INTEGER) и 1 в спеках написано, что придёт Оптимус Прайм и будет бить чечётку — это лучше, чем UB. хотя бы посмотрим на танцующего Оптимуса. (и он обязан прийти, раз спеки так говорят.)

Дело совсем не в том, что нужно продумывать перед тем, как делать, а в том, что после "продумывания" в большинстве случаев и получается плохо определённое поведение. Обнуление переменных вместо диагностики тому пример. Сложность же проверок и накладные расходы не позволяют прописать в описании языка обязательную диагностику, что бы вы не писали про "обязан". Вместо этого в описании пропишут обнуление, после чего адекватная диагностика оказывается невозможной, потому что правильные программы вправе рассчитывать на изначальный 0. И уже нельзя отличить случай, где установка значения была пропущена по ошибке, от случая, где установка была пропущена, потому что 0 и нужен. Вот и получается воспроизводимость работы плохого кода вместо не идеальной, но диагностики. Если же это неопределённое поведение, то практически все случаи обращения до установки - это ошибка и потому диагностика возможна. И чем продвинутей, тем больше в статике, вплоть до доказательства корректности, но точная граница в конкретном случае, опять-таки, не определена. Все эти потенциальные возможности с гарантией выбрасываются на помойку, если до языка дорвутся разработчики, которые всё "правильно" "продумают".

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

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

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

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

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

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

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

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

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

одна из причин, по которым я перевёл LONGINT с FPU на обычные целочисленные инструкции, кстати — устранение очередного исключения: «INTEGER на переполнение не проверяется, а LONGINT — иногда таки да». (и там надо допилить включение проверок, когда стоит флажок компилятора, но всё руки не доходят.)

p.s.: кстати, записи, созданые по NEW тоже зануляются полностью. более того: есть довольно много кода, который на это полагается. и никто не помер. опять же: почему полностью, почему не только указатели? снова исключение. опять надо про него помнить. «потому что так быстрее и удобней для авторов компилятора и рантайма» слабый, с моей точки зрения, аргумент.

p.p.s.: CP2, кстати, по достижении некоторого порога заменяет ручное зануление указателей на очистку через STOSD. по-моему, просто чистит весь блок от первого указателя до последнего, включая другие локалы. опять исключение и UB.

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

* на организационном уровне установить, что каждая автоматически инициализированная нулём переменная требует комментария с пояснением. За комментарий несёт ответственность тот, кто его последний менял, а само наличие комментария можно проверять инструментально (при этом не нужен анализ потоков исполнения, а достаточно просто синтаксического разбора).
* завести особое "не инициализированное значение", с теми же свойствами, как в Эль-76. Правда, это несовместимо с понятиями о типах данных, бытующими в современных процессорах, и получится резко дороже

В том виде как есть, получилась лажа, но при определённом форматировании мозгов, конечно, можно и с этим жить. В ЯОС я прописал обнуление в описание языка:

https://tvoygit.ru/budden/jaos/src/branch/главная/док/язык-и-библиотека/описание-языка.md#8-объявления-переменных (там, кстати, устарело, ARM теперь тоже поддерживается). И сделал я это не первый, а посмотрев на тех, кто разработал golang. В то время как golang победно шагает по планете, Оберон продолжает влачить жалкое существование. Это, конечно, не гарантирует качество решений в голанге, но слегка намекает.

Уж не говоря о том, что ЕМНИП в КП нельзя инициализировать переменную при объявлении, а значит, ненулевая переменная - это гонка. Нужно гарантировать отсутствие сборки мусора между моментом объявления переменной и её обнулением. Но тут я, впрочем, могу и ошибаться.