OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 11 Август, 2020 10:49

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 16 ] 
Автор Сообщение
СообщениеДобавлено: Суббота, 25 Апрель, 2020 17:57 
Аватара пользователя

Зарегистрирован: Среда, 22 Апрель, 2015 23:51
Сообщения: 191
Откуда: г. Рига, Латвийская ССР
При разработке компилятора встал вопрос, можно ли написать такое:
Код:
PROCEDURE DWord(n: INTEGER);
...
DWord(90909090H)

при том, что INTEGER имеет разрядность 32 бита.

Некоторые компиляторы выдают ошибку, тогда как в компиляторе Project Oberon (2013) всё работает. Это удобно, т. к. назначение DWord — записать в файл 4 байта, указанные в виде числа INTEGER (порядок байтов от младшего к старшему). Реализована, она, кстати, так (модуль Generator):
Код:
PROCEDURE DWord(n: INTEGER);
BEGIN
  Files.Write(r, CHR(n MOD 100H));
  Files.Write(r, CHR(n DIV 100H MOD 100H));
  Files.Write(r, CHR(n DIV 10000H MOD 100H));
  Files.Write(r, CHR(n DIV 1000000H))
END DWord;


В сообщении о языке Оберон не указано, что литерал 90909090H следует рассматривать как ошибочную запись числа при 32-битовом INTEGER.

В опыте использован онлайн-эмулятор RISC.


Вложения:
Комментарий к файлу: Целые числа в Project Oberon (2013)
32bit.png
32bit.png [ 23.93 КБ | Просмотров: 955 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 26 Апрель, 2020 01:01 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
Артур, в Project Oberon и в Обероне-07 только один целочисленный тип для операций — это INTEGER. BYTE просто промежуточная форма для хранения значений. Поэтому ограничивать специально ёмкость беззнаковых шестнадцатеричных литералов и не стали, неявно приводя их к знаковым. Здесь плохо то, что знак получается скрытым.

Если есть другие целые типы (LONGINT, например), то всё несколько усложняется. Я бы вынес знак из маски шестнадцатеричного числа и писал бы DWord(90909090H - 100000000H). Это будет хорошо работать в рамках модели с несколькими целочисленными типами.

С интересом выслушаю, почему знак в шестнадцатеричных литералах должен быть задан разрядом. Но тебе здесь не подскажут никакого разумного ответа, зачем это надо оставить. Разве что взять заклеить себе жвачкой глаза и сделать вид, что 64-битных чисел не существует. Или сделать вид, что при существовании 64-битных чисел не существует 32-битных. Короче, молиться богу Оберона-07.

P.S. Ответ "потому, что иначе самое большое шестнадцатеричное число 0FFFFFFFFFFFFFFFFH и не задашь литералом без знака" не прокатывает. Это проблема, но разумного решения у неё нет. Только в виде полумер: всё равно разрешить. А просто потому что потому.

И ещё: почему задавать знак разрядом в десятичных литералах нельзя:
Код:
CONST a = 4294967295; (* где подразумеваем, что это 32-битная константа со знаком *)
, что правильно, а в шестнадцатеричных должно быть можно? Где здесь логика?

Проблема несколько смягчается, если при задании константы можно задавать и её тип. Но это усложнение и тоже полумера. Раз мы отказались от беззнаковых типов вместе с переходом на Обероны, то остаётся только этому радоваться. Упрощение жеж ;-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 26 Апрель, 2020 06:33 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2810
Шестнадцатеричная запись - это для каких-то адресов надо, например, для системных вещей. Так что это скорее внутренняя тема на уровне SYSTEM, где шаг влево вправо чреват столкновением с особенностями реализации компилятора. И надо вдумчиво понимать эти особенности. В нормальных прикладных алгоритмах не стоит использовать шестнадцатеричные, по моему скромному мнению...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 26 Апрель, 2020 07:32 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
Если у нас не один целочисленный тип, то всё равно нужно как-то обозначать разрядность шестнадцатеричного числа, будь оно со знаком или без. Если не вводить для этого специальные меры типа постфикса L, а оставить всё в кристальной простоте, то приравнивать -1H к 0FFFFFFFFH всё равно нельзя.

Если мы ни о чём, т.е. у нас в сферическом вакууме присутствует только один целый тип, тогда проблем вообще нет, можно лепить так, как в Project Oberon. Уверен, если бы у Артура не было сомнений, то он и тему открывать бы не стал. Так что предлагаю рассмотреть именно случай с несколькими целыми типами.

Применимость же шестнадцатеричных чисел не всегда связана с системщиной.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 26 Апрель, 2020 12:08 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
Dave Brown писал(а):
Как в VOC, так и в Oberon 2013 целочисленные литералы анализируются в анализаторе символов (VOC: OPS.Mod или 2013: ORS.MOD) и хранятся в таблице символов в виде целочисленных значений со знаком.

Позже, во время компиляции выражений, их размер определяется величиной их целочисленного значения со знаком.

Разница между Oberon 2013 и VOC - это самый большой целочисленный тип, который составляет 32 бита в Oberon 2013 и 64 бита в VOC.

Специальная обработка, которая позволяет шестнадцатеричному литералу с верхним разрядным набором рассматриваться как знаковое значение, происходит в то время, когда литерал анализируется как символ, независимо от того, в каком контексте он используется. (Рассмотрим, например, 'CONST mask = 90909090H' - анализ CONST не знает, будет ли эта константа использоваться в 64-битном, 32-битном, 16-битном или другом контексте.)

VOC и Oberon 2013 допускают поведение синтаксического анализа верхнего набора битов шестнадцатеричного специального случая, разница заключается в размере целочисленного литерала.

Таким образом, VOC принимает myint64 := 909090909090909090H, поскольку 909090909090909090H анализируется как отрицательное 64-битное целое число со знаком.

Но VOC не принимает myint32 := 90909090H, потому что 9090909090H анализируется как положительное 64-битное целое число со знаком.

VOC не имеет возможности распознать 90909090H как отрицательное 32-разрядное целое число со знаком.

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

- Обратите внимание, что это не зависит от настройки совместимости VOC -Ox: это устанавливает целочисленный размер по умолчанию, а не целочисленный размер литерала - целочисленные литералы всегда поддерживают самый большой доступный целочисленный размер, который является SYSTEM.INT64, он же HUGEINT.)

-- Дейв


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 29 Апрель, 2020 06:44 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
Подрезюмируя сказанное. В итоге всё сводится к вопросу: литерал 0FFFFFFFFH считать 64-битным без знака или 32-битным со знаком? У нас три решения:

    1. Считать 64-битным. Если Артуру не нравится писать
    Код:
    DWord(90909090H - 100000000H);
    , то Ofront+ предлагает ещё такой вариант:
    Код:
    DWord(SYSTEM.VAL(INTEGER, 90909090H));
    , вполне в духе Оберон-парадигмы. И системность не должна смущать — у нас же шестнадцатеричные литералы юзаются для системщины. Так что, Артур, я предлагаю в твоём компиляторе поступить именно так.

    2. Считать 32-битным. А для 64-битного использовать постфикс типа 0FFFFFFFFL, как в КП. Ofront+ тоже реализует этот вариант (в режиме -C).

    3. Сделать вид, что у нас все целочисленные литералы одного размера. В этом случае знак шестнадцатеричного литерала задавать разрядом. Это то, что реализовано в большинстве компиляторов Оберона-07, что оправдывается отсутствием в них целочисленной арифметики разной битности.

Что я упустил?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 29 Апрель, 2020 11:02 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 151
Откуда: Russia
Oleg N. Cher писал(а):
Что я упустил?

4) Сделать типизированные константы


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 29 Апрель, 2020 20:03 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
Sergej Durmanov писал(а):
4) Сделать типизированные константы
Ну, на самом деле в Ofront'е+ можно описать системное приведение при определении константы:
Код:
CONST dword = SYSTEM.VAL(INTEGER, 90909090H);

Я специально для подобных случаев реализовал. В CPfront, BlackBox, voc и Ofront такой фичи нет.

Если Вы предлагаете INTEGER(90909090H) как в AO, то это уже было в Turbo Pascal. Тогда надо разрешить такое же (заметьте, несистемное) приведение и в выражениях — и понеслось.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 01 Май, 2020 09:53 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 248
Откуда: Austria, Bruck
Иван Денисов писал(а):
Шестнадцатеричная запись - это для каких-то адресов надо, например, для системных вещей. Так что это скорее внутренняя тема на уровне SYSTEM, где шаг влево вправо чреват столкновением с особенностями реализации компилятора. И надо вдумчиво понимать эти особенности. В нормальных прикладных алгоритмах не стоит использовать шестнадцатеричные, по моему скромному мнению...


В таком случае было бы логично сделать разбор 16-тиричных числел подключаемым при импорте модуля SYSTEM.

