OberonCore https://forum.oberoncore.ru/ |
|
Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x86 https://forum.oberoncore.ru/viewtopic.php?f=30&t=6344 |
Страница 14 из 17 |
Автор: | adimetrius [ Понедельник, 30 Август, 2021 22:17 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Если я правильно понял диагноз по третьей проблеме, то в ББ есть например, вот такое определение в Properties с вложенной записью: Код: StdProp = POINTER TO RECORD (Property) next-: Property; known, readOnly, valid: SET; color: Dialog.Color; typeface: Fonts.Typeface; size: INTEGER; style: RECORD val, mask: SET END; weight: INTEGER; END; StdProp не EXTENSIBLE, в отличие от примера, вызывающего ошибку. Возможно, тогда дело не во вложенности, а в расширяемости, или в комбинации свойств записей. |
Автор: | Oleg N. Cher [ Вторник, 31 Август, 2021 23:00 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
adimetrius писал(а): Возможно, тогда дело не во вложенности, а в расширяемости, или в комбинации свойств записей. Да, дело точно в расширяемости.Я так понимаю, что транслятор дублирует два раза запись, которую расширяет (Ex__1). Но в Си структуры, вложенные в другие структуры, не могут иметь одинаковое имя. Йозеф предложил два решения, но, видимо, делать правку в скором будущем не будет. Я ещё в процессе обдумывания. |
Автор: | Дмитрий Дагаев [ Среда, 01 Сентябрь, 2021 17:48 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): По третьей Так что, я думаю, нам есть смысл подключить Дмитрия Викторовича Дагаева, если у него есть интерес закрыть эту ошибку в МультиОбероне. Я сейчас в отпуске, посмотрю позже. Навскидку вместо дублирования записей должно быть использование анонимной записи, определённой в базовом модуле Ex1. |
Автор: | Oleg N. Cher [ Среда, 01 Сентябрь, 2021 20:16 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
На первый взгляд мысль кажется очень интересной. Но как тогда обращаться к элементам внутренней анонимной структуры? Я передал Йозефу Ваше предложение, посмотрим, что ответит. |
Автор: | Дмитрий Дагаев [ Четверг, 02 Сентябрь, 2021 17:27 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): На первый взгляд мысль кажется очень интересной. Но как тогда обращаться к элементам внутренней анонимной структуры? Я передал Йозефу Ваше предложение, посмотрим, что ответит. В примере анонимная структура 'y' не имеет элементов, хотя может иметь. Но это превращается в С коде в элемент 'y' с типом в виде анонимной структуры struct без элементов. |
Автор: | Oleg N. Cher [ Четверг, 02 Сентябрь, 2021 21:26 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Понятно. Ещё такой вопрос: анонимные структуры являются частью стандарта ANSI C? Судя по этой ссылке, нет. Глубже не копал. Думаю, тогда лучше не стоит так делать. Не везде есть C11 и выше. |
Автор: | Wlad [ Пятница, 03 Сентябрь, 2021 13:15 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Понятно. Ещё такой вопрос: анонимные структуры являются частью стандарта ANSI C? компилятора под руками нет... Судя по этой ссылке, нет. Глубже не копал. Думаю, тогда лучше не стоит так делать. Не везде есть C11 и выше. Только в виде вложенных и возвращаемых значений, насколько мне память не изменяет. |
Автор: | Wlad [ Пятница, 03 Сентябрь, 2021 13:28 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): .Не везде есть C11 и выше. нет, я думаю, акценты - несколько иначе надо расставить...Есть конторы, где обязательно надо самые последние и свежие новшества языка использовать, а есть, где - только "прошедшие сертификацию" версии разрешается работать. Например, во времена, когда уже везде пользовались gcc версии 4.5+, в конторе, где я работал, разрешалось использовать только 2.97.*... И там даже 99 версию не разрешалось включать... |
Автор: | Oleg N. Cher [ Пятница, 03 Сентябрь, 2021 19:21 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Влад, всё верно. Но в данном случае мы гонимся не за последними новшествами из мира Си, а чтобы покрыть побольше Си-компиляторов, в т.ч. и старых. |
Автор: | Wlad [ Воскресенье, 05 Сентябрь, 2021 03:14 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Влад, всё верно. Но в данном случае мы гонимся не за последними новшествами из мира Си, а чтобы покрыть побольше Си-компиляторов, в т.ч. и старых. Могу, конечно же, ошибаться, но - не пустые ли это заморочки получаются? Потому, что я уже практически не знаю компиляторов си(++), даже для встраиваемых приложений, где бы не было самых последних стандартов реализовано. Нет, года четыре назад, я столкнулся с уникумом-начальником, который требовал, что бы ПО писалось на K&R варианте стандарта...но это уже, похоже, - исчезающий тип. В основном все уже безоговорочно приняли минимумом 11-тые стандарты. А на си++ уже требуют 17ый стандарт применять. И - самое главное - уже как бы и повальное увлечение следованию MISRA проходит и восстанавливается здравый смысл. Очень этому статические анализаторы особенно способствуют... |
Автор: | Oleg N. Cher [ Суббота, 18 Сентябрь, 2021 21:37 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Тем временем, в Ofront+ появилась долгожданная поддержка двухбайтного символьного типа CHAR. Это открывает перед нами отличные перспективы по пересборке модулей BlackBox при помощи Ofront+, а также можно уже смело присмотреться к большой библиотеке исходников Гельмута Цинна, которые тоже можно пробовать пересобирать Ofront'ом+. Лично мне очень приятно, что такая серьёзная, не побоюсь этого слова, работа привела к практически полной поддержке в Ofront+ Компонентного Паскаля. У нас нет ещё только поддержки мета-информации для работы BlackBox'овского модуля Meta, но я надеюсь, что нам это ещё долго не понадобится. В GPCP тоже этого нет, но, тем не менее, GPCP имеет право называться компилятором Компонентного Паскаля, согласно описания языка. В Ofront+ появилась опция командной строки -w, отвечающая за то, как именно интерпретируются символы исходника программы: без -w - как и раньше (т.е. любой символ попадает в строку по его коду, и кодировка может быть абсолютно любая), а с -w транслятор считает, что на вход поступают широкие символы, даже если кодировка исходника UTF-8. Ещё раз. На вход без режима -w можно подавать что угодно, любую кодировку - хоть 1251, хоть 866, хоть KOI-8R. Она просто ляжет в целевой сишник с теми же кодами, что и входящие символы. А вот в режиме -w нужно подавать только такие юникодные символы, которые поместятся в два байта. Иначе будет ошибка err 3. Это я предусмотрел специально. err #3: illegal character in string Я думаю, будет очень хорошо показывать юзеру, что его хитрый символ (типа эмодзи) не проходит компиляцию как один широкий символ. С опцией -w пока что поддерживается только входной формат .txt в кодировке UTF-8 (в версии для BlackBox - и .odc), но список входящих форматов мы обязательно расширим. В итоге нам должно быть без разницы, как именно закодирован исходник. Я как раз хотел этот момент автоматизировать и не задавать доп. ключами. А вот как именно интерпретировать символы - совсем другое дело, для этого теперь есть опция -w. А когда мы научим Texts понимать формат .odc (я планирую это сделать), оттуда будут идти широкие символы, но нужно оставить возможность, чтобы они интерпретировались как UTF-8 (без ключа -w). Кстати, в процессе работы над CHAR появилась интересная мысль сделать ключик -w переключателем широкого или узкого CHAR в Обероне-07. Уже даже реализовал. Я подумал, что ведь раз будут идти широкие символы с входного потока, а тип CHAR в O7 только один, то нормально будет их обрабатывать именно как широкие. А если будут идти узкие, в UTF-8, то нормально будет узкие. Расклад по широкому CHAR'у: Oberon-1, Oberon2: CHAR, SYSTEM.CHAR16 Oberon-07: варьируемой длины CHAR КП: SHORTCHAR, CHAR Oberon-3: CHAR, LONGCHAR Одна небольшая тонкость, связанная с ключиком -w: Модуль Код: MODULE TestChar16; VAR ch: CHAR; BEGIN ch := "Ж" END TestChar16. С -w поступивший символ "Ж" будет интерпретирован как широкий CHAR и программа нормально скомпилится. А без -w символ "Ж" это будет юникодовая строка, состоящая из двух байт, и программа уже не скомпилится. Код: MODULE TestChar16; VAR i: INTEGER; BEGIN i := LEN("Ж") END TestChar16. Здесь с -w длина будет 1, а без -w длина 2. Но тут, надеюсь, всё понятно) Также ввёл для Оберона-3 новую операцию LCHR. Связано это с тем, что CHAR тут короткий, и поэтому CHR не может и не должна выдавать длинный символ, значит нужна новая операция. Для O1, O2 реализован SYSTEM.LCHR. Также во всех диалектах реализованы типы SYSTEM.CHAR8 и SYSTEM.CHAR16. Я подверг Ofront+ зверскому испытанию - попробовал оттранслировать модуль Strings из BlackBox: Пришлось включить ключик -w, а то там есть прямое задание широких символьных литералов. А вот часть ББ, собранная для Linux. Strings и Math должны работать. Из Kernel взято только несколько процедур: Модули bb* не только транслируются, но и компилятся сишкой. Но их работу я не тестировал. Привязки LinLibc и LinLibW сделаны очень сильно с уклоном на 32-битность, надо перепахивать. Пока сделал, что смог. К сожалению, нет возможности для заимствованных привязок тестировать все функции. Один очень важный момент: перед сборкой любого проекта новым Ofront+ нужно удалить все символьники. Пришлось немного изменить формат символьников. OP2 вообще очень похабно работает с символьниками: если подсунуть символьник неправильного формата, то транслятор закрэшится почти гарантированно. И это касается и Ofront, и Ofront+, и BlackBox. |
Автор: | Oleg N. Cher [ Пятница, 15 Октябрь, 2021 12:05 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Для третьей проблемы выкатываю такое решение. Компилируемость проверил в GCC, Clang, Turbo C v2.01, cc65, SDCC и SCCZ80. |
Автор: | Oleg N. Cher [ Понедельник, 27 Декабрь, 2021 17:06 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
В процессе реализации RECORD [union] в Ofront+ столкнулся с вопросом наследования системного флага при наследовании записей. Конечно посматриваю на BlackBox. Оказалось, что в BlackBox наследовать от безтеговых записей с системным флагом можно. Более того, можно даже иметь тегированную запись внутри безтеговой, притом BlackBox не мешает иметь тегированные записи с тегированными (отслеживаемыми сборщиком) указателями внутри записи, унаследованной от RECORD [union]. Это страшное безобразие, которое можно оправдать только если безтеговость неявно переходит во внутренню запись. Да и то, хорошо ли, что неявно? В общем, вопрос к знатокам: проясните этот момент. Может нам стоит зареквестить в ББ генерацию ошибки в случае объявления тегированной записи, унаследованной от безтеговой? Пусть программист явно и осознанно подставит туда системный флаг, не полагаясь на такое неявное поведение ББ. Я затрудняюсь даже представить себе юнион с отслеживаемыми сборщиком указателями внутри. |
Автор: | Oleg N. Cher [ Вторник, 28 Декабрь, 2021 18:37 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Ну, я так понимаю, никто ничего не хочет добавить по данному вопросу? Между тем, у Ofront'а+ праздник: 1,500 коммитов! С чем я нас всех поздравляю! Сейчас будет 1,501-й - окончательная реализация RECORD [union]. Вычисление размера поборол, всё правильно вычисляет, и размер, и выравнивание. |
Автор: | GameHunter [ Пятница, 14 Январь, 2022 21:20 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Этой ошибке не было в одной из предыдущих версий ofront+'а (не могу сказать в какой именно) |
Автор: | Oleg N. Cher [ Суббота, 15 Январь, 2022 02:39 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
А теперь смотрите как реагирует BlackBox на подобный код: То есть, проблема Ofront'а+ только в том, что он на него не ругается. Это мы поправим. Здесь вместо ARRAY OF используйте POINTER TO ARRAY [untagged] OF, лучше всего вот так: Код: PROCEDURE GetModuleHandleA* ["GetModuleHandleA"] (lpModuleName: POINTER TO ARRAY [untagged] OF CHAR): S.PTR; Зачем здесь нужно доп. задание имени в скобках? Это указание, что функция внешняя и тело BEGIN..END не требуется. Для модулей, помеченных системным флажком [foreign], это необязательное условие.Кстати, здесь у Вас должен использоваться диалект с однобайтным CHAR, иначе надо GetModuleHandleW. Ещё лучше используйте WinApi, он для того и создан: Код: MODULE Win; IMPORT w := WinApi;
PROCEDURE Example; BEGIN IF w.GetModuleHandleA(NIL)=0 THEN END; END Example; END Win. |
Автор: | Oleg N. Cher [ Суббота, 15 Январь, 2022 16:58 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Сделал отчёт об этой проблеме на форуме Центра. По поводу ошибки сравнения с NIL на уровне Си - погляжу, выглядит действительно странновато. |
Автор: | GameHunter [ Воскресенье, 16 Январь, 2022 04:32 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Хорошо, спасибо. Для связи с Windows Api хорошо работает такая конструкция: Код: PROCEDURE -GetModuleHandleA * (IN [nil] lpModuleName:ARRAY [untagged] OF SHORTCHAR): HMODULE "GetModuleHandleA(lpModuleName)";
|
Автор: | GameHunter [ Воскресенье, 16 Январь, 2022 04:37 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Следующий вопрос. Вот простой модуль: Код: MODULE Ex; IMPORT Console; BEGIN Console.String("Asdf"); Console.Flush(); END Ex. Он компилируется и ofront+'ом, и в дальнейшем си. Но почему-то не линкуется. Вот что пишет gcc (mingw-w64): "c:/Util/MinGW-w64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x2e): undefined reference to `WinMain' collect2.exe: error: ld returned 1 exit status" В чём может быть причина? Со старой версией ofront+'а программа успешно линкуется и исполняется. |
Страница 14 из 17 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |