OberonCore
https://forum.oberoncore.ru/

Чего не хватает для полноценной реализации?
https://forum.oberoncore.ru/viewtopic.php?f=157&t=6631		 Страница 1 из 1
Автор:  Дмитрий Дагаев [ Понедельник, 29 Июнь, 2020 14:35 ]
Заголовок сообщения:  Чего не хватает для полноценной реализации?
В рамках базовой функциональности (а МультиОберон за точку отсчета брал объем функциональности компилятора BlackBox) практически все важные проблемы решены. Есть компилятор, есть кросс-платформенность, есть 32/64 бит, есть оптимизатор, есть динамическая загрузка, есть диверсификация бэкендов. Все, кроме обработки исключительных ситуаций.
Напомню, что было исследование уважаемого коллеги X512 https://community.blackboxframework.org/viewtopic.php?f=32&t=123#p678, в котором он абсолютно точно обозначил проблему structured exception handling (SEH) и проблему адресной арифметики в различных модулях.

Вторая проблема обусловлена использованием INTEGER адресов в модулях типа Meta, ...
В рамках МультиОберона я не ставил цели переносить всю инфраструктуру BlackBox (Dialog Stores Sequencers Models Services Fonts Meta Converters Ports Views Controllers Properties Mechanisms Containers Printers Printing ...) на 64-бит. В рамках моей необходимости появились 64-битные версии Kernel, например.

Первая проблема существует. Это не означает, что нет обработчика исключений. Есть в модулях Runner свои версии TrapViewer. И они работают
Код:
c:\suok5\test\Mob>Blwe\omlsh run OmtestMkTraps -trap a
*** trap # 21 19CDD8
OmtestMkTraps.RunOpt<OmtestMkTraps.MAIN<OmcCoffLoader.RunModule<OmcCoffLoader.Re
adModule<OmcLoader.LoadMod<OmcLoader.ThisMod<Runner.ThisMod<Kernel.ThisMod<OmcSh
ell.RunModule<OmcShell.Run<OmlSh.Run<Runner.RunModule<Runner.EntryPoint<Runner.S
etRun<OmlSh._body<OmlSh._main

