Оберон-клуб «ВЄДАsoft»

Обнаружил, что константы Platform.Unsigned_ХХХ нельзя смешивать в одном константном диапазоне с "обычными" числами 0..127. Так, например,
попытка поставить 100..Platform.Unsigned_200: в одной из ветвей CASE вызовет сообщение "illegal value of constant", потому что фактически у нас написано "100..-56", т.е. правая граница меньше левой.
Однако можно в данном случае разбить диапазон на два и написать "100..127, Platform.Unsigned_128..Platform.Unsigned_200:" , такое Оfront пропустит.

_________________
А кроме того, я думаю, что корFORген должен быть разрушен!

Кроме того, что такой CASE выглядит коряво, ещё плохо то, что, видимо, в Ofront'е немало таких мест, где надо поправить код в сторону учёта беззнаковости. Значит "малой кровью" обойтись не получится...

Вот, Олег, хочу показать тебе коммит, реализующий это "подобие работы с беззнаковыми". Тогда я отложил "на потом" многие вопросы, которые нужно было поставить сразу. Например, разрешить ли смешивать знаковые и беззнаковые типы в выражениях (как это разрешено в Си), или напротив — запретить (как в Модуле-2)? Первый вариант порождает бардак и чехарду, второй — значительно ограничивает область применения беззнаковых. В Си меня угнетает, например, вот такое:

Признаюсь, я склонен разрешить в XDev произвольное смешивание знаковых и беззнаковых вот по каким причинам. Во-первых, это увеличит применимость беззнаковых (там, где это нужно, конечно), во-вторых беззнаковые у нас — это системные типы, а в-третьих появляется интересная возможность скрыто пользоваться беззнаковыми типами только на некоторых платформах, не нарушая изначальную идеологию Оберона. Т.е.:

Тогда мы будем иметь на каждой платформе свою идеально оптимальную реализацию, не засвечивая явно, что типы могут быть и беззнаковыми. И я уже разрабатывал таким образом программы, получаеся очень эффективно. Но нет ли здесь подводных камней?

Меня вот несколько смущает неявный импорт SYSTEM (который тянут за собой беззнаковые типы), но с тем же успехом в Обероне/КП можно неявно импортировать SYSTEM, используя и, например, безтеговые указатели, ведь по ним сверху и не скажешь, что они безтеговые. Так что, в принципе, наверно это приемлемо. Но какие будут ещё мысли?

Боюсь, Олег, что я еще мало разбираюсь во внутренностях Ofront (и,увы, в компиляторах вообще). Новое, как я понял, в строчке
Что именно она делает?

Конечно, без всяких операций со знаковыми и беззнаковыми мы не обойдемся, но и бездумно смешивать их не хотелось бы. По крайней мере, такому смешению нужно придать какую-то ясную и полезную семантику. Хорошо бы выделить общие случаи, когда такое смешение необходимо и что должно при этом получаться. Например, пусть IF x < y сравнивает величины разной "знаковости". Если мы при этом преобразуем один тип к другому - получим одно (вернее два результата - когда x преобразуется к типу y и когда наоборот), если мы обе величины преобразуем к некому "большему" общему для них типу, то это уже другое. Хотелось бы, чтобы было ясно какой из этих случаев имеет место и как-то управлять выбором этих случаев.

Да, такая инкапсуляция типов выглядит "в духе Оберона": важно, что это координаты, в какой конкретно тип они транслируются с целью эффективности на данном уровне абстракции не важно. А подводные камни могут быть в том, что употребляя эти типы, программист будет подразумевать какую-то неявную семантику (ошибочно), уповать на неизменность каких-то свойств, что на другой платформе совершенно изменятся. В результате и получится неконтролируемое смешивание типов с неясным результатом. Поэтому важно оговорить, что общее для всех платформ (чем желательно, в основном, и пользоваться), а что специфично для каждой. И как это специфическое настраивать. Т.е. желательно иметь не крайние подходы ("совсем не смешивать", "как угодно смешивать"), а настройка разных уровней:подключим вот это - можно будет делать это, остальное компилятор не даст; подключим еще и это - можно будет и вот так еще и т.д. Т.е. примерно как модуль SYSTEM: обходимся без него - хорошо, значит не делаем ничего платформозависимого. А нужно что-то особое - подключи SYSTEM и можно будет еще вот это и вон то.

Да, тоже думаю приемлемо, потому что у нас специфические, "системные" задачи, без SYSTEM нам никак не обойтись.

_________________
А кроме того, я думаю, что корFORген должен быть разрушен!

Сегодня столкнулся с трапом Ofront'а. Хотел уже писать репорт Дж.Темплу, но выяснилось, что косячат мои "прилепленные скотчем" беззнаковые типы. Прикладываю фрагмент, воспроизводящий ошибку (трап исчезает, если изменить типы SYSTEM.SHORTCARD на SHORTINT).

Ошибка возникает из-за превышения глубины рекурсивного вызова процедуры OPC.Stars. Похоже зациклилась обработка типов. Может быть это из-за последнего коммита "IF typ = typ^.BaseTyp THEN OPM.WriteString(prev^.strobj^.name); EXIT END;" ?

Оптимальные условия для реализации цикла FOR через REPEAT UNTIL, которым я посвятил аж7 постов, мне несколько надоели, поэтому на этой неделе я прошелся по форуму и написал сообщения в другие темы Размышления о беззнаковом делении привели в эту ветку.
Как обстоит сейчас дело с беззнаковыми типами в Ofront? Не слишком хорошо, не так ли? Это, наверно, потому, что мы движемся не в том направлении. Подмена идентификаторов типов и псевдофункция Platform.Unsigned - это путь в тупик. Тем более, что тут уже начали вылезать непонятные ошибки (см предыдущий пост). Единственная польза этого пути в том, что он показал как трудно ввести беззнаковые числа.
Так что предлагаю начать заново.
1) Надо убрать из Ofront изменения, которые должны были обеспечить работу с беззнаковыми числами. Нужно вернуться к чистознаковым типам Дж.Темпла и убедиться, что все стабильно работает.
2) Ввести в структуру данных для хранения типов в Ofront специальный флажок Unsigned:BOOLEAN. Поскольку никакие процедуры Ofront о нем пока не знают, то он ничему пока и не помешает.
3) Заставить Ofront устанавливать этот флажок для идентификаторов типа SYSTEM.SHORTCARD и им подобным и сбрасывать его для обычных знаковых типов. Пусть в остальном пока работа с типами Unsigned и ~Unsigned никак не отличается, но теперь Ofront хотя бы знает, какие из них какие. Вот тут в Си-проге или сам Ofront, ориентируясь на флажок, или макроопределения в библиотеках могут вставлять для таких идентификаторов «unsigned». Т.е. мы достигнем того же функционала, что и сейчас, но получим меньше неприятных сюрпризов (я надеюсь).
4) Для типов unsigned изменить функции MIN и MAX, чтобы они давали верное значение. О, вот тут полезут всевозможные глюки и несоответствия, которые сейчас трудно себе и представить. Что же, для того и вводим новое, чтобы все эти проблемы выявить и устранить.
5) Ввести беззнаковые константы, Навроде, 255u – беззнаковый байт (в отличие от знакового 2-байтного 255). Ну или продумать правила, по которым та или иная константа будет относиться к знаковым или беззнаковым.
6) Изменить для беззнаковых функции с одним аргументом. Тоже думаю какие-то проблемы будут и тут.
7) Ввести операции (присваивания, сравнения) над беззнаковыми (в том числе, если они разной длины), пока без смешения знаковых и беззнаковых. Продумать и отладить эти операции прежде чем переходить к следующему пункту.
8) Операции (присваивания, сравнения)над знаковыми и беззнаковыми вперемешку. Что должно при этом получаться, каким путем. Следует ли приводить первое ко второму или наоборот или к большему типу, содержащему их оба. И какому большему — знаковому или беззнаковому и как этот выбор можно регулировать. Пока нет даже хорошей стройной теории этого, не то что реализации.
Вот такой план. Это трудно, но это путь в верном направлении, как я думаю. Правда особо в систему типов в Ofront я не вникал.

2Zorko: Олег, что думаешь по этому поводу?

Именно так, Олег.
Всё правильно. Кстати, ошибки лезут как раз из-за этой подмены. Получается, что беззнаковые типы сейчас являются алиасами знаковых, но код проработан не везде, и часть кода не знает, что могут быть такие алиасы. Поэтому правильным представляется убрать алиасы и ввести честные новые типы полностью, что подразумевает серьёзный объём работы.

Вообще не удивительно, что проф. Вирт отказался в Обероне от беззнаковых типов. И наверное не только потому, что операции с ними — область системная. А ещё и из-за усложнения компилятора. Весь каркас OP2, на котором построены ETH Oberon, BlackBox и Ofront спроектирован без учёта беззнаковой арифметики, и в системных целях предлагается эмулировать её системными средствами, а в крайнем случае ассемблерными или сишными вставками. А впрямь, много ли мы теряем, лишившись беззнаковости? Потери есть, но они не такие уж значительные. Выигрыш за счёт упрощения системы типов имхо всё же серьёзнее — меньше путаницы.

Точно также и приведение FOR x:=A TO B в стандарте к x:=A;WHILE x<=B это тоже компромисс для упрощения и описания реализации цикла, и самого компилятора. Но это никак не оправдание на самом деле.

Признаюсь честно, что введение беззнаковых в Ofront видится мне очень сложной работой. И я бы предложил чуть-чуть другой способ. Олег, не спеши его сразу отметать, плиз, давай помозгуем что из этого можно использовать, а что нет. Поскольку серьёзное усложнение Ofront'а является идеологически не совсем верным шагом, подумаем как добиться цели малой кровью. Здесь видится привлекательным: 1) библиотечный путь (как в XDev/Multi/CardAsm); 2) путь наращивания каркаса Ofront'а системой расширения типов, которая будет полезной не только для введения беззнаковой арифметики, но и ещё много для чего (я имею ввиду что-то вроде OberonX). Итак, если сделать интерфейс для беззнаковой арифметики на Обероне и реализацию на Си, получим вполне эффективное решение. Низкоуровневым представлением для беззнакового байта будет, например, тип CHAR (поскольку он подходит по размеру, плюс появится дополнительный барьер для смешивания знаковой и беззнаковой арифметики в обход средств модуля реализации). Выглядеть это может примерно так:
У этого решения крайне много недостатков. Такие беззнаковые числа не удастся использовать в качестве меток CASE, такие переменные не удастся использовать для цикла FOR. Но всё же способ привлекает своей простотой, масштабируемостью и невмешательством в код транслятора. Под масштабируемостью я здесь понимаю лёгкость возможности реализации подобного же модуля для других Оберон-трансляторов, и даже для тех платформ, где беззнаковая арифметика не столь актуальна. Из чего следует совместимость с кодом, который разработан, например, с учётом эффективности для процессора Z80, но будет работать, к примеру, и на JVM.

Буду рад услышать как этот способ можно усовершенствовать.

Не возражаю. Но хочу заметить, что Ofront, даже с этими изменениями работает замечательно стабильно если не использовать добавленные беззнаковые типы. Это подтверждается и тестированием, и исходит из самого кода. Там очень просто всё проверить. Но я не возражаю убрать эти изменения. Просто я ими пользуюсь для разработки под ZX, хотя это и явная полумера. А в проекте Ofront for Linux эту возможность убирать не нужно, т.к. её там и так нет.

Так что хочу подчеркнуть, что мне для моих разработок хватает полумеры в виде беззнаковых типов, введённых мною, даже несмотря на ошибки. Направление введения беззнаковых более серьёзным способом считаю не очень перспективным, хотя и желательным (вот бы кто сделал ).

Почему? Да просто ввиду малого количества заинтересованных в появлении беззнаковой арифметики для Ofront'а программистов.

Другое дело правильный цикл FOR. Вот это реально насущная потребность.

Не, имхо так вмешиваться в язык Оберон не нужно. Это же не просто системная возможность, импортированная из модуля SYSTEM. Это фактически посягательство на "улучшение" стандарта языка.

Кроме того, вроде как и необязательно указывать какая константа беззнаковая, если это следует из её описания. Типизированные константы AO — я до сих пор не понимаю в них нужды, разве что для чего-то вроде:

Да уж, есть над чем почесать тыковку!

План хороший. Только давай для начала попробуем выжать всё возможное из библиотечного решения?

Второй вариант — в стиле OberonX — можно было бы попробовать запрограммировать и отладить в OPCL (или в ETH Oberon), хотя проблемы с CASE и FOR будут висеть и там. Не, доделка Ofront'а — однозначно самый правильный и самый сложный способ, но вот кто бы сделал это за нас.

Кстати, Олег, если есть желание совершенствовать Ofront, то, возможно, более перспективными направлениями будет добавление конкатенации вида:

Или параметров процедур IN и OUT, это явная языковая прореха языков Оберон-1 и Оберон-2.

Есть конечно ещё один взгляд на параметры IN/OUT, что нужно сделать передачу массивов и сложных структур всяко без неявного копирования (а копирование при необходимости применять явно), но "это уже будет другой язык", хотя и тут есть над чем подумать.

Эти возможности уже присутствуют в Компонентном Паскале. Такие доработки Ofront'а имхо будут более востребованы в "большом" программировании, т.е. помимо Спектрума.

Сейчас есть 2 течения: к Оберону-07 и ещё большему упрощению; или к КП и балансу между простым и сложным. Мне конечно ближе по духу второй путь, ибо Оберон-07 имеет слишком мало средств для удобной разработки. И не имеет удачных решений, воплощённых в языке КП, которые мне очень нравятся.

Основная проблема,имхо, в том и заключается, что даже теоретически нет хорошей системы, работающей и со знаковыми и с беззнаковыми числами. Мы не только не знаем как реализовать, мы не знаем даже что надо реализовать.

Да уж, код который я уже написал для реализации FOR раз в 10 превышает первоначальную реализацию через WHILE. И это еще не конец... Надеюсь, что не понадобится выносить генерацию FOR в отдельный модуль

Хорошо, пусть на первых порах будет библиотека. Может быть практика поможет создать теоретическую базу, которой пока нет. Будем использовать c := Unsigned.Add8(a, b);, вот и увидим когда это нужно и что из этого получается.
Преимущества такого подхода не только в легкости реализации, но еще и в наглядности. c := Unsigned.Add16(a, b) - сразу видно, что это такое. А вот смысл c := a+b скрыт "синтаксическим сахаром". На данном этапе это только запутает. Вот выясним, как, когда и для чего следует употреблять беззнаковые числа, тогда можно и "подсластить" для удобства.
Так что, пусть будет библиотека. А потом можно постепенно и новые типы ввести, и операции, когда на библиотеке обкатаем.
А вот не помешает ли уже на этом этапе приведение типов самого С? Ведь мы транслируем в Си, где, например, все однобайтовые операнды приводятся к int. Разберется ли потом с этим компилятор Си->ассемблер? Как это регулировать на уровне Офронт? Ведь в конце концов, мы беззнаковые числа и завели для эффективной реализации в машинном коде, и нужно чтобы до этого кода дошли оптимальные операции с байтами.
Имеется в виду однобайтовый CHAR, который в ББ называется SHORTCHAR?
Ну, не знаю, стоит ли использовать CHAR только ради барьера. И нужен ли барьер? Барьер, конечно, предотвратит путаницу между этими типами, но он же помешает и увидеть общее. Так в общем диапазоне 0..127 нет разницы между знаковыми и беззнаковыми, а этот диапазон не так и мал, включает, например, координаты знакоместа. Да и как быть с 2-байтовыми беззнаковыми, для них допустим путаницу? Может быть всё-таки, для внутреннего представления беззнаковых использовать знаковый того же размера?

Кое-что можно применить в CASE и FOR как уже предлагалось. Хотя, конечно, это тоже не универсальный путь. Что же, практика укажет нам узкие места, которые мы и будем постепенно расширять.

С этим согласен. Но опять следует вспомнить про стандартное приведение типов в Си и Джаве, которое может помешать.

Я этим занимаюсь. Но стоило немножко подальше отступить от первоначальной реализации, как выяснилось, что мое представление о механизмах Ofront было поверхностным. Он несколько иначе устроен, чем я думал.
Но нет худа без добра. Изучение тонкостей Ofront может пригодиться не только для реализации FOR. К сожалению, сейчас не могу уделять этому много времени.

Что же, можно обойтись пока библиотечными средствами.

Как уже писал выше, согласен, давай обкатаем на библиотеке. Вот только, боюсь, мало найдется людей для обкатки.