OberonCore
https://forum.oberoncore.ru/

Оберон-07: вопросы реализации
https://forum.oberoncore.ru/viewtopic.php?f=115&t=6352
Страница 1 из 5

Автор:  Oleg N. Cher [ Вторник, 12 Февраль, 2019 15:34 ]
Заголовок сообщения:  Оберон-07: вопросы реализации

Сейчас делаю в Ofront+ поддержку Оберона-07 и возник такой момент. Меня удивило применение ORD к аргументу типа REAL. Что можно сказать по этому поводу?

В описании языка аргументом ORD могут быть типы CHAR, BOOLEAN и SET (кстати, тоже несимметрично: ORD(set) есть, а обратного BITS(int) нету). Есть такое объяснение: мэтру быстренько понадобился такой хак и он, не мудрствуя лукаво, свалил это на ORD, чтобы лишний раз не дёргать SYSTEM.

Я и правда не понимаю, что должен возвращать ORD(real). Если это скрытое округление или отбрасывание дробной части, тогда это не так уж и красиво. А если это замаскированный SYSTEM.VAL(INTEGER, real), то ещё хуже, ибо "числа это не биты" (Н. Вирт).

Ссылка на код (см. процедуру WriteReal): https://en.wikibooks.org/wiki/Oberon/V5/Texts.Mod

Делать ли поддержку ORD(real) в Ofront+? Плюсом будет совместимость с имеющим хождение кодом. Минусом будет нестандартное расширение языка. Компромиссом вижу: разрешить, но с предупреждением.

