OberonCore https://forum.oberoncore.ru/ |
|
Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x86 https://forum.oberoncore.ru/viewtopic.php?f=30&t=6344 |
Страница 9 из 17 |
Автор: | 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. И сборщик заработал, однако после пересборки самого себя транслятор стал в некоторые моменты трапиться. Отладка показала, что это происходит в момент взятия данных из стека. На стеке, как мы знаем, хранятся локальные переменные. И консервативный сборщик шпарит по ним, собирая указатели простым сравнением со списком уже выделенных указателей. Вопрос такой: можно ли предположить, что если даже читать память из области стека, то будет приходить какой-то сигнал, прерывание или исключение? Если я прав, значит нужен обработчик, который не будет делать ничего. У кого-нибудь есть опыт подобного? Спасибо.
|
Автор: | 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 |
Хотя, поглядев на код... Например, можно проверить версию о том, что логика сборщика неправильная и он пытается читать за пределами стека... И ещё неплохо бы понять, что именно делает 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 |
Немного забыл про этот форум. Новостей много, но основные:
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 из 17 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |