OberonCore
https://forum.oberoncore.ru/

Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x86
https://forum.oberoncore.ru/viewtopic.php?f=30&t=6344
Страница 9 из 10

Автор:  Oleg N. Cher [ Среда, 20 Май, 2020 06:57 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Это очень хитрая ошибка, два дня искал. Флюктуации миграции в сторону BlackBox/CPfront.
Связана с подсчётом количества методов, который в Ofront и в BlackBox устроен по-разному.
Под список методов выделялся массив меньшего размера, чем требовалось, что приводило к порче памяти.
Исправил.

Автор:  Oleg N. Cher [ Воскресенье, 12 Июль, 2020 09:45 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Коллеги, у кого-нибудь здесь есть опыт низкоуровневого программирования под Linux, Windows? Такие дела. Недавно в voc/Ofront+ была найдена и исправлена ошибка в сборщике мусора. И, как оказалось, сборщик мусора вообще был незадействован. После фикса, который просто сводился к убиранию "творчества" Дэйва Брауна, я вернулся к тому же коду, что в оригинальном Ofront. И сборщик заработал, однако после пересборки самого себя транслятор стал в некоторые моменты трапиться. Отладка показала, что это происходит в момент взятия данных из стека. На стеке, как мы знаем, хранятся локальные переменные. И консервативный сборщик шпарит по ним, собирая указатели простым сравнением со списком уже выделенных указателей.

Вопрос такой: можно ли предположить, что если даже читать память из области стека, то будет приходить какой-то сигнал, прерывание или исключение? Если я прав, значит нужен обработчик, который не будет делать ничего. У кого-нибудь есть опыт подобного? Спасибо.

Вложения:
MarkStack.png
MarkStack.png [ 372.95 КБ | Просмотров: 1894 ]

Автор:  Rifat [ Понедельник, 13 Июль, 2020 15:20 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

На самом деле сложно понять, из-за чего именно трапится.
Есть два варианта:
- возможно, что срабатывает какой-то внутренний ASSERT в сборщике мусора;
- или система запрещает обращение по какому-то адресу.
Под стек на windows обычно выделяется что-то типа 10 Мб. Соответственно, обращаться к стеку можно по адресам от начального, то конечного. Соседние страницы памяти могут быть не выделены и при попытке к ним обратиться может возникать исключение.
Теоретически, возможна ситуация, что не ко всем страницам внутри определенного интервала можно обращаться, они могут быть выделены для других целей (антивирус, вирус, драйвер и т.д., может загружаться внутрь адресного пространства и занимать там какую-то область). По-хорошему, нужно учитывать такие моменты, что может быть не сплошной кусок памяти, а с разрывами (для стека это не очень актуально, а для выделения динамической памяти в куче это может быть актуально).

Автор:  budden [ Понедельник, 13 Июль, 2020 16:43 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Я бы сделал так:

1. Знать, где находится стек.

2. Знать, где находится куча.

3. В сборщике мусора не пытаться разыменовывать те "указатели", которые указывают ни на стек, ни на кучу. Тогда и исключений не будет. Исключения, мало того, что требуют обработчика, так ещё и их обработка занимает время.

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

Автор:  budden [ Понедельник, 13 Июль, 2020 16:52 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Хотя, поглядев на код... :roll:
Например, можно проверить версию о том, что логика сборщика неправильная и он пытается читать за пределами стека... И ещё неплохо бы понять, что именно делает GET

Автор:  Oleg N. Cher [ Понедельник, 13 Июль, 2020 17:44 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

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

__GET это же SYSTEM.GET. Читает из памяти по указанному адресу в переменную.

Проблема со сборкой мусора исправлена. Надеюсь, теперь уже окончательно.

Автор:  Oleg N. Cher [ Вторник, 04 Август, 2020 02:53 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Дмитрий Викторович, я сейчас вот накатил Ваш патч и столкнулся с такой проблемой:

Код:
MODULE OPP;

   TYPE
      Elem = POINTER TO RECORD
         next: Elem;
         pos: INTEGER;
      END;

      CaseTable = ARRAY 1 OF
         RECORD
            low, high: INTEGER
         END;

END OPP.

Раньше сгенерированный для этого модуля код выглядел так:
Код:
#ifndef OPP__h
#define OPP__h

#include "SYSTEM.h"

import void *OPP__init (void);

#endif
А после патча выглядит так:
Код:
#ifndef OPP__h
#define OPP__h

#include "SYSTEM.h"

typedef
   struct OPP__1 OPP_CaseTable[1];

typedef
   struct OPP_Elem__rec *OPP_Elem;

typedef
   struct OPP_Elem__rec {
      INTEGER _prvt0;
      char _prvt1[4];
   } OPP_Elem__rec;

import void *OPP__init (void);

#endif

И такой хедер не хочет включаться, т.к. в нём не определено OPP__1.

Ваша правка в DevCPC.DefineType. Было:
Код:
      IF (OPM.currFile = OPM.BodyFile) ...
Стало:
Код:
      IF (OPM.currFile IN {OPM.BodyFile, OPM.HeaderFile}) ...

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

Автор:  Дмитрий Дагаев [ Вторник, 04 Август, 2020 20:22 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Тут наложились мои эксперименты с динамической загрузкой (пока еще не доделанной) и привязкой загружаемых модулей. Даже, если тип неэкспортирован, тэг типа нужен.

На всякий случай прогнал свои 479 тестов с Вашей правкой и без - все совпадает для статически собираемых модулей.

Автор:  Oleg N. Cher [ Среда, 05 Август, 2020 04:08 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Да, CPfront генерирует код с этой правкой несколько другой, нежели Ofront+
В том плане, что для вышеприведённого модуля описание типа OPP__1 в хедере генерится.

Как успехи с динамической загрузкой? Вы ведь через стандартный механизм ОС .so/.dll делаете?

Автор:  Дмитрий Дагаев [ Среда, 05 Август, 2020 10:48 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Oleg N. Cher писал(а):
Как успехи с динамической загрузкой? Вы ведь через стандартный механизм ОС .so/.dll делаете?

Реализована для бэкенда LLVM в первой версии. Для CPfront-бэкенда Omf пока в работе. Грузятся объектники в coff и elf формате https://forum.oberoncore.ru/viewtopic.php?f=157&t=6423&start=20#p112043. Выставлена версия 0.95.

Автор:  Oleg N. Cher [ Четверг, 06 Август, 2020 17:54 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Это я видел, я же читаю форум. Не, именно для CPfront интересно.

Автор:  SovietPony [ Среда, 12 Август, 2020 09:07 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Я делал динамическую загрузку модулей через dlopen. Работает, но допилить cpfront надо. (секция CLOSE не регистрируется в дескрипторе модуля).

Автор:  Oleg N. Cher [ Среда, 09 Декабрь, 2020 02:38 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Немного забыл про этот форум. Новостей много, но основные:

    1. Наконец-то сделан корректный экспорт константных массивов

    2. Артур Ефимов заявил о переводе Free Oberon на ядро Ofront+

    3. Ofront+ показывает себя стабильным продуктом. В последнее время совсем мало правок. Конечно в планах ещё много всего, но пользовать уже очень можно.

Автор:  Дмитрий Дагаев [ Среда, 09 Декабрь, 2020 09:05 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Oleg N. Cher писал(а):
Наконец-то сделан корректный экспорт константных массивов

А Вы не думали/пробовали в Ofront+ делать константные структуры произвольного содержания?

Поясню. Если мы посмотрим на С-код, сгенеренный Ofront'ами, то там огромное число таких структур, например
Код:
static ADDRESS Math__exp[] = {
   1,
   0xde082fa8, (ADDRESS)Math_IntPower, 1<<8 | 0x44, 0,
};
static char Math__names[] = {
   0,
   'I','n','t','P','o','w','e','r',0,
};
static ADDRESS Math__ptrs[] = {
   0
};
struct SYSTEM_MODDESC Math__desc = {
   0, 13, 0, /* next, opts, refcnt */
   {2019, 10, 8, 13, 43, 18}, /* compTime */
   {0, 0, 0, 0, 0, 0}, /* loadTime */
   Math__body,
   0,
   1, /* nofimps */
   0, /* nofptrs */
   0, 0, 0, 0, 0, 0, 0, 0, /* csize..varBase */
   Math__names,
   Math__ptrs,
   Math__imp,
   (SYSTEM_DIRECTORY*)Math__exp,
   "Math"
};

И, что важно, эти структуры ложатся при загрузке в секцию данных, а не в секцию кода.
А в Обероне такого нет. И что, получается, мы не сможем такое сделать на Обероне?

Автор:  Oleg N. Cher [ Среда, 09 Декабрь, 2020 15:39 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Дмитрий Дагаев писал(а):
А Вы не думали/пробовали в Ofront+ делать константные структуры произвольного содержания?
Такие запросы от юзеров были. Но решили не усложнять язык.
Если доберётесь сделать, будет интересно посмотреть синтаксис.

Дмитрий Дагаев писал(а):
И, что важно, эти структуры ложатся при загрузке в секцию данных, а не в секцию кода.
А в Обероне такого нет. И что, получается, мы не сможем такое сделать на Обероне?
Ну да, получается, не сможем. Разве что в Ofront'е через уровень Си.

Автор:  GameHunter [ Пятница, 30 Апрель, 2021 04:17 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Вот такой модуль в ББ компилируется, а в ofront+ - нет:

Код:
MODULE Ex;

PROCEDURE Prc (p1:PROCEDURE(p:PROCEDURE); p2:PROCEDURE);
  BEGIN
    p1(p2)
  END Prc;

END Ex.

Автор:  kekc_leader [ Понедельник, 03 Май, 2021 04:48 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

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

А что если компилятор, когда видит в начале секции инициализации модуля (главный BEGIN) множество присваиваний вида "переменная := константа", загонял бы это всё (не во время выполнения, а в момент компиляции) в сегмент данных? Какие здесь могут быть проблемы? Такие данные ведь можно потом изменять?

Код:
MODULE A;
VAR m: ARRAY 4 OF BYTE;
BEGIN m[0] := 8; m[0] := 2; m[0] := 5; m[0] := 7
END A.

превращается в (условно):
Код:
.DATA   
m DB 8, 2, 5, 7

Автор:  Дмитрий Дагаев [ Понедельник, 03 Май, 2021 09:50 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

Получается неясная конструкция. А если добавить код, как Вы будете различать?
Код:
VAR m: ARRAY 4 OF BYTE; pm: POINTER TO ARRAY OF BYTE;
BEGIN NEW(pm, 4); m[0] := 8; pm[0] := 9; m[1] := 2+pm[0]; pm[1] := 8; m[2] := 5+pm[1]; m[3] := 7


Речь шла о возможной инициализации в определениях переменных, скажем так
Код:
VAR mArr: ARRAY 4 OF BYTE = {8, 2, 5, 7};


Это пока не предложение, а мысли вслух в контексте поднятых Oleg N. Cher проблем. Чтобы сделать Ofront на Обероне.

Автор:  Comdiv [ Понедельник, 03 Май, 2021 13:19 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

kekc_leader писал(а):
А что если компилятор, когда видит в начале секции инициализации модуля (главный BEGIN) множество присваиваний вида "переменная := константа", загонял бы это всё (не во время выполнения, а в момент компиляции) в сегмент данных? Какие здесь могут быть проблемы? Такие данные ведь можно потом изменять?
Хороший подход, но возможные проблемы, помимо дополнительного усложнения компилятора, Вы и сами показали в своём будто бы намеренно ошибочном примере.

Автор:  Oleg N. Cher [ Четверг, 06 Май, 2021 12:39 ]
Заголовок сообщения:  Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8

GameHunter писал(а):
Вот такой модуль в ББ компилируется, а в ofront+ - нет
Эта проблема тянется из оригинального Ofront. Исправлено.

Дмитрий Дагаев писал(а):
Это пока не предложение, а мысли вслух в контексте поднятых Oleg N. Cher проблем. Чтобы сделать Ofront на Обероне.
Вот эту сентенцию я вообще не понял. Ofront и так на Обероне. Там есть только один маленький сишный SYSTEM.c, реализующий системные возможности, ну как и в CPfront.

Господа, в контексте вашего обсуждения.

Реализовывать превращение присваиваний в константные данные не планирую. В Ofront+ и так есть то, чего нет во многих других реализациях — константные массивы.

Страница 9 из 10 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/