OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 20 Сентябрь, 2019 02:21

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 98 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Понедельник, 04 Март, 2019 10:09 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 714
Откуда: Барнаул
Oleg N. Cher писал(а):
Kemet, но чисто для Вас я поменял местами XCHG и SHRD.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Понедельник, 04 Март, 2019 13:26 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 320
Откуда: Украина, Днепропетровская обл.
SHRD всё равно выставит флаги как при сдвиге на 0 битов.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Понедельник, 04 Март, 2019 14:40 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 714
Откуда: Барнаул
Так всё просто - машинные инструкции ror и rol помещают сдвигаемый бит в флаг CF. И есть алгоритмы, которые используют циклические сдвиги и флаг. Логично, что программно реализованные операции делают то же самое. Тогда алгоритмы работают без всяких проблем при смене разрядности данных. Это ожидаемое поведение для архитектуры x86.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Вторник, 05 Март, 2019 10:07 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 320
Откуда: Украина, Днепропетровская обл.
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).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Вторник, 05 Март, 2019 10:47 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1200
Oleg N. Cher писал(а):
Я печально грущу из-за того, что сдвиги в сообщении о языке Оберон-07 вообще-то не поддерживают тип SET. Но это в рассылке никого не смущает.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Вторник, 05 Март, 2019 11:12 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 320
Откуда: Украина, Днепропетровская обл.
LONGINT, я слышал, некоторые компиляторы Оберона-07 понимают как алиас INTEGER.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Вторник, 05 Март, 2019 13:37 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 714
Откуда: Барнаул
Oleg N. Cher писал(а):
Kemet, не слезайте с темы. Выставлять флаги специально "чтобы было" не нужно. Никакой разумной причины для этого нет.
Причина проста - одинаковое поведение машинной инструкции и её программного воплощения. На форумах фрипаскаля несколько раз всплывали темы, когда люди натыкались на проблемы из-за того, что семантика программной реализации для 64-битных чисел в 32-битном режиме отличалась от машинной.
Oleg N. Cher писал(а):
Человек радостно радуется, что избежал SYSTEM. Я печально грущу из-за того, что сдвиги в сообщении о языке Оберон-07 вообще-то не поддерживают тип SET. Но это в рассылке никого не смущает.
Да как-бы Вирта не смущает, что в прожект оберон реализация Оберона-07 не соответствует репорту. Оберон что дышло: куда повернул - туда и вышло.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Вторник, 05 Март, 2019 18:15 

Зарегистрирован: Пятница, 13 Март, 2015 16:40
Сообщения: 326
Oleg N. Cher писал(а):
...академический Оберон-07 действительно никому не интересен, даже реализаторам систем на FPGA...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Вторник, 05 Март, 2019 18:28 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 320
Откуда: Украина, Днепропетровская обл.
Kemet писал(а):
Причина проста - одинаковое поведение машинной инструкции и её программного воплощения. На форумах фрипаскаля несколько раз всплывали темы, когда люди натыкались на проблемы из-за того, что семантика программной реализации для 64-битных чисел в 32-битном режиме отличалась от машинной.
Я вообще не понял эту фразу, как-то сильно замудрёно. Вы хотите этим сказать, что какая-то часть программы будет полагаться на флаги, выставленные неизвестной командой в кодовой процедуре так, как ей нужно? Ну так просветите нас, дайте примеры, чтобы всё это не было голословно. Пока же я считаю свою реализацию ROR корректной. А ту, что показали Вы (из A2) — нет.

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

Artyemov писал(а):
Дык в цифровом "железе" сдвиговый регистр это... ну, как колесо. И принцип "биты - не числа" в железе, мягко говоря, не продуктивен.
С этим я не спорю, всё так и есть. Но мы же сейчас не про ассемблер, а про компактный академический ЯВУ, проверенный временем и выверенный в лучших традициях швейцарской школы ETH? :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Вторник, 05 Март, 2019 19:13 

Зарегистрирован: Пятница, 13 Март, 2015 16:40
Сообщения: 326
Выход один: сводить все нестыковки в списочек и просить Никлауса Эмилича ;-) утрясти их на досуге.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 05:39 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 714
Откуда: Барнаул
Oleg N. Cher писал(а):
Я вообще не понял эту фразу, как-то сильно замудрёно.
Эта песня будет вечной.
В Обероне-07 присутствуют операции, которые, как раз, учитывают тот самый флаг:
Цитата:
ADC(m, n) INTEGER INTEGER add with carry C
SBC(m, n) INTEGER INTEGER subtract with carry C

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 10:25 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 812
Откуда: Казань
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 сработает. Как мне кажется, синонимы надо запретить, однако же во всех Оберонах (насколько я знаю) они разрешены.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 12:22 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1200
Ну, это уже не "вопросы реализации", а "разработка нового языка программирования".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 14:11 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 320
Откуда: Украина, Днепропетровская обл.
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 писал(а):
Как мне кажется, синонимы надо запретить, однако же во всех Оберонах (насколько я знаю) они разрешены.
Да уж, интересный случай. Пожалуй, запрещать синонимы на уровне компиляции — это усложнит компилятор и перегрузит описание языка. :-) Проблема в том, что даже маленький Оберон подвержен таким тонким моментам...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 15:10 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 812
Откуда: Казань
Oleg N. Cher писал(а):
Rifat писал(а):
Как мне кажется, синонимы надо запретить, однако же во всех Оберонах (насколько я знаю) они разрешены.
Да уж, интересный случай. Пожалуй, запрещать синонимы на уровне компиляции — это усложнит компилятор и перегрузит описание языка. :-) Проблема в том, что даже маленький Оберон подвержен таким тонким моментам...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 15:36 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 888
Откуда: Киев
Oleg N. Cher писал(а):
Пожалуй, запрещать синонимы на уровне компиляции — это усложнит компилятор и перегрузит описание языка.
"Достаточно" запретить VAR-параметры, то есть, описание языка как раз только упростится. Но без добавления других возможностей это усложнит написание программ и понизит их эффективность.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 17:42 

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 54
Откуда: Equestria
Rifat писал(а):
синонимы надо запретить
На здоровье:
Код:
ASSERT(SYSTEM.ADR(a) # SYSTEM.ADR(b))

или

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 17:53 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 812
Откуда: Казань
SovietPony писал(а):
SYSTEM.ADR(a) # SYSTEM.ADR(b).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 18:46 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1200
Comdiv писал(а):
"Достаточно" запретить VAR-параметры

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оберон-07: вопросы реализации
СообщениеДобавлено: Среда, 06 Март, 2019 18:57 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 888
Откуда: Киев
Если избавляться от синонимов в расширенном смысле, то это нерешаемая задача, поскольку в алгоритмически полном языке нельзя выкинуть понятие указателя, даже если избавиться от термина.
Код:
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.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 98 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB