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))

или

IF SYSTEM.ADR(a) # SYSTEM.ADR(b) THEN
  (* optimized code *)
ELSE
  (* generic code *)
END
А с примитвами вообще лучше использовать процедуры-функции вместо var-праметров.

Автор:  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/