OberonCore

Сделал для Вас примерчик простой DLL и её вызова:



Только перекачайте Ofront+, я там исправил кое-что, связанное с опцией -d.

Улучшена поддержка Oberon-07 (опция -7): добавлены встроенные функции ASR, LSL и ROR.

• https://github.com/Oleg-N-Cher/OfrontPlus/issues/59

Новости по Ofront+

1. Улучшена совместимость с Компонентным Паскалем в плане базовой разрядности целочисленной арифметики. Как вы знаете, в КП она равняется типу INGEGER, т.е. результат «SHORTINT + SHORTINT» будет иметь тип INTEGER, а в Обероне/Обероне-2 — тип SHORTINT.

• https://github.com/Oleg-N-Cher/OfrontPlus/issues/60

Изменение серьёзное, поэтому всё ещё тестируется. Формирую для него набор специальных тестов.

2. Улучшена совместимость с Обероном-07 в плане проверки наличия RETURN только в конце процедур. Также сделал поддержку, чтобы для процедур, телом которых выступает только RETURN expr, наличие BEGIN было необязательно. Обнаружил, что Ofront разрешает RETURN из секции инициализации модуля. Это нестандартная возможность. Решил не убирать, просто добавил предупреждение. Для Оберона-07 убрал (он всё равно не поддерживает RETURN без expr).

• https://github.com/Oleg-N-Cher/OfrontPlus/commit/f6a5ae82544907dadb2266bf9758f7fa4db8eff9

3. Исправлены ошибки в плане проверок на MIN(INTEGER) вместо MIN(LONGINT).

• https://github.com/Oleg-N-Cher/OfrontPlus/commit/d5faf055904d1da9d238fee1ede49bc4063d3b23

4. Привёл в порядок примеры, теперь должны все собираться нормально. Добавил пример создания и использования динамической библиотеки.

Собрать все примеры: Examples/Bin/build

Для работы сетевого примера нужна библиотека curl, для работы графических — SDL2 и SDL2_image.

Здравствуйте, Олег.

В последнем исправлении, похоже, вы ввели пару новых багов

Вот такой тест последней версией ofront+ не компилируется, выдаёт сообщение об ощибке line 10 pos 9 err 113 incompatible assignment.


Та же самая ошибка получается если x определить как T.INT16. T.INT32 и T.INT64 ошибки не выдают.

В последней версии, в отличие от предпоследней, корректно работает ENTIER - и для 32-битного и для 64-битного результата, и для аргуменота типа REAL и дла LONGREAL. Хорошо бы это не сломалось при исправлении.

С уважением,
GH.

GameHunter, это не баг, это фича. Вы же в режиме -C компилируете? На КП оно так и есть, если не верите — проверьте в BlackBox.

Для INT8 пишите так:Для INT16 так:
Если Вам кажется это странным, то вот смотрите. В Обероне Вы можете написать операцию:
В случае int16 = MIN(SYSTEM.INT16) будет тихое и спокойное искажение результата. То же самое, в случае суммы двух int16 — если сумма превысит ёмкость значений типа, она просто выйдет за его пределы. В КП результат этих операций будет 32-битным, а Вам придётся осмысленно использовать приведение SHORT, притом только в том случае, когда Вы зачем-то хотите использовать в качестве результата более короткую переменную. Это не сильно мешает, потому что для 32- и 64-битных платформ короткая целочисленная арифметика не очень востребована. Так что эта ревизия над Обероном — вполне разумна. А я просто улучшил совместимость Ofront+ с КП.

Если по каким-либо причинам Вам это не подходит, используйте Оберон-2 или Оберон-3. Там результат операций над короткими целыми типами не приводится неявно.

Поделитесь кодом, на котором тестируете ENTIER. Добавлю его в свои тесты.

Вот пример про ENTIER:


Предпоследняя версия Ofront+'а выдаёт ошибки:
line 11 pos 21 err 113 incompatible assignment
line 12 pos 21 err 203 number too large
Последняя версия компилирует без ошибок, как и должно быть.

Где можно посмотреть описание вашего Oberon-3?

В данный момент Вы не найдёте много отличий Оберона-3 от КП. Они будут в отсутствии неявного приведения коротких типов при целочисленных расчётах и в отсутствии параметров IN у процедур (все не-VAR параметры-массивы/записи передаются в О3 по ссылке, но доступны внутри только для чтения). Таким образом, мы избегаем ёмкого копирования, которое неизбежно при передаче структурных параметров по значению (как в Обероне-2 или в КП без IN). То есть, получается, что все не-VAR параметры уже являются в Обероне-3 параметрами IN, но само слово не пишется, в отличие от КП.

Ofront+ для BlackBox ещё поддерживает в режиме -O3 константные массивы и «правильный FOR». Подробнее в моей презентации на Дне Оберона-2018. Я ещё не успел перетащить эти фичи в консольную версию. Так что, как видите, всё в процессе. Пока не вижу особого смысла делать описание. Но, наверное, я и не очень вправе советовать Вам Оберон-3. Просто у него такая же система типов, как у КП (INTEGER 32 бита). А в Обероне и Обероне-2 она традиционная (INTEGER 16 бит).

Может что-то упустил, но мелкое.

Вот такой пример:

Вот вывод:
0.368324136874223
0.36832412523020303
Точность значения c1 ограничена точночтью REAL.
Мне кажется, было бы правильнее константы рассчитывать с точностью LONGREAL, даже если все явные числовые значения имеют одинарную точность, - чтобы при присваивании переменным типа LONGREAL не происходила потеря точности.

