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 вычислить. |
Автор: | 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/ |