OberonCore https://forum.oberoncore.ru/ |
|
Оберон-07: вопросы реализации https://forum.oberoncore.ru/viewtopic.php?f=115&t=6352 |
Страница 4 из 5 |
Автор: | Kemet [ Понедельник, 04 Март, 2019 10:09 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Oleg N. Cher писал(а): Kemet, но чисто для Вас я поменял местами XCHG и SHRD. А если счетчик сдвигов = 32? |
Автор: | Oleg N. Cher [ Понедельник, 04 Март, 2019 13:26 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
SHRD всё равно выставит флаги как при сдвиге на 0 битов. Kemet, вот дались Вам эти флаги. BlackBox никак не заставляет как-то специально выставлять флаги после работы кодовых процедур. Если у A2 такие требования есть, то я искренне сочувствую. Вдогонку. Всякая машинная команда поступает с флагами по-своему, исходя из логики своей работы. Если бы BlackBox'ом регламентировалось выставить там флаг Zero в качестве булевского результата кодовой процедуры, тогда бы я ещё понял. Но ничего такого нет. |
Автор: | Kemet [ Понедельник, 04 Март, 2019 14:40 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Так всё просто - машинные инструкции ror и rol помещают сдвигаемый бит в флаг CF. И есть алгоритмы, которые используют циклические сдвиги и флаг. Логично, что программно реализованные операции делают то же самое. Тогда алгоритмы работают без всяких проблем при смене разрядности данных. Это ожидаемое поведение для архитектуры x86. |
Автор: | Oleg N. Cher [ Вторник, 05 Март, 2019 10:07 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Kemet, не слезайте с темы. Выставлять флаги специально "чтобы было" не нужно. Никакой разумной причины для этого нет. Ну вот. Стоило мне закончить со сдвигами, и тут по рассылке ETH пробегает знатный образчик кода: Jörg Straube писал(а): Instead of what is now in Display.Mod, this should have been my favorite, as it is short and doesn’t need SYSTEM.VAL(). mask := -LSL({0..31}, x); The following code is even shorter source code but 100% equivalent to the above: mask := -LSL(-{}, x); Compare this to my first "mask := SYSTEM.VAL(SET, ASR(7FFFFFFF, 31-x));"!!! It seems I was under time pressure I didn’t think long enough... Человек радостно радуется, что избежал SYSTEM. Я печально грущу из-за того, что сдвиги в сообщении о языке Оберон-07 вообще-то не поддерживают тип SET. Но это в рассылке никого не смущает. Как видим, соответствующий описанию академический Оберон-07 действительно никому не интересен, даже реализаторам систем на FPGA, уж не знаю, Вирт это или сотоварищи. Интересно нафаршировать его ловкими фишками. Всё-таки придётся мне ввести предупреждение "Non-standard feature in Oberon-07" и тоже попробовать новые фишки типа ORD(real) и LSL(set). |
Автор: | Trurl [ Вторник, 05 Март, 2019 10:47 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Oleg N. Cher писал(а): Я печально грущу из-за того, что сдвиги в сообщении о языке Оберон-07 вообще-то не поддерживают тип SET. Но это в рассылке никого не смущает. А Вас смущает? LONGINT они ведь тоже не поддерживают. |
Автор: | Oleg N. Cher [ Вторник, 05 Март, 2019 11:12 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
LONGINT, я слышал, некоторые компиляторы Оберона-07 понимают как алиас INTEGER. |
Автор: | Kemet [ Вторник, 05 Март, 2019 13:37 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Oleg N. Cher писал(а): Kemet, не слезайте с темы. Выставлять флаги специально "чтобы было" не нужно. Никакой разумной причины для этого нет. Причина проста - одинаковое поведение машинной инструкции и её программного воплощения. На форумах фрипаскаля несколько раз всплывали темы, когда люди натыкались на проблемы из-за того, что семантика программной реализации для 64-битных чисел в 32-битном режиме отличалась от машинной.Oleg N. Cher писал(а): Человек радостно радуется, что избежал SYSTEM. Я печально грущу из-за того, что сдвиги в сообщении о языке Оберон-07 вообще-то не поддерживают тип SET. Но это в рассылке никого не смущает. Да как-бы Вирта не смущает, что в прожект оберон реализация Оберона-07 не соответствует репорту. Оберон что дышло: куда повернул - туда и вышло.
|
Автор: | Artyemov [ Вторник, 05 Март, 2019 18:15 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Oleg N. Cher писал(а): ...академический Оберон-07 действительно никому не интересен, даже реализаторам систем на FPGA... Дык в цифровом "железе" сдвиговый регистр это... ну, как колесо. И принцип "биты - не числа" в железе, мягко говоря, не продуктивен. |
Автор: | Oleg N. Cher [ Вторник, 05 Март, 2019 18:28 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Kemet писал(а): Причина проста - одинаковое поведение машинной инструкции и её программного воплощения. На форумах фрипаскаля несколько раз всплывали темы, когда люди натыкались на проблемы из-за того, что семантика программной реализации для 64-битных чисел в 32-битном режиме отличалась от машинной. Я вообще не понял эту фразу, как-то сильно замудрёно. Вы хотите этим сказать, что какая-то часть программы будет полагаться на флаги, выставленные неизвестной командой в кодовой процедуре так, как ей нужно? Ну так просветите нас, дайте примеры, чтобы всё это не было голословно. Пока же я считаю свою реализацию ROR корректной. А ту, что показали Вы (из A2) — нет.Kemet писал(а): Да как-бы Вирта не смущает, что в прожект оберон реализация Оберона-07 не соответствует репорту. Оберон что дышло: куда повернул - туда и вышло. Это печально. Получается, имеем описание на 17 страниц, но толку с него мало. PACK и UNPK вообще описаны в двух словах. И меня не покидает ощущение, что Оберон-07 — самый эзотеричный из всех языков семейства Оберона.Artyemov писал(а): Дык в цифровом "железе" сдвиговый регистр это... ну, как колесо. И принцип "биты - не числа" в железе, мягко говоря, не продуктивен. С этим я не спорю, всё так и есть. Но мы же сейчас не про ассемблер, а про компактный академический ЯВУ, проверенный временем и выверенный в лучших традициях швейцарской школы ETH?
|
Автор: | Artyemov [ Вторник, 05 Март, 2019 19:13 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Выход один: сводить все нестыковки в списочек и просить Никлауса Эмилича утрясти их на досуге. |
Автор: | Kemet [ Среда, 06 Март, 2019 05:39 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Oleg N. Cher писал(а): Я вообще не понял эту фразу, как-то сильно замудрёно. Эта песня будет вечной.В Обероне-07 присутствуют операции, которые, как раз, учитывают тот самый флаг: Цитата: ADC(m, n) INTEGER INTEGER add with carry C SBC(m, n) INTEGER INTEGER subtract with carry C Ну вот как бы надо обеспечить этот самый флаг, если семантика машинной инструкции предполагает его установку. А команды сдвига этот флаг устанавливают. |
Автор: | Rifat [ Среда, 06 Март, 2019 10:25 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Oleg N. Cher писал(а): И меня не покидает ощущение, что Оберон-07 — самый эзотеричный из всех языков семейства Оберона. А меня не покидает ощущение, что обсуждаются какие-то мелочи: где какой флаг переноса и т.д. А более важные вопросы не обсуждаются. Под более важными вопросами я имею в виду создание параллельных программ на Оберон-07. Или же to be or not to be aliasing? Например: Цитата: MODULE M; VAR x: INTEGER; PROCEDURE Proc(VAR a, b: INTEGER); BEGIN a := b + 1; ASSERT(a # b); END Proc; BEGIN x := 1; Proc(x, x); END M. Хотя кажется, что внутри процедуры Proc переменная a никак не может равняться переменной b, но так как a и b синонимы, то значения у них будут одинаковы и ASSERT сработает. Как мне кажется, синонимы надо запретить, однако же во всех Оберонах (насколько я знаю) они разрешены. |
Автор: | Trurl [ Среда, 06 Март, 2019 12:22 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Ну, это уже не "вопросы реализации", а "разработка нового языка программирования". |
Автор: | Oleg N. Cher [ Среда, 06 Март, 2019 14:11 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Kemet писал(а): В Обероне-07 присутствуют операции, которые, как раз, учитывают тот самый флаг Уточним. Не в Обероне-07, а в "опциональном модуле SYSTEM" ("The optional module SYSTEM") (цитирую Oberon07.Report), который не является частью языка Оберон. К тому же, не входящая в язык машинная реализация произвольной операции вольна поступать с флагами так, как ей угодно.Kemet писал(а): Ну вот как бы надо обеспечить этот самый флаг, если семантика машинной инструкции предполагает его установку. А команды сдвига этот флаг устанавливают. И какова же, по Вашему мнению, должна быть семантика выставления флага Carry в случае с ROR, скажем, на 20 бит?Вы вот, Kemet, придрались к моей реализации ROR, а ведь Ваш вариант (для A2) ровно так же выставит флаги, как и мой, но только в случае сдвига на 0..31 бит первой операцией SHRD, а в случае сдвига на 32..63 бит — второй операцией. Для какой именно половины сдвига важно возвращать корректный флаг Carry? И для какого именно бита? Если не вникать в эту всю фигню, то Вам, по-хорошему, надо выработать нормальную семантику выставления флага и убедиться, что все случаи отрабатывания SHRD ей соответствуют. Я заявляю участие моей реализации ROR в этом тестировании. Думаю, она будет не хуже A2'шной. Rifat писал(а): Как мне кажется, синонимы надо запретить, однако же во всех Оберонах (насколько я знаю) они разрешены. Да уж, интересный случай. Пожалуй, запрещать синонимы на уровне компиляции — это усложнит компилятор и перегрузит описание языка. Проблема в том, что даже маленький Оберон подвержен таким тонким моментам...
|
Автор: | Rifat [ Среда, 06 Март, 2019 15:10 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Oleg N. Cher писал(а): Rifat писал(а): Как мне кажется, синонимы надо запретить, однако же во всех Оберонах (насколько я знаю) они разрешены. Да уж, интересный случай. Пожалуй, запрещать синонимы на уровне компиляции — это усложнит компилятор и перегрузит описание языка. Проблема в том, что даже маленький Оберон подвержен таким тонким моментам...Вообще говоря да, определить, что параметры могут являться синонимами не сказать, что очень просто, так как возможны случаи, когда в процедуру передается запись, а другим параметров поле этой записи. И внутри процедуры поле записи (которая передана как запись) и другая переменная могут быть синонимами. Я слышал, что в языке SPARK (подмножество ADA) синонимы запрещены. |
Автор: | Comdiv [ Среда, 06 Март, 2019 15:36 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Oleg N. Cher писал(а): Пожалуй, запрещать синонимы на уровне компиляции — это усложнит компилятор и перегрузит описание языка. "Достаточно" запретить VAR-параметры, то есть, описание языка как раз только упростится. Но без добавления других возможностей это усложнит написание программ и понизит их эффективность.
|
Автор: | SovietPony [ Среда, 06 Март, 2019 17:42 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Rifat писал(а): синонимы надо запретить На здоровье:Код: ASSERT(SYSTEM.ADR(a) # SYSTEM.ADR(b)) А с примитвами вообще лучше использовать процедуры-функции вместо var-праметров.
или IF SYSTEM.ADR(a) # SYSTEM.ADR(b) THEN (* optimized code *) ELSE (* generic code *) END |
Автор: | Rifat [ Среда, 06 Март, 2019 17:53 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
SovietPony писал(а): SYSTEM.ADR(a) # SYSTEM.ADR(b). А если будет 10 параметров и практически все различаются, только два каких то параметра могут совпадать, то уже сотни вариантов кода будут. А если 10 параметров, но 3 параметра могут совпадать, то еще сотни таких вариантов. И один вариант, когда все 10 параметров являются синонимами. То есть динамически проверить адреса и под это генерировать различный код не очень хорошее решение. Как вариант, конечно, можно оставить два крайних случая, когда никаких синонимов нет и когда все параметры могут являться синонимами. Лучше, конечно, чтобы на этапе компиляции компилятор просто не компилировал код с синонимами. |
Автор: | Trurl [ Среда, 06 Март, 2019 18:46 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Comdiv писал(а): "Достаточно" запретить VAR-параметры Тогда уж и указатели. |
Автор: | Comdiv [ Среда, 06 Март, 2019 18:57 ] |
Заголовок сообщения: | Re: Оберон-07: вопросы реализации |
Если избавляться от синонимов в расширенном смысле, то это нерешаемая задача, поскольку в алгоритмически полном языке нельзя выкинуть понятие указателя, даже если избавиться от термина. Код: MODULE M;
CONST x = 0; VAR mem: ARRAY 640 OF INTEGER; PROCEDURE Proc(a, b: INTEGER); BEGIN mem[a] := mem[b] + 1; ASSERT(mem[a] # mem[b]); END Proc; BEGIN mem[x] := 1; Proc(x, x); END M. |
Страница 4 из 5 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |