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 писал(а):
Наличие у товарищей таких идиосинкразий намекает на наличие и других особенностей.
Ещё, лягушку можно варить постепенно. Правда, непонятно, кто кого сварит в конце концов :lol: .

Автор:  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

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

Сегодня обновилась подсистема Мастер. Добавлена поддержка ключевых слов и типов в нижнем регистре: включается, если модуль начинается с module. Пишу здесь, т.к. это может представлять интерес для Оберона-3, который пока поддержан только в Ofront+.



Вложения:
Master.png
Master.png [ 23.04 КБ | Просмотров: 5565 ]

Автор:  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 и увидели бы, что он выдаёт ту же ошибку несовместимого присваивания. Помните, Вы меня убеждали, что вещественные константы должны по умолчанию иметь самую высокую точность? Ну так вот, это оно и есть. :D

В Компонентном Паскале для присваивания 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/