OberonCore https://forum.oberoncore.ru/ |
|
Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x86 https://forum.oberoncore.ru/viewtopic.php?f=30&t=6344 |
Страница 4 из 17 |
Автор: | Comdiv [ Четверг, 05 Сентябрь, 2019 15:57 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Буду признателен за хорошие идеи. Можно, конечно, думать и предлагать, но перед этим интересно узнать про предыдущий опыт. Иван делал сборку ББ с возможностью писать ключевые слова строчными буквами. Насколько востребована эта возможность?
|
Автор: | Comdiv [ Четверг, 05 Сентябрь, 2019 16:03 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Info21 писал(а): Наличие у товарищей таких идиосинкразий намекает на наличие и других особенностей. Ещё, лягушку можно варить постепенно. Правда, непонятно, кто кого сварит в конце концов .
|
Автор: | Oleg N. Cher [ Пятница, 06 Сентябрь, 2019 21:40 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Comdiv писал(а): Можно, конечно, думать и предлагать, но перед этим интересно узнать про предыдущий опыт. Иван делал сборку ББ с возможностью писать ключевые слова строчными буквами. Насколько востребована эта возможность? Да. Иван, а ты как-то решил проблему запрета на использования идентов DO или TYPE при работе в нижнем регистре?
|
Автор: | Иван Денисов [ Суббота, 07 Сентябрь, 2019 08:19 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Comdiv писал(а): Можно, конечно, думать и предлагать, но перед этим интересно узнать про предыдущий опыт. Иван делал сборку ББ с возможностью писать ключевые слова строчными буквами. Насколько востребована эта возможность? Да. Иван, а ты как-то решил проблему запрета на использования идентов DO или TYPE при работе в нижнем регистре?Там это автоматически решается тем, что они считаются ключевыми словами и проводят к ошибке компиляции. Так что приходится их переименовать. У Trurl, к слову, более элегантное решение для программирования ключевыми словами в нижнем регистре. |
Автор: | Oleg N. Cher [ Суббота, 07 Сентябрь, 2019 16:53 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Протестировал решение Трурля на таком модуле: Код: module DO; end DO. Оно тоже не решает проблему идентов в верхнем регистре, совпадающих с ключевыми словами.Здесь может даже регистровая нечувствительность была бы лучше? По крайней мере, тогда бы такие иденты запрещались, приравниваясь к ключевым словам. Хотя бардака типа: Код: fOR i := 1 To 10 bY 2 do .. eNd; конечно же не хочется...
|
Автор: | Иван Денисов [ Суббота, 07 Сентябрь, 2019 17:02 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Протестировал решение Трурля на таком модуле: Код: module DO; end DO. Оно тоже не решает проблему идентов в верхнем регистре, совпадающих с ключевыми словами.Здесь может даже регистровая нечувствительность была бы лучше? По крайней мере, тогда бы такие иденты запрещались, приравниваясь к ключевым словам. Хотя бардака типа: Код: fOR i := 1 To 10 bY 2 do .. eNd; конечно же не хочется...Не должно быть таких идентификаторов в программе, которые совпадают с ключевыми словами. Не понимаю в чем проблема, Олег... |
Автор: | Comdiv [ Суббота, 07 Сентябрь, 2019 18:42 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Иван, есть какие-то данные о востребованности прописных ключевых слов? |
Автор: | Oleg N. Cher [ Суббота, 07 Сентябрь, 2019 19:40 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Иван Денисов писал(а): Не должно быть таких идентификаторов в программе, которые совпадают с ключевыми словами. Не должно быть логически, ибо это программеру не надо? Или не должно быть вообще и запрещено директивно транслятором?В общем, я даже придумал как в решении Трурля запретить иденты в верхнем регистре, совпадающие с ключевыми словами. Но чем больше я углубляюсь в реализацию лоукейса, тем всё меньше мне это нравится. Ключевые слова лоукейсом сделал, а как же теперь быть с типами? Впиливаться в OPT? Пожалуй, я откажусь от поддержки ключ. слов в нижнем регистре совсем. |
Автор: | Oleg N. Cher [ Воскресенье, 08 Сентябрь, 2019 01:09 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Всё-таки реализовал в Обероне-3 лоукейс. Теперь программисты смогут потешить свою лоукейсную жажду. При работе в нижнем регистре иденты, совпадающие с ключ. словами в верхнем, запрещены. SYSTEM по-прежнему остаётся капсом, но это я ещё обдумываю. Также начал работу над реализацией беззнакового типа UBYTE. Из двух соображений: совместимость с GPCP и улучшение поддержки разработки для слабых таргетов. Есть и третье соображение: в Обероне-07 тип BYTE беззнаковый, так что всё равно нужно сделать. Тип UBYTE уже можно тестировать. |
Автор: | Илья Ермаков [ Понедельник, 09 Сентябрь, 2019 12:34 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Ну, например, type или module используются повсеместно как имена переменных, полей и т.п. |
Автор: | PSV100 [ Понедельник, 09 Сентябрь, 2019 18:50 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Ввести регистровую независимость как в Паскале или Аде видится шагом назад (просто не хочется мешанины, когда ident и — iDeNT одно и то же) И наоборот -- Паскаль, Ада (а также SQL и некоторые др.) могут и уменьшать мешанину -- например, одновременное содержание переменных "ident" и "Ident" (или "iDent" и т.д.) в одной области определения/видимости может свидетельствовать о наличии некоторой потенциальной прикладной ошибки, и Паскаль-стиль не позволит завести подобные идентификаторы. |
Автор: | PSV100 [ Понедельник, 09 Сентябрь, 2019 18:56 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Я слышал, что в Zonnon'е если модуль начинается с MODULE, то ключевые слова ожидаются в верхнем регистре, а если с module, то только в нижнем. Это очень интересное решение, но, к сожалению, не учитывает момент, когда программист, работая с ключевыми словами в нижнем регистре заведёт и экспортирует переменную с именем TYPE (или DO), а другой программист, работая с исходником в верхнем регистре, не сможет её использовать. Этого бы очень хотелось избежать. Как бы вы предложили поступить в этом случае? Oleg N. Cher писал(а): Протестировал решение Трурля на таком модуле: Код: module DO; end DO. Оно тоже не решает проблему идентов в верхнем регистре, совпадающих с ключевыми словами.Здесь может даже регистровая нечувствительность была бы лучше? По крайней мере, тогда бы такие иденты запрещались, приравниваясь к ключевым словам. Хотя бардака типа: Код: fOR i := 1 To 10 bY 2 do .. eNd; конечно же не хочется...Видимо, в данном случае регистровая нечувствительность, фактически, является единственным решением. Может быть, есть смысл в некой ограниченной нечувствительности, сохраняя основные достоинства регистронезависимости и чувствительности к регистру. Например. Пусть ключевые слова задаются только в верхнем или нижнем регистре в зависимости от MODULE/module в начале. Буквы идентификаторов должны быть в одном и том же регистре, т.е. нельзя одновременно определить (в одной области), к примеру, "ident" и "Ident" или "iDent" и т.д. При совпадении набора букв в идентификаторе и ключевого слова хотя бы одна буква в идентификаторе должна быть в ином регистре. К примеру, допустимы "do" или "Do" (и "dO") при наличии ключевого слова "DO". Ключевое (и, возможно, самое проблемное) -- необходимо разделить пространство имён -- на имена типов и все прочие имена, где две области имеют свою уникальность (по аналогии с рядом функциональных языков, и, вроде бы, в Паскаль-подобном языке такое размежевание потенциально осуществимо). Тогда имеется возможность иметь идентичные имена в типах и переменных/параметрах/константах (а также и процедурах), напр.: Код: var date: date; (* или: var date: Date; *) При этом нельзя одновременно определить в одной области переменные как "var date: ..." и, напр., "var Date: ...". И не могут быть одновременно два типа, напр., как "type date = ..." и "type Date = ...". На границе модулей экспортируемый интерфейс адаптируется для импортирующего модуля. Для последнего экспортируемые имена являются условно регистронезависимыми, но допускается только один вариант применения регистра в идентификаторе. Например: Код: (* Модуль с ключевыми словами в верхнем регистре, экспортирующий тип и переменную *) MODULE M1; TYPE Do* = ...; VAR do*: Do; ... END M1. (* Модуль с ключевыми словами в нижнем регистре, импортирующий элементы из M1 *) module M2; import M1; (* Использование импортированного типа. Идентификатор "Do" может быть в любом регистре, напр. и как "DO" и пр., но допустим только один вариант применения: *) var d1: M1.Do; var d2: M1.Do; (* var d2: M1.DO; -- ошибка, т.к. в модуле уже используется вариант M1.Do *) (* Применение импортированной переменной. Аналогично, регистр идентификатора "do" может быть любым, но в единственном варианте: *) ... begin d1 := M1.do; d2 := M1.do; ... end; ... end M2. В импортирующем модуле в случае квалифицированных имён (как "модуль.идентификатор") регистр идентификатора может быть любым (но в единственном варианте). Если гипотетически в языке возможен и доступ без квалификации, то требуется использовать вариант регистра идентификатора, отличающийся от ключевого слова: Код: MODULE M1; TYPE Do* = ...; VAR do*: Do; ... END M1. module M2; import M1; (* использование типа M1.Do: *) var d1: DO; var d2: DO; (* использование переменной M1.do: *) ... begin d1 := Do; d2 := Do; ... end; ... end M2. Возможна и некая расширенная форма директивы а-ля import в стиле: Код: (* импортируется переменная и тип с указанием варианта имени для каждого идентификатора: *) import M1(Do, type DO); Не в курсе, возможна ли подобная схема для Оберон-экспериментов (у себя ранее рассматривалась схожая проблематика, но не для Оберонов). |
Автор: | Oleg N. Cher [ Понедельник, 09 Сентябрь, 2019 21:46 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Знаете, PSV100, тогда уж лучше вообще ничего не трогать, пусть будет как есть) Технически впилить регистровую независимость будет сложнее, чем то, что сделано сейчас. Так стоит ли? Илья Ермаков писал(а): Ну, например, type или module используются повсеместно как имена переменных, полей и т.п. Тут мы пойдём по пути ущемления любителей нижнего регистра, они просто не смогут использовать такие идентификаторы. Пущай присматриваются к правильному, верхнему PSV100 писал(а): И наоборот -- Паскаль, Ада (а также SQL и некоторые др.) могут и уменьшать мешанину -- например, одновременное содержание переменных "ident" и "Ident" (или "iDent" и т.д.) в одной области определения/видимости может свидетельствовать о наличии некоторой потенциальной прикладной ошибки, и Паскаль-стиль не позволит завести подобные идентификаторы. Ну а мне нравится практика иметь переменную type типа Type. При наличии в языке ключевого слова TYPE. И не нравится бардак типа fOR i:=0 tO 10 bY 2 Do
|
Автор: | GameHunter [ Понедельник, 30 Сентябрь, 2019 23:23 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Вот тестовый модуль: Код: MODULE Test; VAR i:LONGINT; x:SHORTREAL; BEGIN x:=i; x:=1.0; x:=1.0+i; END Test. Ofront+ (в режиме компонентного пвскаля с ключом -C) в предпоследней строчке выдаёт ошибку: 10:11 err 113 incompatible assignment Oleg N. Cher, помните, я вас убедил, что вещественные константы быть нетиптзированными, и должны присваиываться и переменным типа REAL, и переменным типа SHORTREAL, при этом без потери точности. Это, конечно, должно выполняться не только для простых присваиваний, но и для выражений. С уважением, GH. |
Автор: | Oleg N. Cher [ Вторник, 01 Октябрь, 2019 00:18 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
А Вы бы, GameHunter, для начала проверили тот же самый код в BlackBox и увидели бы, что он выдаёт ту же ошибку несовместимого присваивания. Помните, Вы меня убеждали, что вещественные константы должны по умолчанию иметь самую высокую точность? Ну так вот, это оно и есть. В Компонентном Паскале для присваивания REAL => SHORTREAL используется SHORT(). Разумеется, для константных выражений это смягчено. А для неконстантных — нет. Юзайте так: Код: x:=SHORT(1.0)+i;
|
Автор: | GameHunter [ Вторник, 01 Октябрь, 2019 05:00 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Да, ваша правда, в сообщении о языке написано: A real number is always of type REAL. Что ж, пусть будет так, хотя это и неудобно. |
Автор: | Oleg N. Cher [ Вторник, 01 Октябрь, 2019 12:41 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
В КП так сделали, чтобы избавиться от E и D при описании вещ. чисел в экспоненциальном виде, как это было в Обероне-2. Сочли D для двойной точности излишеством. Кстати, в Обероне-2 короткий вещественный тип имеет преимущество при вычислениях, поэтому константы в экспоненциальном виде с E и константы в неэкспоненциальном виде описывают короткие числа. А на длинные выходят только по необходимости, используя D. Сказывается то, что работали на старых машинах, где двойная точность была ёмче. Сейчас в архитектуре x64 сопроцессор всё перемалывает в 80-битном виде, так что разница только в выводе из сопроцессора и хранении. Получается, язык подтянулся за архитектурой. Я долго думал, как поступить в Обероне-3 с этим. В конце концов, тоже счёл, что SHORT(1.0) это неудобно, и сделал как в Обероне-2: префиксы E и D, вещ. числа в неэкспоненциальном виде короткие, вещ. вычисления по умолчанию короткие, удлинять нужно явно. |
Автор: | GameHunter [ Вторник, 01 Октябрь, 2019 16:51 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Вот такой тестовый модуль: Код: MODULE Test; TYPE Arr = ARRAY 3,4 OF REAL; PROCEDURE Do1 (): POINTER TO Arr; BEGIN RETURN NIL END Do1; END Test. Он компилируется без ошибок, но .c-файла на выходе почему-то нет. (В ББ этот модуль тоже компилируется). Если Arr = INTEGER и процедура возвращает 0, c-файл появляется, и всё работает как должно. |
Автор: | Oleg N. Cher [ Среда, 02 Октябрь, 2019 14:15 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Спасибо за информацию, GameHunter. Исправил. Если интересны подробности, то оригинальный Ofront не разрешает задать результатом процедуры POINTER TO ..., пишет такую ошибку: Код: PROCEDURE Do1 (): {identifier expected} POINTER TO Arr;
|
Страница 4 из 17 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |