OberonCore

Тэкс. Для начала извиняюсь перед Дмитрием Викторовичем. Упомянутые выше правки в Stars действительно не Ваши, а оригинальные. Просто я заглянул в файл OPC вместо CPC, они же там в исходном архиве все в куче. Это отличия реализации Stars в Ofront и CPfront. Так что вопрос снят.

По новой ошибке. Она присутствует и в оригинальном Ofront, и в CPfront. Связана с отловом циклического определения типа. Разберёмся на днях.

Когда меняю исходник так:


Ofront и Ofront+ зависают, а CPfront впадает в безконечную рекурсию внутри процедуры CPC.Universal.

Снять рекурсию можно, добавив условие typ.comp IN {array, dynArray, record}, но тогда на UniversalArrayName такая же петрушка. Надо аккуратно смотреть, как разрывать этот круг. И да, после этого регрессионные тесты.

Исправлена проблема для бесконечной рекурсии. Модифицированы функции Universal, UniversalArrayName, появились UniversalEx, UniversalArrayNameEx (где определены корректные условия выхода из рекурсии). Также снято сообщение об ошибке OPM.Mark(244, str^.txtpos) в DefineType (может, и зря - у меня нет теста на этот case).
Это - тот самый случай, где по нескольку раз я запускал свои регрессионные тесты, пока не пришел к приемлемому решению.

Дмитрию Викторовичу спасибо за решение.

GameHunter, я хотел подождать, что ответит Йозеф Темпл, но он молчит. Судя по идеологии Ofront'а, я так думаю, что он предпочтёт вообще запретить такое рекурсивное определение. Ведь код:

это просто чуть замаскированное определение:
Изначально в Ofront'е это циклическое определение типа, и оно запрещено. Есть ещё рекурсивное определение типа, т.е.:
И оно тоже запрещено, что логично.

Но BlackBox разрешает такое циклическое определение типа. Мне бы хотелось увидеть практический случай применения такого подхода.

Самое простое, что я могу сделать, просто применить решение Дмитрия Викторовича. Но я ещё думаю. Конечно надо разрешить, хотя бы для совместимости с BlackBox.

Ну так страничное дерево, например...
Каждый уровень дерева - Arr.

Для дерева логичнее использовать указатели на записи, а не на массивы, разве нет?)

Дмитрий Викторович, Ваш фикс не проходит такие тесты:
(ловит ошибку 244, хотя если 2 убрать и сделать массив открытым, то компилит)

(порождает код со static Arr Ex5_a, где Arr не определено)

Ну так если рекурсивно можно определять POINTER TO RECORD, то почему же нельзя POINTER TO ARRAY?

Если оборачивать каждый POINTER TO ARRAY в RECORD, то это лишняя косвенность, опять же - доп. поля не всегда нужны.

Реализовал в Ofront'е+ возможность вставок из Оберон-процедуры в генерируемый текст на Си в виде комментария специального вида. Сделано, главным образом, для того, чтобы было можно писать код на встроенном в Си-компилятор ассемблере:

P.S. По рекурсивным определениям: решение Дмитрия Дагаева в репозиторий Ofront+ внедрено в предложенном виде. Пара случаев некорректной отработки таких определений, описанных мной выше, ещё в процессе.

А стандартный механизм кода в Ofront+ через не получался?

Я просто не пробовал.

Про некорректные обработки я помню, обязательно еще посмотрю.

Да, в Ofront'е есть такой механизм. Но он весьма ограничен — не понимает многострочных вставок. Есть и другой механизм: опция "-i": include header and body prefix files (Module.h0/.c0), которая добавляет .h0 и .c0-файлы в начало .h и .c-файлов.

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

Получилось собрать код на Обероне для игровой приставки Nintendo/NES/Dendy/Famicom. Через компилятор cc65 с помощью Ofront+.





Подсистема NesDev включена в XDev. В ближайшее время буду её обновлять и наверное даже вынесу в отдельный репозиторий.

Спасибо Shiru за помощь и консультации.

Исправил в новой версии для МультиОберона рекурсивные определения типов (прилагается). Более глубокое тестирование показало наличие в старой версии еще проблемы с некорректностью генерации .h - файла: те же тесты при импортировании из другого файла не собирались. Изменения следующие:
1. Расширены константы типов (RECURSIVE_TYPE TEMPORARY_TYPE), вместо безобразия 3+OPG.currFile поставлено MAX_TYPE+OPG.currFile.
2. Изменена обработка в DefineType - и для .h, и для .c. Ошибка 244 заменена на обработчик рекурсивных определений.
3. Изменено условие Undefined с учетом RECURSIVE_TYPE

Олег, что вы решили по рекурсивным объявлениям массивов - будете реализовывать, или оставите запрет?

Ещё одна ошибка. Вот 3 модуля:



Они компилирутся Ofront+'ом, но затем не компилирутся коспилятором C.
Вот что у меня выдаёт MinGW-w64-gcc:

Опубликуете?

Да, с новой версией.

Думаю, надо реализовать. Хотя бы для совместимости с BlackBox. Первая часть-то уже реализована на основе фикса Дм. Дагаева. Надо только поправить найденные мной пару ошибок. Постараюсь сделать сегодня или завтра.

Выкатываю решение.

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

Следующая ошибка.
Вот два модуля:



Всё успешно компилируется и линкуется в конечный исполняемый файл. Но при запуске происходит какая-то системная ошибка. Если убрать объявление Main.Rec либо процедуру Do, ошибки не возникает, и я вижу на экране "Done".