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

Твердыня модульных языков
Текущее время: 16 апр 2024, 21:30

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




Начать новую тему Ответить на тему  [ Сообщений: 36 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: 23 авг 2019, 16:25 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Благодарю, что спросили. Нужет ответ для пытливого ума, а не по верхушечкам. Я постараюсь ответить.

Конкретно в реализации Оберона в Ofront'е+ для любых операций разрядностью <= int применяется неявное преобразование в базовый тип int. При этом на 32-битном таргете он 32 бита, а вот, допустим, на 8-битном Z80 он 16 бит. Так принято в Си. В Си не реализованы операции конкретно над байтовым размером, они всегда производятся над >= int. При этом оптимизатор может конечно потом оптимизировать такие операции до конкретно байтовых, но без потери точности.

В нативном ETH Oberon результат байтовых операндов тоже будет, как минимум, двойным, т.е. 16-битным. Просто ETH Oberon не приводит его к этому типу явно, давая обратно присвоить результат переменной типа INT8 (хотя для INT8 здесь возможно переполнение и искажение).

BlackBox же и Компонентный Паскаль, как я это понимаю, неявно кастует разрядность операций над операндами размером <= 32 именно к 32-битам. И поскольку мы позиционируем Оберон-3 для таргетов различной разрядности, то есть смысл вернуться к поведению, принятом в Обероне и Обероне-2. Здесь ничего нового не выдумано, просто мы не хотим иметь 32-битность там, где она излишняя.

В то же время, для 8-битного таргета (опция -C21) я реализовал поведение Компонентного Паскаля так, что минимальная разрядность операций в нём составляет 16 бит. Но это отход от описания языка в пользу 8- и 16-битных таргетов. Просто обкатываем, как покажется лучше. Так что это две стратегии: Оберон-3 требует для результата байтовых a+b типа как минимум INT8, а КП с опцией -C21 как минимум типа INT16. Но и в КП, и в Обероне-3 результат для приведённого выше кода будет составлять +128, т.е. правильный.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 23 авг 2019, 20:09 
Не в сети

Сообщения: 35
Благодарю за развернутый ответ.
Значит, правила совместимости по выражению и по присваиванию как в Обероне-2.
С одним уточнением: есть "нормальный" целочисленный тип, который зависит от таргета. Вычисления над короткими типами выполняются в границах "нормального" типа. Конечный результат может быть усечен до размера получателя, если, конечно, получатель совместим по присваиванию с выражением.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 24 авг 2019, 12:02 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Да, всё сформулировано правильно.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 30 авг 2019, 16:26 
Не в сети
Аватара пользователя

Сообщения: 67
Откуда: Equestria
Есть планы по выпиливанию неструктурированных операторов EXIT и RETURN?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 30 авг 2019, 16:36 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Таких планов нет. Кто обходится — может и так не пользоваться.

Я видел достаточно кода, который при переписывании без EXIT и RETURN только потеряет — усложнится и станет более запутанным.

EXIT и RETURN остаются в моём понимании неким люфтом, который всё равно неизбежен в "большой" (в смысле, не игрушечной) разработке. И это даже лучше, что он есть.

Другое дело, если в основу разработки положены специальные усиленные требования, допустим, к надёжности, но они к любому ЯП применимы (в виде использования или неиспользования тех или иных средств этого ЯП).


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 08 сен 2019, 02:21 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Обнаружилась интересная особенность при использовании VAR [nil] в биндингах. Если вызвать процедуру, передавая ей в качестве переменной NIL, то наша доработка требует также присутствия @. Получается так:

Код: "OBERON"
  1. WinAPI.WriteFile(hConOutput, SYSTEM.ADR(str), Strings.Length(str), @maxLen, @NIL);

Подумав, я решил не выпиливать. Довольно выразительно: нужна переменная, а мы вместо неё передаём NIL, и не просто как значение, а как ссылку. В любом случае, возможность системная, так что часто встречаться не будет.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 09 сен 2019, 20:18 
Не в сети

Сообщения: 146
Нужен ли такой механизм в привязках? Раз уж возможен NULL, то, на мой взгляд, логичней честно указывать тип-указатель. Необходимость потом использовать SYSTEM.ADR для фактических переменных тоже вполне нормальна.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 09 сен 2019, 22:41 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Константин, у нас нет указателей на переменные, помните? Только на записи и массивы. Или Вы предложите создавать в таких случаях указатель на массив на 1 элемент? Так ему нельзя будет переменную передать. Тоже плохая идея, лишняя сущность. А использовать просто безтиповый адрес — будет громоздче и даже ненадёжнее. Мало ли что туда передадут.

Вместо всего этого можно просто ввести понятие "системная ссылка определённого типа, которая может быть NIL". И SYSTEM.ADR на такой переменной вернёт 0. Так и поступили, и это очень разумное решение. А Вы, следуя букве, можете это называть не ссылкой, а системным указателем, не связанным со сборкой мусора.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 10 сен 2019, 18:17 
Не в сети

Сообщения: 146
Zorko писал(а):
У нас нет указателей на переменные, а только на записи и массивы
Их нет в Обероне, а в расширенном языке привязок есть всё, что Вы захотите. VAR[nil], например, тоже нет в оригинале. В любом случае, я не настаиваю.

Цитата:
Или Вы предложите создавать в таких случаях указатель на массив на 1 элемент?
Я, естественно, этого не предлагал. Подождали бы, что ли.

Цитата:
Так ему нельзя будет переменную передать. ... А использовать просто безтиповый адрес — будет громоздче и даже ненадёжнее. Мало ли что туда передадут.
На мой взгляд, привязки желательно вызывать не больше одного раза - из нормальной Оберон-обвязки, в интерфейсе которой нет прямых завязок на нижний уровень с безтиповыми указателями и любыми другими особенностями. Поэтому и беспокоится о невозможности передачи чего-либо или об ошибках в передаче преременной не того типа нет большой нужды, потому что один раз ошибиться в заголовке привязки или один раз ошибиться в вызове, на первый взгляд, выглядит эквивалентно. То есть, желательно, чтобы пользователю обвязки не нужно было знать о не обероновских особенностях нижнего уровня. В конце концов с такими указателями могут быть и другие проблемы, например, с выравниванием или чем угодно ещё. Все проблемы проще решать в единственной обвязке, чем в богатом языке привязок.

Цитата:
следуя букве, можете это называть не ссылкой, а системным указателем
Вопрос был не в том, как это называть, а нужно ли это.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 10 сен 2019, 18:24 
Не в сети

Сообщения: 146
Кстати, этот параметр - указатель на довольно замороченную структуру https://docs.microsoft.com/ru-ru/windows/win32/ap ... nbase/ns-minwinbase-overlapped


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

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


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

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


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

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club