OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 11:36

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




Начать новую тему Ответить на тему  [ Сообщений: 330 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 17  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 14 Февраль, 2019 03:51 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
Сделал для Вас примерчик простой DLL и её вызова:

Код:
MODULE MyDLL; IMPORT Console;

PROCEDURE Plus* (a, b: INTEGER): INTEGER;
BEGIN
   RETURN a + b
END Plus;

BEGIN
   Console.WriteStr("MyDLL initialized"); Console.WriteLn
END MyDLL.

Код:
MODULE MyDLLuse;
IMPORT MyDLL, Console;

BEGIN
   Console.WriteStr("4 + 3 = "); Console.WriteInt(MyDLL.Plus(4, 3))
END MyDLLuse.

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


Вложения:
MyDLL.png
MyDLL.png [ 38.33 КБ | Просмотров: 6762 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Февраль, 2019 16:06 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
Улучшена поддержка Oberon-07 (опция -7): добавлены встроенные функции ASR, LSL и ROR.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Март, 2019 01:39 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
Новости по Ofront+

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


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

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


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


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

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

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


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

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Здравствуйте, Олег.

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

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

Код:
MODULE TestAssignment;

IMPORT
  T:=Types;

VAR
  x:T.INT8;

BEGIN
  x:=x+x;
END TestAssignment.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 04 Апрель, 2019 15:04 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
GameHunter, это не баг, это фича. Вы же в режиме -C компилируете? На КП оно так и есть, если не верите — проверьте в BlackBox.

Для INT8 пишите так:
Код:
x:=SHORT(SHORT(x+x)); (* В КП результат целочисленных операций над BYTE всегда 32-битный *)
Для INT16 так:
Код:
x:=SHORT(x+x); (* Результат целочисленных операций над SHORTINT тоже всегда 32-битный *)

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 05 Апрель, 2019 22:56 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Вот пример про ENTIER:

Код:
MODULE Ex;

IMPORT
  T:=Types;

VAR
  i32:T.INT32;
  i64:T.INT64;

BEGIN
  i32:=ENTIER(1.0E5);
  i64:=ENTIER(1.0D11);
END Ex.

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

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


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
В данный момент Вы не найдёте много отличий Оберона-3 от КП. Они будут в отсутствии неявного приведения коротких типов при целочисленных расчётах и в отсутствии параметров IN у процедур (все не-VAR параметры-массивы/записи передаются в О3 по ссылке, но доступны внутри только для чтения). Таким образом, мы избегаем ёмкого копирования, которое неизбежно при передаче структурных параметров по значению (как в Обероне-2 или в КП без IN). То есть, получается, что все не-VAR параметры уже являются в Обероне-3 параметрами IN, но само слово не пишется, в отличие от КП.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 12:37 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Вот такой пример:
Код:
MODULE Ex;

IMPORT
  C:=Console, R:=Reals;

CONST
  c1 = 2.0E0/5.43E0;
  c2 = 2.0D0/5.43D0;

PROCEDURE OutReal * (x:LONGREAL);
  VAR
    s:ARRAY 100 OF CHAR;
  BEGIN
    R.LRealToString(x,s);
    C.String(s); C.Ln; C.Flush;
  END OutReal;

BEGIN
  OutReal(c1);
  OutReal(c2);
END Ex.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 14:48 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
Не будем забывать, что более короткий четырёхбайтовый тип REAL был во времена Оберона/Оберона-2 более штатным и широко используемым. Никто же не мешает явно при задании константы указать, что она должна вычисляться с двойной точностью. Хотя бы даже вот так:
Код:
CONST
  c1 = LONG(2.0E0) / LONG(5.43E0);

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 15:45 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Кстати, сорри, я не указал, что это быо Оберон-2.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 15:49 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Опять Oberon-2.

Код:
MODULE Ex;

TYPE
  T = PROCEDURE;

VAR
  p:T;

PROCEDURE pp ();
  BEGIN
  END pp;

BEGIN
  IF p=pp THEN
  END;
END Ex.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 16:57 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
GameHunter писал(а):
Раз константы в обероне нетипизированы (явно), их обработка и применение должны быть бескомпромиссными - нужно же их использовать для переменных разных типов.
Константы в OP2 всё же имеют скрытый тип, который берётся неявно, из контекста. Можно, например: CONST LongZero = LONG(0);

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

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

GameHunter писал(а):
line 14 pos 10 err 126 this expression cannot be a type or a procedure
Вроде бы такие сравнения должны быть возможными?
Да, странно. А вот так работает:
Код:
MODULE TestProc;

TYPE
  T = PROCEDURE;

VAR
  p, p2: T;

PROCEDURE pp ();
  BEGIN
  END pp;

BEGIN
  p2 := pp;
  IF p = p2 THEN
  END;
END TestProc.
Я ещё не придумал, что с этим лучше сделать. Надо подумать.

GameHunter писал(а):
И ещё вопрос: можно ли при помози модуля SYSTEM узнать адрес процедуры? SYSTEM.ADS(pp) не работает.
Так было у Темпла изначально. Но непорядок, так что вот исправление:


Теперь такой код компилируется и работает:
Код:
MODULE TestProc; IMPORT SYSTEM, Console;

PROCEDURE pp; END pp;

BEGIN
  Console.LongInt( SYSTEM.ADR(pp), 0 ); Console.Ln
END TestProc.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 15 Апрель, 2019 13:59 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
Результаты некоторого исследования сравнений процедур. Я конечно понял куда надо впилиться, чтобы разрешить нужные сравнения. Но сразу возникает несколько вопросов.

Во-первых, BlackBox тоже не поддерживает такое сравнение:
Код:
TYPE T = PROCEDURE (a, b: BOOLEAN);
VAR p: T;
PROCEDURE pp (a, b: BOOLEAN); END pp;

BEGIN
  IF pp = p THEN ... END
END;
Хотя обходным путём через переменные процедурного типа, которым заранее присвоены нужные процедуры, такие сравнения возможны. Мне интересно, что скажут наши корифеи. Нужно ли внедрить эту фичу в BlackBox?

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

В-третьих, тогда сам собой напрашивается "процедурный CASE":
Код:
TYPE T = PROCEDURE;

PROCEDURE pp1; END pp1;
PROCEDURE pp2; END pp2;
PROCEDURE pp3; END pp3;

PROCEDURE Case (proc: T);
BEGIN
  CASE proc OF
    pp1: ...
    pp2: ...
    pp3: ...
  END
END Case;
Конечно необходимые изменения для поддержки такого кода сделать можно, но, опять же, насколько это будет идти вразрез с сообщением о языке (Оберон и КП)? Опять же, интересно услышать мнения. Если данную фичу удастся обосновать и протащить в BlackBox, тогда я её точно реализую и в Ofront'е+.


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
GameHunter писал(а):
Мне кажется, было бы правильнее константы рассчитывать с точностью LONGREAL, даже если все явные числовые значения имеют одинарную точность, - чтобы при присваивании переменным типа LONGREAL не происходила потеря точности.
Реализовал предложенную Вами стратегию для КП и Оберона-3. Уже извините, но Оберон и Оберон-2 трогать не буду.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 16 Апрель, 2019 21:09 
Аватара пользователя

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

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Май, 2019 20:48 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
Адаптировал для Ofront+ утилиту Александра Ильина ImportGraph.

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

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

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

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

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

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

Изображение

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

Изображение


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Июнь, 2019 00:03 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
Улучшен концепт "правильного" FOR: теперь переменная цикла FOR должна иметь максимальную локальность, т.е. быть не экспортирована и объявлена в той же процедуре, что и цикл. Напоминаю, что "правильный" FOR в Ofront+ можно включить для любого Оберон-диалекта ключиком -f (а в режиме -3 он уже активен).



Вложения:
Ofront+.png
Ofront+.png [ 54.8 КБ | Просмотров: 6037 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Июнь, 2019 02:11 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Oleg N. Cher писал(а):
Улучшен концепт "правильного" FOR: теперь переменная цикла FOR должна иметь максимальную локальность, т.е. быть не экспортирована и объявлена в той же процедуре, что и цикл.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 16 Июнь, 2019 09:39 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 519
Откуда: Украина, Днепропетровская обл.
Это будет беспрецендентно для Оберонов ;-) А какой предлагается синтаксис? Как-то так?
Код:
FOR i: INTEGER = 1 TO 10 DO
  ...
END

P.S. В Eberon'е сделано так:
Код:
FOR i <- 0 TO 10 DO
  ...
END


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 16 Июнь, 2019 12:13 

Зарегистрирован: Пятница, 11 Январь, 2019 21:33
Сообщения: 88
В Active Oberon есть ranges.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 330 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 17  След.

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


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

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


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

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