Не будем забывать, что более короткий четырёхбайтовый тип REAL был во времена Оберона/Оберона-2 более штатным и широко используемым. Никто же не мешает явно при задании константы указать, что она должна вычисляться с двойной точностью. Хотя бы даже вот так:

В КП так оно и есть, вещественные константы вычисляются с точностью восьмибайтового REAL, а совместимость по присвоению литерала типа REAL в SHORTREAL смягчена. В режиме -C я тоже так сделаю. Сейчас присвоить длинный вещественный литерал короткой переменной без явного SHORT нельзя (как в Обероне), а должно быть можно (как в КП). В КП поэтому даже нет разделения на короткие и длинные вещественные литералы (2.0E0 и 2.0D0).

Кстати, сорри, я не указал, что это быо Оберон-2.

> Никто же не мешает...
Мешает. Раз константы в обероне нетипизированы (явно), их обработка и применение должны быть бескомпромиссными - нужно же их использовать для переменных разных типов.

Опять Oberon-2.


При компиляции выдаётся ошибка
line 14 pos 10 err 126 this expression cannot be a type or a procedure
Вроде бы такие сравнения должны быть возможными?
И ещё вопрос: можно ли при помози модуля SYSTEM узнать адрес процедуры? SYSTEM.ADS(pp) не работает.

Константы в OP2 всё же имеют скрытый тип, который берётся неявно, из контекста. Можно, например: CONST LongZero = LONG(0);

И это будет именно 0 удлинённого типа (для КП — типа LONGINT). Что, например, важно при операции типа SYSTEM.PUT(adr, LongZero);

Я думаю, наследие Оберона/Оберона-2 нам нужно брать как оно есть, а не пытаться его исправлять. Оставим Оберон истории, а использовать будем КП. А в целом — я с Вами полностью согласен.

Да, странно. А вот так работает:
Я ещё не придумал, что с этим лучше сделать. Надо подумать.

Так было у Темпла изначально. Но непорядок, так что вот исправление:

• https://github.com/Oleg-N-Cher/OfrontPlus/issues/62

Теперь такой код компилируется и работает:

Результаты некоторого исследования сравнений процедур. Я конечно понял куда надо впилиться, чтобы разрешить нужные сравнения. Но сразу возникает несколько вопросов.

Во-первых, BlackBox тоже не поддерживает такое сравнение:
Хотя обходным путём через переменные процедурного типа, которым заранее присвоены нужные процедуры, такие сравнения возможны. Мне интересно, что скажут наши корифеи. Нужно ли внедрить эту фичу в BlackBox?

Во-вторых, если разрешить сравнения процедур, то только операциями = и #, но не <, <=, > и >=, которые не будут иметь смысла.

В-третьих, тогда сам собой напрашивается "процедурный CASE":
Конечно необходимые изменения для поддержки такого кода сделать можно, но, опять же, насколько это будет идти вразрез с сообщением о языке (Оберон и КП)? Опять же, интересно услышать мнения. Если данную фичу удастся обосновать и протащить в BlackBox, тогда я её точно реализую и в Ofront'е+.

Реализовал предложенную Вами стратегию для КП и Оберона-3. Уже извините, но Оберон и Оберон-2 трогать не буду.

• https://github.com/Oleg-N-Cher/OfrontPlus/commit/0da4bbe74d520fe17a9594e8d46f9d534295ba8e

Кроме того, для КП и Оберона-3 убрал возможность описывать двойные вещественные суффикcом D (1.3D8). Вот как можно описывать константы с неявным коротким вещественным типом:

Сделал реализацию прямого сравнения процедурной переменной с процедурой. Две процедуры друг с другом при этом сравнивать нельзя, и процедуру с NIL тоже нельзя.

GameHunter, тестируйте.

• https://github.com/Oleg-N-Cher/OfrontPlus/issues/63

"Процедурный CASE" у нас, пожалуй, всё-таки не состоится, потому что адреса процедур на уровне Си — это не константы. Здесь предвижу сложности, так что это направление ковырять не буду.

Адаптировал для Ofront+ утилиту Александра Ильина ImportGraph.

Отличия от оригинальной утилиты:

• понимает структуру, сложившуюся в Ofront+ (исходники в /Mod, библиотеки в /Lib/Mod); в то же время, осталась возможность понимать иерархию подсистем BlackBox и формат .odc;

• имя модуля берётся не из входного параметра, а непосредственно из текста самого модуля. Это позволяет, например, хранить модуль Platform в файле Platform.Windows.Mod (при наличии разных его реализаций); не забудьте в этом случае указать это имя входным аргументом, чтобы утилита поняла в каком файле ей искать модуль;

• работает под Linux, также есть возможность собрать 64-битную версию;

• ключик командной строки -r для сокращённого вывода, при котором не показывается часть зависимостей. Например, для (A->B, B->C, A->C) зависимость A->C не показывается.

Пример. Полная структура Ofront+:



Сокращённая структура:

Улучшен концепт "правильного" FOR: теперь переменная цикла FOR должна иметь максимальную локальность, т.е. быть не экспортирована и объявлена в той же процедуре, что и цикл. Напоминаю, что "правильный" FOR в Ofront+ можно включить для любого Оберон-диалекта ключиком -f (а в режиме -3 он уже активен).

• http://zx.oberon2.ru/forum/viewtopic.php?f=32&t=459&p=3413#p3412

А есть возможность "ещё более правильную" переменную цикла опредлять?
Это - которая только в теле цикла видима.

Это будет беспрецендентно для Оберонов А какой предлагается синтаксис? Как-то так?

P.S. В Eberon'е сделано так:

В Active Oberon есть ranges.

(
Или "как в" ADA.
)