OberonCore

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

код он, кстати, тоже пишет ужасный. не уровня «невыносимо отвратительно», но уровня «вымойте это с мылом!»

Да, меня тоже это немного задело. Ведь все знают, что java позаимствовала идеи из Oberon. А си - ну, скажу не самый приятный язык лично для меня. И писать кода больше, чем команда из 7 человек. Ещё не смотрел, но вот теперь догадываюсь что там . . . Спасибо, что предупредили. У меня есть склонность идеализировать, иногда в упор не замечая недостатков. И в другую сторону, только наоборот ))).

Вопрос. Почему сборку мусора не сделать в виде внешнего подключаемого модуля. А не как обязательный стандарт языка. Например, как это прописано для ввода/вывода. Не надо придерживаться строгих “дубовых правил”. Каждый сможет выбрать из нескольких бэкендов, подходящий к конкретной задаче. В таком случае для GC можно реализовать несколько вариантов с различными стратегиями. Для трапов ведь получается вынести во внешний подключаемый модуль. Почему не сделать также для GC, разгрузив модуль Kernel. Или это из серии глупых вопросов ???.

И ещё тема автоматически не появляется в списке ‘Активных тем’. Случайность или так и задумано ???.

Kernel — совершенно обычный модуль, который никто не запрещает менять. так что переписать реализации GC, memory allocator и прочее — совершенно не запрещено. ;-) ну, кроме того факта, что компилятор должен уметь в то, что нужно GC (write barriers, например, если у нас GC инкрементальный).

это не отменяет того, что Kernel должен быть «предзагружен», потому что он нужен системе. чтобы что-то загрузить — надо иметь уже загруженый GC и реализацию файлового I/O. в BBCB это линкуется в бинарь; в O/Ur используется хак (загрузка исходников модулей и последующая компиляция делаются на стороне крестов).

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

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

и опять повторюсь: реализация GC жёстко связана с реализацией компилятора. компилятор должен знать про внутренние процедуры ядра, вызов которых он вставляет вместо тех же NEW, ASSERT, HALT и прочего, например. ядро должно знать формат модулей, как там расположена информация о типах, секции, фиксапы. это не то, что можно легко отвязать друг от друга.

а вот запрос памяти у ОС в том же BBCB сделан как раз как интерфейс. в O/Ur я вообще поленился возиться со страницами, и выделяю чанки через `malloc()`.

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

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

p.s.: в той же Pow!, например, есть возможность оторвать GC и вручную любиться с освобождением памяти. по какой-то причине они решили интегрированый текстовый редактор сделать именно так. я нифига не понял, зачем.

malloc - это нормально. Особенно учитывая экспериментальный характер проекта. Не факт, что быстро слепленный страничный менеджер окажется сильно лучше стандартного, предоставляемого Linux. У себя вообще не заморачивался. Взял malloc посчитав, что лучше мне все равно не сделать. Исключение только для jit модулей. Но там по другому никак. Требуется атрибут execute. У Вас скорее также ???.

Условная компиляция. Компиляция на лету из исходников. Include. Сильно. Может когда-нибудь и дорасту до таких высот. А сейчас наоборот стараюсь запихнуть в один файл как можно больше, чтобы сократить количество этих файлов. Но это наверное связано с особенностями восприятия (охвата) информации. У каждого своя !!!

В остальном. Да, похоже вопрос из разряда не умных. Вдруг показалось, что можно сделать фиксированный простой Kernel с единственным dispose. А уже к нему динамически подключить GC. Причем и dispose и GC могут работать совместно в параллели. Ладно, в мусорку, так мусорку (((.

`malloc()` у меня используется точно так же, как и `mmap()` — чтобы взять большой чанк. менеджер памяти дальше свой. просто мне лень было для шынды отдельно делать `VirtualAlloc()`, вот и всё. ;-)

житер, конечно, дёргает страницы системными вызовами, тут иначе никак.

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

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

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

а DISPOSE быть не должно вообще: это нарушает базовую гарантию безопасности. тогда уже проще спокойно брать сишечку и не заморачиваться. впрочем, у меня в BBCB есть хак: statistics AA tree, память под ноды я там выделяю как раз в страницах, полученых от операционки, в которые GC не смотрит. чисто для скорости: нод много, живут они долго, внутри них ничего интересного нет, а GC постоянно их сканирует. может быть в новом компиляторе сподоблюсь на incremental generational GC, чтобы не приходилось такими глупостями заниматься больше. это и для SoN пригодится потом: SoN плодит ноды как от ураганной диареи, примерно треть из них почти сразу и выкидывает.