OberonCore

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

с учётом того, что у вас, похоже, IS/AS неправильные — то и WITH, конечно, бесполезен. ;-)

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

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

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

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

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

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

никак не успеваю. но это не мешает стараться. ;-)

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

Сто лет в BB, и Сто % был уверен, что IS не распространяется на родителей. Проверил. Реальность оказалась другой - распространяется (((. Спасибо ))).

Компилятор однопроходный, а взаимно рекурсивные процедуры пишу так:

proc A;
proc B; begin A; end B;
begin B; end A;

Матом, а если других нет ))). С wayland - вероятно и Микрософт внес свою лепту. Они вроде главные спонсоры (((.

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

>>>> Драконью Книгу . . . удовольствия перед сном почитать.

Почитать, конечно придется. Но вот про удовольствие. Это шутка такая ???.

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

Ага серьезная. Да это наверное самое сложное, что есть в мире программирования. Потоки, графика, интерфейс, сюжет. Есть область, которую можно пропустить ???

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

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

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

хотя больше пошутил, конечно.

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

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

пререквизиты: необходимо понимать, что такое SSA, CFG, DFA, def-use chains и прочие маты из compiler 101. такие простые вещи Клифф особо не разжёвывает. всё это, в принципе, можно найти в книге про SSA от Inria, ссылку на которую я давал выше.

Клифф Клик, помимо прочего, автор C2: оптимизирующего JIT-компилятора для java. в котором как раз в полный рост использует SoN.

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

Спасибо, шикарный подарок ))). Интересный проект https://aglang.org, пишет свой язык, работал в Гугле, предлагал руководству в качестве оф.языка.

Раньше Вас, точно нет. В приоритетах - поддержка дисплеев высокого разрешения (retina), добавить android, устранение ошибок и недоделок. И новый - чтение на ночь, рекомендованной Вами литературы. И только потом, если звезды сложатся . . . )))

The initial build takes ≈60Gb of storage, it requires 16+Gb RAM, and depending on device configuration can take up to 6 Hours.
«прелестно, прелестно!» (ц)
бейте это лопатой пока не залезет обратно туда, откуда вылезло.

Не могу скомпилировать такую программу (адаптацию одного из моих ГПСЧ к Вашей среде). В логе пишет "x8k.SYM" не создан!" Также при отладке я часто получал сообщение что-то вроде "идентификатор не определен" без указания этого самого идентификатора, и такую ошибку может быть сложно искать. Также, похоже, компилятор в сообщениях об ошибках нумерует строки с 0, а в редакторах они нумеруются с 1.



Ещё по исходникам из дистрибутива: там встречаются идентификаторы на транслите вроде DrawOval. Также в исходниках используется кодировка 1251 вместо более привычной UTF-8. Впрочем, в исходниках вообще обычно не используют символы, отличные от ASCII и естественные языки, отличные от английского (т.к. программист не обязан знать русский язык, но обязан знать английский).

Не ходите в Aфрику гулять . . . Не берите, то что там лежит . . . А если по существу, то часть пробелов в тексте, не пробелы, а какие-то скрытые символы, воспринимаемые компилятором как индефикаторы. Позже посмотрю в hex редакторе что это. А пока просто почистил. И второе, именование имени модуля - отсутствовал префикс имени папки назначения. Тоже поправил. Исправленный mod файл и краткая инструкция в архиве ))).

Спасибо. Похоже, я нашёл ошибку компилятора. Вот короткая программа:



Она у меня выдаёт 16 вместо 4 (ROR = Rotate Right). В описании Оберон-07 от Вирта ROR описана как "x rotated right by n bits". О формате исходника:
1) В качестве разделителя строк используется символ с кодом 13, что достаточно экзотично (т.е. это не CRLF из Windows и не LF из Unix).
2) После вставки коммандера по CTRL-R файл с исходниками перестаёт быть корректным файлом в ASCII и даже в UTF-8. Т.е. любой исходник с коммандером получается невозможно представить в ASCII, что странно.

Спасибо. Да действительно в спецификации Oberon07 так. А вот в спецификации Oberon-2, такой команды нет. А операции сдвига представлены универсальными ASH, LSH в которых сдвиг влево - неотрицательное целое, сдвиг вправо - отрицательное целое. Решил не ломать общую концепцию и сделал также: ROR(8, -1) = 4, а ROR(8, 1) = 16. Вот у Вас такой результат и получился.

ASCII, UTF-8. Честно даже не заморачивался этим вопросом. У меня так, есть кириллица - UTF-8, нет кириллицы - ASCII. Точнее сохранить можно в UTF-8, а по умолчанию win1251.

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

Там есть команды в модуле SYSTEM под названием ROT, и я не помню, в какую сторону там сдвиг. От сдвига влево можно ожидать скорее название ROL (ROtate Left) или ROTL. А то этот ROR в роли сдвига влево может привести к тихим, но коварным ошибкам при переносе программ.


Пользуйтесь, конечно, BigCrush, SmokeRand и PractRand 0.94 (по меньшей мере до 16 ТиБ) он проходит. Только сдвиги правильные проставьте и добейтесь прохождения внутреннего теста, без этого он развалится. Но я его сделал скорее как эксперимент для обхода ограничений системы типов Оберона, чем как нечто образцово-показательное

Ещё о генераторах: у Вас при прибавлении к 2147483647 всегда получается -2147483648? Это - устойчивое поведение компилятора или нет? Просто если у Вас будет везде Wraparound при целочисленном переполнении, то можете взять ГПСЧ поприличнее, шифр ChaCha20, с сидом от /dev/urandom или его аналогов.

Спасибо, за разрешение. Алгоритм симпатичный. Постоянно страдаю, если случайное число. Лезу в os api и достаю время. Ужасть ))).

ROR переименовал в RSH, чтобы уж точно была полная ассоциация с ASH и LSH. И обнаружил ошибку в сдвиге - integer переменные при сдвиге с переменной, сдвигаются как longint. Хорошо, что хоть при сдвиге на константу сдвигаются корректно в соответствии с типом. Ещё один ужасть (((.

Сегодня буду исправлять. И следующую сборку выложу с исправлениями.

Про прибавление. Да, это устойчивое поведение (по крайней мере хочется так думать). Все вычисления с целыми делаются, как с длинными целыми (64 разряда). И только при сохранении обрезаются до нужного размера.

>>> ГПСЧ поприличнее, шифр ChaCha20, с сидом от /dev/urandom или его аналогов.

Честно, я и слов таких не знаю. Меня вполне устраивает Ваш вариант. Спасибо ))).

У Linux и Windows есть специальные API именно для генерации случайных чисел, причём криптографического качества. В Linux - это "файл" /dev/urandom, в Windows - функции CryptAcquireContext, CryptGenRandom, CryptReleaseContext, CryptReleaseContext. Они не очень быстрые, но для начальных значений (seed) - в самый раз.


Вот ChaCha20: https://datatracker.ietf.org/doc/html/rfc7539, только счётчик не забудьте заменить на 64 бита. Он сложнее и нередко медленнее всяких bithack-генераторов (в т.ч. моего), но намного надёжнее. Впрочем, если Вы не занимаетесь каким-то серьёзным моделированием, то и алгоритмы попроще, в т.ч. мой вариант KISS, скорее всего подойдут.

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