Пример OmtestMkTraps при опции -trap a выдает реакцию на ASSERT(,21)
Обработчик выдает на консоль печать стека. Но:
1.данная информация слишком минималистична;
2.отслеживание стека неэффективно использует ресурсы процессора.
Автор:  Дмитрий Дагаев [ Понедельник, 29 Июнь, 2020 14:40 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
Механизм отслеживания стека взят из OFront. Мне кажется, для C придумать лучше ничего нельзя было.
Возьмем код теста OmtestMkTraps
Код:
void OmtestMkTraps_RunOpt (SHORTCHAR *str, INTEGER str__len)
{
   INTEGER iv, nv;
   struct CHAR_ARRAY *ps = NIL;
   __ENTER("OmtestMkTraps.RunOpt");
   iv = -1;
   nv = 2;
   ps = NIL;
   switch (str[0]) {
      case (SHORTCHAR)'a':
         __ASSERT(iv >= 0, 21);
         break;
      case (SHORTCHAR)'h':
         __HALT(22);
         break;
      case (SHORTCHAR)'z':
         nv = __DIVF(nv, iv + 1);
         break;
      case (SHORTCHAR)'p':
         (ps->data)[0] = (_CHAR)L'A';
         break;
      default:
         (*OLog_String)((_CHAR*)L"-- unknown choice -- ", 22);
         (*OLog_SString)(str, str__len);
         (*OLog_Ln)();
         __ASSERT(iv >= 0, 63);
         break;
   }
   (*OLog_String)((_CHAR*)L"*** unreachable statement! ***", 31);
   (*OLog_Ln)();
   __EXIT;
}

В данной процедуре неэффективное использование реализуется в __ENTER("OmtestMkTraps.RunOpt") на входе и __EXIT на выходе. Эти процедуры обновляют список, соответствующий текущему состоянию стека.

Это используется в Omf OFront, аналогичное решение, за неимением лучшего, я применил и в Oml LLVM бэкенде.
Автор:  Дмитрий Дагаев [ Понедельник, 29 Июнь, 2020 14:48 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
Механизмы обработки для LLVM бэкенда известны:

Но проблема заключается в какой-то там неимоверности реализаций (welcome to C++ world). Поэтому решение пока не сложилось.
А пока оно не сложилось, используются те варианты обработчиков, которые используются.
Автор:  GameHunter [ Понедельник, 06 Июль, 2020 18:11 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
Как на счёт поддержки комплексных чисел?
Автор:  Дмитрий Дагаев [ Понедельник, 06 Июль, 2020 19:57 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
GameHunter писал(а):
Как на счёт поддержки комплексных чисел?

Концептуально МультиОберон состоит из уровней, причем базовый уровень - объем функций BlackBox. Другие уровни будут получаться дополнительными запретами и иногда разрешениями операторами RESTRICT. К такому уровню может относиться и тип COMPLEX со всей арифметикой. Это разумно. Но пока планируется доделать версию 1.0 базового уровня, после чего определить приоритеты в части развития других уровней. В ближайшем будущем комплексных чисел в планах нет.
Автор:  budden [ Среда, 08 Июль, 2020 15:24 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
Не хватает выбора АО в качестве базового уровня функционала.
Автор:  Oleg N. Cher [ Среда, 08 Июль, 2020 21:12 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
В качестве альтернативы внедрению типа COMPLEX предлагаю рассмотреть реализацию математического расширения OberonX (уже реализованного для OP2 в ETH Oberon, так что остаётся только перенести код, подглядывая туда). Тогда можно будет легко сконструировать комплексный тип и операции над ним средствами самого расширения. Да и не только комплексный тип, а и много чего другого. Хотя с точки зрения идеально сбалансированной простоты это всё-таки уже уход в синтаксический сахар.


Я бы хотел реализовать это в Ofront+, может со временем сделаю.
Автор:  Oleg N. Cher [ Среда, 08 Июль, 2020 23:14 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
Нашёл в сети такое обсуждение:


Ниже дурной машинный перевод, но мне так читать полегче, чем на инглише.
Цитата:
>От: BlackBox [mailto:BLACKBOX {([at]}) нигде.ху
>Марк Мартин
> Отправлено: понедельник, 29 июня 2009 г., 1:36 утра
>To: BLACKBOX {([at]})нигде.ху
>Тема: Re: [BLACKBOX] BlackBox 1.6 final version?
>
>> У меня есть вопрос: есть ли шанс, что сложные типы данных, как
> > обсуждаемые в руководстве по дубраве для Оберона-2, будут
>выполненный в черном ящике?
>
>Я занимаюсь математическим программированием, и мне всегда казалось, что это нормально.
>мне кажется, что комплексные числа могут быть определены пользователем с помощью записи
>типы. Хотя если вы хотите использовать операторы со сложными
> типы, возможно, вам действительно следует просить о возможности
>определить операторы? Некоторые языки позволяют вам сделать это,
>включая Зоннон, который, кажется, является Обероном / модулем-2/Паскалем
> * без * философии "держи все просто".

Хорошая точка. Было бы разумно рассмотреть возможность реализации определяемых пользователем операторы как способ поддержки комплекса. Затем пользователь будет иметь добавленную преимущество возможности реализации других распространенных математических операций (например, умножение матрицы).

Единственные недостатки этого подхода, которые я могу придумать, это:

а) сгенерированный код может быть менее эффективным, чем если бы комплекс был нативными данными тип, распознанный компилятором.

б) "умный" программист мог бы изобрести несколько "странных и замечательных" применений
в результате получается неясный / недостижимый код.

Пользовательские операторы также были частью ETH" keep it simple".
Оберон уже некоторое время. Первоначально они были определены как часть
Система Оберон-х в 2000 году.

http://www-old.oberon.ethz.ch/native/co ... ators.html

Особенно интересно то, что ссылка выше также ссылается на источник
код реализации сложной арифметики с использованием определяемого пользователем кода
операторы. Это было написано Аланом Фридом, "гуру" математики Оберона:

http://www-old.oberon.ethz.ch/native/co ... omplex.txt

Однако вам не нужен Oberon-X, чтобы попробовать их, как это сделали эти расширения
также был доступен в стандартной ETH родной системе Oberon с момента выпуска
2.2.3. Версию подключаемого модуля Windows можно загрузить с сайта:

http://www.oberon.ethz.ch/archives/syst ... ve/windows

С уважением,
Крис Берроуз

Ссылки в приведённом письме битые. Файл complex.txt с реализацией комплексной математики с сайта ETH (Complex arithmetic by Alan Freed) недоступен на archive.org, я его разыскиваю. У кого вдруг сохранился — прикрепите, пожалуйста.
Автор:  PSV100 [ Четверг, 09 Июль, 2020 11:46 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
На сегодня через "пользовательские операторы" даже, вроде бы, в Delphi можно удобно внедрить какой-нибудь нужный "big numeric".
В новой Ada собираются вводить нечто вроде перегрузки операторов и для комплексных константных выражений, к примеру, "[1, 2 ,3]" для некоего типа set трансформируется в серию вызовов заданной процедуры, какой-то include например.
Вложение:
complex.txt [5.1 КБ]
Скачиваний: 227
Автор:  budden [ Четверг, 09 Июль, 2020 11:56 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
В Активном Обероне тоже есть определение операций пользователем и там встроено какое-то математическое расширение. Матрицы, что ли. Хотя я не уверен, что мне нравится, как оно там сделано. Ну и в учебниках пишут, что определение операций пользователем снижает надёжность языка. Я думаю, что на самом деле пользоваться можно, просто нужно определять необходимый минимум операций и каждый раз думать, как влияет на надёжность языка конкретно вот это определение в комплексе со всеми остальными уже существующими определениями.

Я воспользовался этой возможностью для типов широких строк:

"https://gitlab.com/budden/jaos/-/blob/яос/source/UCS32.Mod#L126"
Автор:  Борис Рюмшин [ Вторник, 21 Июль, 2020 22:34 ]
Заголовок сообщения:  Re: Чего не хватает для полноценной реализации?
Видимо нам надо попробовать свою кодовую базу загнать на ваш компилятор, чтобы что-то повылезало и можно было обсудить вопрос. Руки чешутся, но на это время выделить надо.
Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/