Автор:  Sergej Durmanov [ Вторник, 12 Февраль, 2019 18:40 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Семантика ровно такая же, как и с другими типами - позволяет трактовать как целое.

Автор:  Oleg N. Cher [ Вторник, 12 Февраль, 2019 22:56 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Не, вопрос был про: целое как? С отброшенной дробной частью? Округленное? Абсолютное двоичное приведение (маппинг) REAL к INTEGER?

Ещё вопрос: где можно тестировать мои эксперименты с Обероном-07? (самую свежую ревизию надо). Нужен компилятор или транслятор, который я могу запустить не на ПЛИСе, а на обычной ОС.

Автор:  Борис Рюмшин [ Вторник, 12 Февраль, 2019 23:22 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Oleg N. Cher писал(а):
Нужен компилятор или транслятор, который я могу запустить не на ПЛИСе, а на обычной ОС.

Из того, что Вирт поддерживает, на http://www.projectoberon.com/ есть эмулятор на Си.

Автор:  Kemet [ Среда, 13 Февраль, 2019 06:20 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Oleg N. Cher писал(а):
Не, вопрос был про: целое как? С отброшенной дробной частью? Округленное? Абсолютное двоичное приведение (маппинг) REAL к INTEGER?

SYSTEM.VAL

И это... в Прожект Оберон совсем другой Оберон07, в репорте не описанный.
В общем случае, Оберон 07 не нужен, это язык заточенный под конкретный проект - замкнутую учебную экосистему, которая включает: язык описания аппаратуры( LoLa ) ->компилятор->реализация аппаратуры( RISC5 )-> язык программирования системной и прикладной логики ( Oberon07 )->компилятор->операционная система. Это, безусловно, бесценный проект. Но, как только мы выходим за рамки экосистемы, вынуждены заниматься адаптацией Оберона07. Этих Оберонов07 только от самого Вирта - целый космозоопарк.
А есть ещё проект Minos, в котором тоже свой особенный Оберон07.
Можно ли было сделать универсальный полноценный язык общего назначения? Безусловно, да. Но в 16 страниц репорта это бы не уместилось, пришлось ещё бы пару-тройку добавить. И реализовать. И, самое, главное, пользовать реализованное, иначе возникнет резонный вопрос, а зачем вот эти свистелки? Они же лишние! Можно без них жить!

Автор:  albobin [ Среда, 13 Февраль, 2019 09:10 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Oleg N. Cher писал(а):
Не, вопрос был про: целое как? С отброшенной дробной частью? Округленное? Абсолютное двоичное приведение (маппинг) REAL к INTEGER?

Смею предположить, что последнее. Реализация ORD скорее всего типа как UNION в иных языках. А интерпретировать ORD проще всего как порядковый номер в упорядоченном ряду всех возможных значений. Кстати, судя по коду, в старшем байте упакованного REAL лежит порядок числа. Да, еще, в самой книжке Project Oberon, Вирт в той части, касаемой вывода REAL числа, упоминает UNPK для извлечения порядка. Наверное, позже "оптимизировал" алгоритм, применив ORD.

Автор:  Alexander Shiryaev [ Среда, 13 Февраль, 2019 10:56 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

ORP.StandFunc (*ORD*):
Код:
...
ELSIF fct = 4 THEN (*ORD*)
        IF x.type.form <= ORB.Proc THEN ORG.Ord(x)
        ELSIF (x.type.form = ORB.String) & (x.b = 2) THEN ORG.StrToChar(x)
        ELSE ORS.Mark("bad type")
        END
...

ORB (* form values*):
Код:
      Byte* = 1; Bool* = 2; Char* = 3; Int* = 4; Real* = 5; Set* = 6;
      Pointer* = 7; NilTyp* = 8; NoTyp* = 9; Proc* = 10;
      String* = 11; Array* = 12; Record* = 13;

ORG.Ord:
Код:
PROCEDURE Ord*(VAR x: Item);
BEGIN
  IF x.mode IN {ORB.Var, ORB.Par, RegI, Cond} THEN load(x) END
END Ord;

Автор:  Trurl [ Среда, 13 Февраль, 2019 11:16 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

О, даже от процедуры можно ORD вычислить. :o

Автор:  Oleg N. Cher [ Четверг, 14 Февраль, 2019 20:50 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Спасибо всем за ответы.

После некоторого обдумывания решил не делать ORD для REAL. Может это и лихой трюк — использовать ORD(real) вместо SYSTEM.VAL(INTEGER, real) и, тем самым, избавиться от SYSTEM, но много смысла в таком декоре я не вижу. И поощрять такой стиль нам не следует. Ещё меньше смысла в ORD(Procedure). Что здесь вообще возвращается? Адрес процедуры? Так это системная вещь, её легко получить через SYSTEM.ADR.

Ещё вопрос. В Обероне-07 есть встроенные функции ASR (арифметический сдвиг вправо), LSL (логический сдвиг влево) и ROR (циклический сдвиг вправо), хотя логического сдвига вправо и циклического сдвига влево нет. Или Вирт решил, что такие сдвиги и не нужны. Может от бедности? Сложно сказать. Я вообще не понимаю, зачем понадобилось выносить логический и циклический сдвиги из SYSTEM в язык. Это же работа с битами.

Все имеющиеся операции сдвига имеют второй аргумент, указывающий на сколько битов сдвигать. В описании языка нигде не говорится, что будет, если он будет отрицательным. Подразумевается ли здесь сдвиг в другую сторону? Конечно это было бы красиво, хотя и вразрез с описанием языка, так сказать, неопределённое поведение.

Как бы вы посоветовали мне поступить? Реализовать сдвиги в обратную сторону? Ловить ошибку при отрицательном аргументе? Как с этим обстоят дела в различных реализациях Оберона-07?

Автор:  Борис Рюмшин [ Четверг, 14 Февраль, 2019 23:11 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Oleg N. Cher писал(а):
Ещё вопрос. В Обероне-07 есть встроенные функции ASR (арифметический сдвиг вправо), LSL (логический сдвиг влево) и ROR (циклический сдвиг вправо), хотя логического сдвига вправо и циклического сдвига влево нет. Или Вирт решил, что такие сдвиги и не нужны. Может от бедности? Сложно сказать. Я вообще не понимаю, зачем понадобилось выносить логический и циклический сдвиги из SYSTEM в язык. Это же работа с битами.

Могу больше сказать, их и самом виртовском процессоре RISC-5 нет. А вынесены они, потому что нужны. Криптография та же, к примеру.

Автор:  Пётр Кушнир [ Пятница, 15 Февраль, 2019 00:39 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Все остальные операции из набора сдвигов не зависят от знака (и от формата обратного дополнения) и могут быть получены простыми арифметическими действиями, кажется так. Вирт это дело очень любит, умножил/поделил на 01000H вот и сдвинул туда/сюда. Пришлось мне бороться с этим при реализации компилера под всякие архитектуры странные.

Автор:  Oleg N. Cher [ Пятница, 15 Февраль, 2019 00:50 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Борис Рюмшин писал(а):
А вынесены они, потому что нужны. Криптография та же, к примеру.
А почему они для числового типа INTEGER, а не для битового SET? Тем более, что в Обероне-07 не поощряется конвертация INTEGER в SET. А битовое представление INTEGER может отличаться на разных процессорах. Вот и сломается "железный" портабельный код.

Я согласен, нужны. Но это брешь в подходе "числа — не биты". Сначала выдвинут красивый тезис, потом он же сломан. Ну, так понадобилось.

Всё-таки Оберон-07 сыроват. Неудивительно, что реализаторы его расширяют вдоль и поперёк.

Автор:  Comdiv [ Пятница, 15 Февраль, 2019 01:16 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

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

Автор:  Илья Ермаков [ Пятница, 15 Февраль, 2019 09:38 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

ORD как порядковый номер часто полезен для какого-то уникального целого отпечатка другой сущности.
Например, в ORD(PROCEDURE) не интересует адрес, а интересует уникальный её целый идентификатор, по которому какую-нибудь метаинформацию можно привесить в хэш-таблицу.
Условно.

В ББ, например, есть Services.AddrOf(ANYREC) - и это безопасно. Ничего с адресом сделать без SYSTEM вредного Вы дальше не можете.

Автор:  Kemet [ Пятница, 15 Февраль, 2019 11:34 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Oleg N. Cher писал(а):
Ещё вопрос. В Обероне-07 есть встроенные функции ASR (арифметический сдвиг вправо), LSL (логический сдвиг влево) и ROR (циклический сдвиг вправо), хотя логического сдвига вправо и циклического сдвига влево нет. Или Вирт решил, что такие сдвиги и не нужны. Может от бедности? Сложно сказать. Я вообще не понимаю, зачем понадобилось выносить логический и циклический сдвиги из SYSTEM в язык. Это же работа с битами.
Линейный сдвиг влево для арифметического и логического варианта не отличаются - знаковый бит теряется( но устанавливается специальный флаг ), справа вписываются нули. Поэтому Вирт посчитал, что наличие двух разных операторов, выполняющих одно и тоже, совершенно излишняя сложность. Поэтому он оставил аббревиатуру LSL ( по-сути это и есть логический сдвиг ). А вот линейный арифметический сдвиг вправо работает именно так, как нужно - знак числа сохраняется. Беззнаковых типов у Вирта нет, поэтому наличие логического сдвига вправо - лишняя сущность (возможно, что и в учебном процессоре RISC5 тоже нет такой команды). Я же говорю - это узко заточенный язык, под конкретное применение. По сюжету он не нужен.

Автор:  Kemet [ Пятница, 15 Февраль, 2019 11:40 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Oleg N. Cher писал(а):
А почему они для числового типа INTEGER, а не для битового SET?
А разве есть операция сдвига множества?

Автор:  Trurl [ Пятница, 15 Февраль, 2019 13:43 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Смотря чего множество.

Автор:  Oleg N. Cher [ Суббота, 16 Февраль, 2019 06:11 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Пока что тут не прозвучало слов в защиту или опровержение операций сдвига в противоположную сторону при заданном отрицательном количестве бит.

Скажите навскидку: ORD({31}) < 0 или нет? Оно всегда и везде < 0 или в специфическом окружении так может и не быть? Где в описании языка про это есть? Другими словами, всегда ли при программировании на Обероне-07 нам следует ассоциировать 31-й бит как знаковый? Когда к целым числам применяется официально не системная, но одобренная и предсказуемая операция ROR, об этом следует твёрдо знать.

Илья Ермаков писал(а):
ORD как порядковый номер часто полезен для какого-то уникального целого отпечатка другой сущности.
Ну если так, то да, смысл есть. Но такую возможность нужно ещё протащить в стандарт языка, обосновать, хорошо описать в документации, а только потом реализовывать. А пока обойдёмся SYSTEM.ADR, который без SYSTEM.PUT не опаснее ORD.

Kemet писал(а):
Поэтому Вирт посчитал, что наличие двух разных операторов, выполняющих одно и тоже, совершенно излишняя сложность.
Да даже наличие операции ASR — излишняя сложность, потому что то же самое делает DIV, о чём ранее писал Пётр:
Пётр Кушнир писал(а):
Вирт это дело очень любит, умножил/поделил на 01000H вот и сдвинул туда/сюда.

Kemet писал(а):
Беззнаковых типов у Вирта нет, поэтому наличие логического сдвига вправо - лишняя сущность
А вот в логическом сдвиге вправо смысла было бы намного больше, чем в арифметическом (который и без ASR легко сделать с помощью DIV). А так приходится его эмулировать при помощи арифметического сдвига — проверять и сбрасывать знак, и потом только сдвигать.

Kemet писал(а):
Я же говорю - это узко заточенный язык, под конкретное применение. По сюжету он не нужен.
Да я постоянно спорю об этом с Оберонцами-07, но они очень упёртые и этого не признают. Расширяют потихоньку для себя, куда считают нужным.

Kemet писал(а):
А разве есть операция сдвига множества?
В Обероне, насколько я понимаю, на тип SET положена роль работы с битами, а раз так, то смысл в сдвигах битов есть. Просто в отдельную операцию его не выделили, обходятся такой конструкцией:
Код:
set := SYSTEM.VAL(SET, ROR(ORD(set), n));

Автор:  Sergej Durmanov [ Суббота, 16 Февраль, 2019 09:15 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Цитата:
Пока что тут не прозвучало слов в защиту или опровержение операций сдвига в противоположную сторону при заданном отрицательном количестве бит.
каким образом? Например, в x86 под счетчик сдвигов выделено определенное количество бит в регистре cl, так, чтобы не превысить разрядность слова. То есть для 32 бит, диапазон 0-31, для 64бит, 0-63. Никакого знака нет. Если попытаться использовать большее число, оно просто будет отсечено до нужного количества бит, и результат будет странным. И в процессоре Вирта не случайно присутствуют разные команды для сдвига влево и вправо. Замена сдвига на деление не очень актуальна, так как деление очень медленное, а сдвиг очень быстрый, и как раз наоборот, умножение и деление заменяют на сдвиги где это возможно.

Автор:  Kemet [ Суббота, 16 Февраль, 2019 09:49 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Не, ну это же учебная экосистема. Она полна концептов. И студентам нужно не просто пялиться в экран и восхищаться величием Вирта, а что-то лабать. Ну вот как раз те самые отсутствующие сдвиги, например. Непонимание этого простого факта приводит к появленгию очередных свидетелей Ие.., а, ну да, Вирта.
Та же самая проблема с А2. Она также позиционируется как учебная экосистема. И в ней полно концептов. И нет ортогональной реализации. Студентов нужно учить. Студентам нужно лабать очередной шедевр. Поэтому у каждого свой вариант Оберона07 или Активного Оберона/А2. Это не даёт развиваться экосистемам.
Поэтому, я ещё раз повторю - Оберон07 вне определенной экосистемы и вне определенного применения совершенно не нужен и нет нужды тратить на него время, чтобы слабать очередной недокомпилятор, если только вы не ставите перед собой образовательные задачи.
Как только мы начинаем тянуть учебную экосистему в продакшн, так сразу упираемся в концепты. И приходится брать кувалду, напильник и звать чью-то маму. В результате получается очередной прыжок в сторону. И космозоопарк.

Страница 1 из 5 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/