Кроме того, как быть при реализации прикладных алгоритмов где требуется манипулирование битами, а типа SET недостаточно (более 32 бит)?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 01 Май, 2020 19:35 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 151
Откуда: Russia
Oleg N. Cher писал(а):
и понеслось.

Что куда понеслось? Речь-то идёт о константных выражениях в виде литералов и т.д. Нет никакой надобности распространять это на всё и вся.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Май, 2020 16:33 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
Sergej Durmanov писал(а):
Речь-то идёт о константных выражениях в виде литералов и т.д. Нет никакой надобности распространять это на всё и вся.
Из единообразности: если предлагается для констант CONST a=INTEGER(123);
Тогда почему не разрешить это и в выражениях?

Кстати, вот так будет даже более в духе Оберона-2/КП:
Код:
CONST a = 123(INTEGER);

P.S. Желание защитить решения, принятые в A2, понимаю, но в других Оберонах этого нет и, надеюсь, не будет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Май, 2020 21:25 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 248
Откуда: Austria, Bruck
Oleg N. Cher писал(а):
Из единообразности: если предлагается для констант CONST a=INTEGER(123);
Тогда почему не разрешить это и в выражениях?

Олег, а Оберон-дзен вроде и направляет в сторону использования сущностей явно. Если мы используем константу в обычном выражении, то мы можем однозначно задать ее тип. И вроде парсер константных выражений тот же что и обычных.
А синтаксис - дело вторичное.

[Offtop]
Я за типизированные константы, но. Если мы позволяем быть константам элементарных типов, тогда, чтобы сохранить целостность, должны быть определяемы и структурные константы: массивы и записи. А вот с последними и совсем не ясно как и что. (Возможно я глубоко ошибаюсь)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Май, 2020 11:50 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
Так правильно. Оберон и использует сущность "целое число" явно, что понятно по контексту. Это "короткое", "более короткое", "длинное" и "более длинное" целые числа уже некрасиво выпирают из абстракции, являя собой дань решению "грязных проблем системного программирования", программирования микроконтроллеров, экономии памяти и прочих подобных задач.

Как мы видим, Оберон-07 для целых чисел имеет только типы BYTE (который ввёл Вирт как компромисс, до этого для представления байтов усиленно использовался CHAR) и INTEGER. В Обероне-07 проблема типизированных целых констант вообще не актуальна. Остальных коротких и длинных грязных целочисленных типов нет. И SHORT/LONG не требуются. Мне этот подход, как вы наверное поняли, не по душе. Поэтому я и считаю Оберон-07 узкоспециализированным языком.

В Ofront'е+ реализованы константные массивы (в режиме -3). Насчёт записей мы тоже думали, но посомневались. Я уверен, что Вирт посчитал эту функциональность не настолько важной и положил её на алтарь простоты Оккама.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Май, 2020 12:19 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 275
Oleg N. Cher писал(а):
В Ofront'е+ реализованы константные массивы (в режиме -3).

Интересно.
Вот есть приложение Babel, он генерирует конечный автомат по грамматике и потом этот конечный автомат записывает в виде массива целых. Грамматика КП затягивает, если мне не изменяет память, на несколько сот килобайт. Поскольку массив-констант нет, это записывается в модуле в виде a[i] := 5971630; Компилятор Dev справляется на раз, но в памяти, получается, дважды эта информация записана, т.е. чтобы модуль загрузить, нужно вдвое больше памяти.
А справится ваш компилятор с полумегабайтным массивом-константой?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Май, 2020 15:26 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 248
Откуда: Austria, Bruck
Oleg N. Cher писал(а):
Так правильно. Оберон и использует сущность "целое число" явно, что понятно по контексту. Это "короткое", "более короткое", "длинное" и "более длинное" целые числа уже некрасиво выпирают из абстракции, являя собой дань решению "грязных проблем системного программирования", программирования микроконтроллеров, экономии памяти и прочих подобных задач.
Я бы понял такой подход в языках инженерной обработки (Matlab, R, Алмир, ...).

Oleg N. Cher писал(а):
Поэтому я и считаю Оберон-07 узкоспециализированным языком.
Да, мне кажется также, что Вирт уже создает язык(и) под задачу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Май, 2020 16:28 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 406
Откуда: Украина, Днепропетровская обл.
adimetrius писал(а):
А справится ваш компилятор с полумегабайтным массивом-константой?
Должен справиться. Просто съест под данные массива большой кусок памяти при компиляции. Потом в конце освободит.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 16 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2020, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB