OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 03 Апрель, 2020 03:39

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 153 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8
Автор Сообщение
СообщениеДобавлено: Четверг, 30 Январь, 2020 01:44 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 378
Откуда: Украина, Днепропетровская обл.
Тэкс. Для начала извиняюсь перед Дмитрием Викторовичем. Упомянутые выше правки в Stars действительно не Ваши, а оригинальные. Просто я заглянул в файл OPC вместо CPC, они же там в исходном архиве все в куче. Это отличия реализации Stars в Ofront и CPfront. Так что вопрос снят.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 30 Январь, 2020 08:39 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 378
Откуда: Украина, Днепропетровская обл.
Когда меняю исходник так:

Код:
MODULE Ex4;

TYPE
  ArrPtr = POINTER TO Arr;
  Arr = ARRAY OF ArrPtr;

END Ex4.

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


Вложения:
Infinite.png
Infinite.png [ 165.92 КБ | Просмотров: 573 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 30 Январь, 2020 19:02 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 433
Откуда: Москва
Oleg N. Cher писал(а):
Ofront и Ofront+ зависают, а CPfront впадает в безконечную рекурсию внутри процедуры CPC.Universal.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 05 Февраль, 2020 14:51 

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


Вложения:
OPC_Univ.txt [51.71 КБ]
Скачиваний: 71
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Февраль, 2020 20:43 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 378
Откуда: Украина, Днепропетровская обл.
Дмитрию Викторовичу спасибо за решение.

GameHunter, я хотел подождать, что ответит Йозеф Темпл, но он молчит. Судя по идеологии Ofront'а, я так думаю, что он предпочтёт вообще запретить такое рекурсивное определение. Ведь код:
Код:
TYPE ArrPtr = POINTER TO Arr; Arr = ARRAY OF ArrPtr;

это просто чуть замаскированное определение:
Код:
TYPE ArrPtr = POINTER TO ARRAY OF ArrPtr;
Изначально в Ofront'е это циклическое определение типа, и оно запрещено. Есть ещё рекурсивное определение типа, т.е.:
Код:
TYPE Arr = Arr;
И оно тоже запрещено, что логично.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Февраль, 2020 14:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9222
Откуда: Россия, Орёл
Ну так страничное дерево, например...
Каждый уровень дерева - Arr.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Февраль, 2020 01:59 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 378
Откуда: Украина, Днепропетровская обл.
Для дерева логичнее использовать указатели на записи, а не на массивы, разве нет?)

Дмитрий Викторович, Ваш фикс не проходит такие тесты:
Код:
MODULE Ex4;

TYPE
  ArrPtr = POINTER TO Arr;
  Arr = ARRAY 2 OF ArrPtr;

END Ex4.
(ловит ошибку 244, хотя если 2 убрать и сделать массив открытым, то компилит)

Код:
MODULE Ex5;

TYPE
  Arr = ARRAY 2 OF POINTER TO Arr;

VAR
  a: Arr;

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Февраль, 2020 07:05 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9222
Откуда: Россия, Орёл
Ну так если рекурсивно можно определять POINTER TO RECORD, то почему же нельзя POINTER TO ARRAY?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 11 Март, 2020 08:36 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 378
Откуда: Украина, Днепропетровская обл.
Реализовал в Ofront'е+ возможность вставок из Оберон-процедуры в генерируемый текст на Си в виде комментария специального вида. Сделано, главным образом, для того, чтобы было можно писать код на встроенном в Си-компилятор ассемблере:
Код:
PROCEDURE Code;
BEGIN
(*@
    __asm
        LD A, B
    __endadm;
*)
END Code;
Код:
static void Mod_Code (void)
{
    __asm
        LD A, B
    __endadm;
}

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 11 Март, 2020 08:51 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 433
Откуда: Москва
Oleg N. Cher писал(а):
Реализовал в Ofront'е+ возможность вставок из Оберон-процедуры в генерируемый текст на Си в виде комментария специального вида. Сделано, главным образом, для того, чтобы было можно писать код на встроенном в Си-компилятор ассемблере:
Код:
PROCEDURE Code;
BEGIN
(*@
    __asm
        LD A, B
    __endadm;
*)
END Code;
Код:
static void Mod_Code (void)
{
    __asm
        LD A, B
    __endadm;
}

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

А стандартный механизм кода в Ofront+ через не получался?
Код:
PROCEDURE \[code\] Code* ()
      '__asm
                LD A, B
                __endadm';

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 11 Март, 2020 10:15 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Март, 2020 03:04 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 378
Откуда: Украина, Днепропетровская обл.
Получилось собрать код на Обероне для игровой приставки Nintendo/NES/Dendy/Famicom. Через компилятор cc65 с помощью Ofront+.

Изображение

Изображение

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Апрель, 2020 10:39 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 433
Откуда: Москва
Oleg N. Cher писал(а):
Пара случаев некорректной отработки таких определений, описанных мной выше, ещё в процессе.

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


Вложения:
OPC.txt [51.07 КБ]
Скачиваний: 1
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 153 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2020, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB