OberonCore

А если счетчик сдвигов = 32?

SHRD всё равно выставит флаги как при сдвиге на 0 битов.

Kemet, вот дались Вам эти флаги. BlackBox никак не заставляет как-то специально выставлять флаги после работы кодовых процедур. Если у A2 такие требования есть, то я искренне сочувствую.

Вдогонку. Всякая машинная команда поступает с флагами по-своему, исходя из логики своей работы. Если бы BlackBox'ом регламентировалось выставить там флаг Zero в качестве булевского результата кодовой процедуры, тогда бы я ещё понял. Но ничего такого нет.

Так всё просто - машинные инструкции ror и rol помещают сдвигаемый бит в флаг CF. И есть алгоритмы, которые используют циклические сдвиги и флаг. Логично, что программно реализованные операции делают то же самое. Тогда алгоритмы работают без всяких проблем при смене разрядности данных. Это ожидаемое поведение для архитектуры x86.

Kemet, не слезайте с темы. Выставлять флаги специально "чтобы было" не нужно. Никакой разумной причины для этого нет.

Ну вот. Стоило мне закончить со сдвигами, и тут по рассылке ETH пробегает знатный образчик кода:


Человек радостно радуется, что избежал SYSTEM. Я печально грущу из-за того, что сдвиги в сообщении о языке Оберон-07 вообще-то не поддерживают тип SET. Но это в рассылке никого не смущает.

Как видим, соответствующий описанию академический Оберон-07 действительно никому не интересен, даже реализаторам систем на FPGA, уж не знаю, Вирт это или сотоварищи. Интересно нафаршировать его ловкими фишками. Всё-таки придётся мне ввести предупреждение "Non-standard feature in Oberon-07" и тоже попробовать новые фишки типа ORD(real) и LSL(set).

А Вас смущает? LONGINT они ведь тоже не поддерживают.

LONGINT, я слышал, некоторые компиляторы Оберона-07 понимают как алиас INTEGER.

Причина проста - одинаковое поведение машинной инструкции и её программного воплощения. На форумах фрипаскаля несколько раз всплывали темы, когда люди натыкались на проблемы из-за того, что семантика программной реализации для 64-битных чисел в 32-битном режиме отличалась от машинной.
Да как-бы Вирта не смущает, что в прожект оберон реализация Оберона-07 не соответствует репорту. Оберон что дышло: куда повернул - туда и вышло.

Дык в цифровом "железе" сдвиговый регистр это... ну, как колесо. И принцип "биты - не числа" в железе, мягко говоря, не продуктивен.

Я вообще не понял эту фразу, как-то сильно замудрёно. Вы хотите этим сказать, что какая-то часть программы будет полагаться на флаги, выставленные неизвестной командой в кодовой процедуре так, как ей нужно? Ну так просветите нас, дайте примеры, чтобы всё это не было голословно. Пока же я считаю свою реализацию ROR корректной. А ту, что показали Вы (из A2) — нет.

Это печально. Получается, имеем описание на 17 страниц, но толку с него мало. PACK и UNPK вообще описаны в двух словах. И меня не покидает ощущение, что Оберон-07 — самый эзотеричный из всех языков семейства Оберона.

С этим я не спорю, всё так и есть. Но мы же сейчас не про ассемблер, а про компактный академический ЯВУ, проверенный временем и выверенный в лучших традициях швейцарской школы ETH?

Выход один: сводить все нестыковки в списочек и просить Никлауса Эмилича утрясти их на досуге.

Эта песня будет вечной.
В Обероне-07 присутствуют операции, которые, как раз, учитывают тот самый флаг:

Ну вот как бы надо обеспечить этот самый флаг, если семантика машинной инструкции предполагает его установку. А команды сдвига этот флаг устанавливают.

А меня не покидает ощущение, что обсуждаются какие-то мелочи: где какой флаг переноса и т.д. А более важные вопросы не обсуждаются. Под более важными вопросами я имею в виду создание параллельных программ на Оберон-07. Или же to be or not to be aliasing? Например:

Хотя кажется, что внутри процедуры Proc переменная a никак не может равняться переменной b, но так как a и b синонимы, то значения у них будут одинаковы и ASSERT сработает. Как мне кажется, синонимы надо запретить, однако же во всех Оберонах (насколько я знаю) они разрешены.

Ну, это уже не "вопросы реализации", а "разработка нового языка программирования".

Уточним. Не в Обероне-07, а в "опциональном модуле SYSTEM" ("The optional module SYSTEM") (цитирую Oberon07.Report), который не является частью языка Оберон. К тому же, не входящая в язык машинная реализация произвольной операции вольна поступать с флагами так, как ей угодно.

И какова же, по Вашему мнению, должна быть семантика выставления флага Carry в случае с ROR, скажем, на 20 бит?

Вы вот, Kemet, придрались к моей реализации ROR, а ведь Ваш вариант (для A2) ровно так же выставит флаги, как и мой, но только в случае сдвига на 0..31 бит первой операцией SHRD, а в случае сдвига на 32..63 бит — второй операцией. Для какой именно половины сдвига важно возвращать корректный флаг Carry? И для какого именно бита? Если не вникать в эту всю фигню, то Вам, по-хорошему, надо выработать нормальную семантику выставления флага и убедиться, что все случаи отрабатывания SHRD ей соответствуют. Я заявляю участие моей реализации ROR в этом тестировании. Думаю, она будет не хуже A2'шной.

Да уж, интересный случай. Пожалуй, запрещать синонимы на уровне компиляции — это усложнит компилятор и перегрузит описание языка. Проблема в том, что даже маленький Оберон подвержен таким тонким моментам...

Вообще говоря да, определить, что параметры могут являться синонимами не сказать, что очень просто, так как возможны случаи, когда в процедуру передается запись, а другим параметров поле этой записи. И внутри процедуры поле записи (которая передана как запись) и другая переменная могут быть синонимами.
Я слышал, что в языке SPARK (подмножество ADA) синонимы запрещены.

"Достаточно" запретить VAR-параметры, то есть, описание языка как раз только упростится. Но без добавления других возможностей это усложнит написание программ и понизит их эффективность.

На здоровье:
А с примитвами вообще лучше использовать процедуры-функции вместо var-праметров.

А если будет 10 параметров и практически все различаются, только два каких то параметра могут совпадать, то уже сотни вариантов кода будут. А если 10 параметров, но 3 параметра могут совпадать, то еще сотни таких вариантов. И один вариант, когда все 10 параметров являются синонимами. То есть динамически проверить адреса и под это генерировать различный код не очень хорошее решение. Как вариант, конечно, можно оставить два крайних случая, когда никаких синонимов нет и когда все параметры могут являться синонимами.
Лучше, конечно, чтобы на этапе компиляции компилятор просто не компилировал код с синонимами.

Тогда уж и указатели.

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