| OberonCore https://forum.oberoncore.ru/  | 
|
| Почему BYTE не 0..255? https://forum.oberoncore.ru/viewtopic.php?f=29&t=6747  | 
	Страница 1 из 2 | 
| Автор: | kekc_leader [ Среда, 24 Март, 2021 04:17 ] | 
| Заголовок сообщения: | Почему BYTE не 0..255? | 
В Обероне-07 Вирт ввёл тип BYTE как целочисленный тип из диапазона от 0 до 255, что логично. В КП этот тип имеет диапазон -128..127. Зачем так сделано?  | 
	|
| Автор: | Иван Денисов [ Среда, 24 Март, 2021 04:44 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Набор типов КП приводили к Java, наверное поэтому и BYTE получился таким. Код: To achieve fully portable code, it is necessary to fully specify the domains of all base types. The Component Pascal base types are a superset of the Java base types. Type Size Domain SHORTCHAR 1 byte Latin-1 character set (first Unicode page and a superset of ASCII) CHAR 2 byte Unicode character set BYTE 1 byte signed integer SHORTINT 2 byte signed integer INTEGER 4 byte signed integer LONGINT 8 byte signed integer SHORTREAL 32 bit IEEE REAL 64 bit IEEE SET 4 byte bitset BOOLEAN 1 byte FALSE or TRUE А уж почему так решили сделать в Java... https://javarush.ru/groups/posts/630-pr ... imitivnihe https://stackoverflow.com/questions/362 ... 7#42623517  | 
	|
| Автор: | Info21 [ Среда, 24 Март, 2021 09:56 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Возможно, это одно из тех решений, которые надо принимать, подбрасывая монетку.  | 
	|
| Автор: | Oleg N. Cher [ Среда, 24 Март, 2021 11:06 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Просто был нужен байтовый тип со знаком, чтобы была линейка целочисленных типов всех размеров. Вот его и назвали BYTE. Можно было оставить SHORTINT (1) -> INTEGER (2) -> LONGINT (4) -> HUGEINT (8), но от этого решили уйти, что имхо правильно. Можно было SHORTINT оставить байтовым, а ввести какое-то новое имя типа для двухбайтового. Или, как предлагал Артур: назвать байтовый тип со знаком TINYINT. Но пошли по пути наименьшего сопротивления. Байт нужен? Нужен. Он есть? Есть. В Обероне-2 SYSTEM.BYTE часто тоже со знаком? Да. Ну вот и решение: вытащим BYTE из SYSTEM на свет божий и поставим в линейку целых. Все целочисленные типы - со знаком.  | 
	|
| Автор: | Борис Рюмшин [ Среда, 24 Март, 2021 16:17 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Да нет, тут дело не в том, что вытаскивали откуда-то BYTE, а, как совершенно правильно говорит Иван, из-за приведения системы типов под совместимость с Java. Знаковый BYTE, конечно, раздражает, когда приходится разные протоколы обрабатывать.  | 
	|
| Автор: | Comdiv [ Среда, 24 Март, 2021 20:10 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Борис Рюмшин писал(а): Знаковый BYTE, конечно, раздражает, когда приходится разные протоколы обрабатывать. Как боретесь? byte MOD 100H или  ORD(shortchar)?Кстати, тема как-будто для этого раздела  | 
	|
| Автор: | adimetrius [ Среда, 24 Март, 2021 23:15 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Comdiv писал(а): Как боретесь? byte MOD 100H или  ORD(shortchar)? Ну вот жеж умные люди посоветовали: Comdiv писал(а): Код: j := i MOD 100H; b := SHORT(SHORT(j - j DIV 80H * 100H)); А еще можно вот так: Код:    PROCEDURE [ code ] Shortchar (b: BYTE): SHORTCHAR;   (* пустая процедура - бестелесная ) *) PROCEDURE P; VAR ch: SHORTCHAR; b: BYTE; BEGIN b := -1; ch := Shortchar(b); ch := SHORT(CHR(b MOD 100H)) END P; ch := Shortchar(b); 0000077FH: 8A 45 FE mov al, -2[ebp] 00000782H: 88 45 FF mov -1[ebp], al ch := SHORT(CHR(b MOD 100H)) 00000785H: 0F BE 45 FE movsx eax, byte ptr -2[ebp] 00000789H: 25 FF 00 00 00 and eax, 000000FFH 0000078EH: 88 45 FF mov -1[ebp], al А с включенными проверками: Код: ch := SHORT(CHR(b MOD 100H)) 
		
		000007A2H: 0F BE 45 FE movsx eax, byte ptr -2[ebp] 000007A6H: 25 FF 00 00 00 and eax, 000000FFH 000007ABH: 3D FF 00 00 00 cmp eax, 255 000007B0H: 76 02 jbe 2 (000007B4H) 000007B2H: 8D E6 illegal (TRAP -6) 000007B4H: 88 45 FF mov -1[ebp], al  | 
	|
| Автор: | Илья Ермаков [ Четверг, 25 Март, 2021 00:38 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Ха, какая интересная возможность: кодовая бестелесная процедура, по сути, позволяет сделать бесплатный (по времени выполнения) "преобразователь" на сигнатуру.  | 
	|
| Автор: | Wlad [ Четверг, 25 Март, 2021 14:18 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
adimetrius писал(а): Ну вот жеж умные люди посоветовали: ... Это называется: "Как мы боролись со сложностью и сражались за строгость, простоту и однозначность..."? Что такое "бестелесная" процедура в рамках базовых принципов оберонов? Насколько ЛИЧНО МНЕ видится, правильным было бы что-то вроде полного объявления всех разновидностей типов: 1) как это сделано в сях ( [|u]int[8|16|32|64|...]_t ) 2) что-то, вроде "а ля Зоннон": INT{EGER}( S|U, SIZE, format ), где SIZE - СОВСЕМ НЕ ОБЯЗАТЕЛЬНО кратно степени 2 Примеры: INT(U,32,le), INTEGER(S,16,BIG)  | 
	|
| Автор: | adimetrius [ Четверг, 25 Март, 2021 17:41 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Wlad писал(а): Насколько ЛИЧНО МНЕ видится, правильным было бы что-то вроде полного объявления всех разновидностей типов:... А для чего нужны беззнаковые? в каких задачах? Единственное место, где я столкнулся с необходимостью их отдельно обрабатывать - это сравнение адресов памяти. В остальных случаях (с которыми я работал), даже для представления адресов подходят знаковые; в сравнении нужно другие флаги анализировать, иначе 1 > 0FFFFFFFFH. Такая потребность возникла у меня лишь раз - в анализе стека активаций. Проблема с большим "зоопарком" типов - выбор: ведь каждое инженерное решение должно быть обосновано )) замучаешься обосновывать. А тут - есть тип INTEGER, и обоснование неплохое: а) его достаточно для прикладных задач и б) он совпадает с операндом процессора по умолчанию.  | 
	|
| Автор: | Пётр Кушнир [ Четверг, 25 Март, 2021 20:00 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Байт это протёкшая абстракция машины  | 
	|
| Автор: | adimetrius [ Четверг, 25 Март, 2021 23:28 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Пётр Кушнир писал(а): Байт это протёкшая абстракция машины  Плюсую!  | 
	|
| Автор: | Wlad [ Пятница, 26 Март, 2021 01:26 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
adimetrius писал(а): А для чего нужны беззнаковые? в каких задачах? Адресуйте, пожалуйста знаковым все 4 Гига адресного пространства. (Или у вас адрес 0 будет "посередине" физического адресного пространства? Пожалуйста, сдвиньте вправо нечто, что в вашем представлении является -1 в допкоде, но так, что бы слева приехал 0 в старший разряд. Есть очень интересные архитектуры. Миром правит уже ДАЛЕКО не Джава на платформе х86. Могу Вас заверить, что в мире эмбеддинга и системного, низкоуровневого, программирования, мне более удивительным представляется НАЛИЧИЕ ЗНАКОВЫХ ТИПОВ.  | 
	|
| Автор: | Борис Рюмшин [ Суббота, 27 Март, 2021 00:13 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Эта проблема лежит в той же плоскости, что и разрядность INTEGER. У нас же регулярно споры возникали, что с ним делать при переходе к КП64 -- сдвигать или оставлять 32-битным. А если оставлять, то эффективность вычислений упадёт. В чисто системном плане я согласен с Владимиром: там нужен полный комплект типов с точной разрядностью. Вы криптографию или протоколы связи с коррекцией ошибок попишите -- там умахаться можно выписывая всякие преобразования. Это не очень частые задачи, но случаются. Можно этот набор полностью в SYSTEM заткнуть, чтобы включалось только тогда, когда надо. А так то да, я за абстрактность и удаление от машины. На сколько это возможно.  | 
	|
| Автор: | Борис Рюмшин [ Суббота, 27 Март, 2021 00:15 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Илья Ермаков писал(а): Ха, какая интересная возможность: кодовая бестелесная процедура, по сути, позволяет сделать бесплатный (по времени выполнения) "преобразователь" на сигнатуру. Это опасный хак, который в другой реализации может просто не работать.  | 
	|
| Автор: | Info21 [ Суббота, 27 Март, 2021 08:54 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Борис Рюмшин писал(а): Вы криптографию или протоколы связи с коррекцией ошибок попишите -- там умахаться можно выписывая всякие преобразования. Это не очень частые задачи, но случаются. "не очень частые" -- в эту (недо)оценку вложено ещё то, что они менее заметны в силу более узкой специализации.
		
		 | 
	|
| Автор: | adimetrius [ Суббота, 27 Март, 2021 14:03 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Выходит, как я и предполагал, беззнаковая арифметика нужна в узкоспециальных системнопрограммных задачах. И если так, ей всамделе место в SYSTEM, или CRYPTO. Хотя при нынешней внутренней архитектуре компилятора - для синтезатора кода это абсолютно все равно, ему по-любому все M*M сочетаний базовых типов нужно перебирать. Борис Рюмшин писал(а):  Вы криптографию или протоколы связи с коррекцией ошибок попишите -- там умахаться можно выписывая всякие преобразования. Это не очень частые задачи, но случаются. Можно этот набор полностью в SYSTEM заткнуть, чтобы включалось только тогда, когда надо. Или, опять-таки, грамотно сделать набор кодовых процедур под задачу. Да, они не переносимы (непереносимы:)), поэтому "живут" в SYSTEM. Сейчас согласно Platform-specific issues действует соглашение "вызова" для кодовых процедур, что первый аргумент передается в аккумуляторе, прочие - в стеке, и результат возвращается в аккумуляторе. Можно его дополнить, передавать 2 аргумента в регистрах, и т.д. Рискну предположить, что для криптографии или др задач вообще полезно с битовыми цепочками работать. А этого в универсальном ЯВУ вообще нет, и поделом. Борис Рюмшин писал(а): Илья Ермаков писал(а): Ха, какая интересная возможность: кодовая бестелесная процедура, по сути, позволяет сделать бесплатный (по времени выполнения) "преобразователь" на сигнатуру. Это опасный хак, который в другой реализации может просто не работать. В другой реализации чего? Если SYSTEM соответствует P-S-I, то в чем опасность? На крайний случай легко переделать: Код: PROCEDURE Shortchar (b: BYTE): SHORTCHAR; 
		
		BEGIN RETURN SHORT(CHR(b MOD 100H)) END Shortchar;  | 
	|
| Автор: | Comdiv [ Суббота, 27 Март, 2021 14:08 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Wlad писал(а): Адресуйте, пожалуйста знаковым все 4 Гига адресного пространства. (Или у вас адрес 0 будет "посередине" физического адресного пространства?  В самой адресации знаковым целым нет никакой проблемы, просто верхние адреса будут отрицательными. Только делать этого не нужно, потому что адрес - это отдельный тип, который нежелательно вставлять ни в целые со знаком, ни в целые без знака.Wlad писал(а): Пожалуйста, сдвиньте вправо нечто, что в вашем представлении является -1 в допкоде, но так, что бы слева приехал 0 в старший разряд.  Если нужно думать о 0 и 1 в двоичных разрядах, то речь опять не о целых, а об отдельном типе - о чём-то вроде битовых массивов. В терминах чисел такое тоже делается, но не специфично для представления - численно результат будет одинаковым хоть в троичной системе.Wlad писал(а): Могу Вас заверить, что в мире эмбеддинга и системного, низкоуровневого, программирования, мне более удивительным представляется НАЛИЧИЕ ЗНАКОВЫХ ТИПОВ.  Во многом благодаря тому, что так заведено, а не потому что иначе никак. Это данность которую, конечно, нужно учитывать, но и не преувеличивать.Либо за максимальную типизацию, либо за свалку применений в целых. Борис Рюмшин писал(а): что с ним делать при переходе к КП64 -- сдвигать или оставлять 32-битным. А если оставлять, то эффективность вычислений упадёт. Почему упадёт? Вычислять не обязательно в той же разрядности, что хранить. Разница будет в переполнении, но согласно описанию языка на неё нельзя рассчитывать.adimetrius писал(а): Рискну предположить, что для криптографии или др задач вообще полезно с битовыми цепочками работать. А этого в универсальном ЯВУ вообще нет, и поделом. Для криптографии, вообще, лучше использовать специальные языки с формальными доказательствами с последующей трансляцией(экстракцией, как это принято называть в этой области).
		
		 | 
	|
| Автор: | Борис Рюмшин [ Суббота, 27 Март, 2021 15:55 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
adimetrius писал(а): В другой реализации чего? Если SYSTEM соответствует P-S-I, то в чем опасность? На крайний случай легко переделать: Код: PROCEDURE Shortchar (b: BYTE): SHORTCHAR; BEGIN RETURN SHORT(CHR(b MOD 100H)) END Shortchar; Можно. Потенциальную проблему указал просто.  | 
	|
| Автор: | Wlad [ Воскресенье, 28 Март, 2021 10:53 ] | 
| Заголовок сообщения: | Re: Почему BYTE не 0..255? | 
Comdiv писал(а): В самой адресации знаковым целым нет никакой проблемы, просто верхние адреса будут отрицательными. Вы перечитываете. то, что написали, перед тем, как отослать?Comdiv писал(а): Только делать этого не нужно, потому что адрес - это отдельный тип, который нежелательно вставлять ни в целые со знаком, ни в целые без знака. 1. Адрес - ЧЕГО (какого типа)?2. Если вы работаете с "чисто адресами", озвучьте СМЫСЛ отрицательного (не "относительного") АДРЕСА. 3. Есть понятие "счёТное (упорядоченное) множество". Дальше - продолжать? 4. Во многих РЕАЛЬНЫХ системах регистры управления и состояния внешних устройств отображены на адресное пространство. Дальше - продолжать? Comdiv писал(а): Если нужно думать о 0 и 1 в двоичных разрядах, то речь опять не о целых, а об отдельном типе - о чём-то вроде битовых массивов. И? Вы когда-нибудь видели даташиты на ядра микроконтроллеров и их периферию? У таймеров обычно выставляются коэффициенты деления входной частоты. Можете мне озвучить смысл ОТРИЦАТЕЛЬНОГО значения коэффициента пересчёта? Длина информационной части при передаче по последовательному порту может быть от 5 до 9 бит. Для её представления используется 3-4 бита в определённом регистре управления. И, кстати, значения многих параметров, в таких полях регистров конфигурации/правления/состояния очень часто задаются ПЕРЕЧИСЛИМЫМ ТИПОМ (дальше - продолжать? Или вы предлагаете "лишний" "знаковый битик" аппаратчикам реализовывать, только, что бы соответствовать стройной картинке мира? Так в реальном мире инженеры-электронщики за каждый нано- и пиковатт сейчас сражаются... Comdiv писал(а): Wlad писал(а): Могу Вас заверить, что в мире эмбеддинга и системного, низкоуровневого, программирования, мне более удивительным представляется НАЛИЧИЕ ЗНАКОВЫХ ТИПОВ.  Во многом благодаря тому, что так заведено, а не потому что иначе никак. Это данность которую, конечно, нужно учитывать, но и не преувеличивать.Comdiv писал(а): Либо за максимальную типизацию, либо за свалку применений в целых. Так она там и присутствует.Comdiv писал(а): Борис Рюмшин писал(а): что с ним делать при переходе к КП64 -- сдвигать или оставлять 32-битным. А если оставлять, то эффективность вычислений упадёт. Почему упадёт? Вычислять не обязательно в той же разрядности, что хранить. Разница будет в переполнении, но согласно описанию языка на неё нельзя рассчитывать.Это - помимо отслеживания случая переполнений и их обработки по "не основным" ветвям алгоритма вычислений. Упоминание "нерассчёта согласно описанию языка" осталось загадкой. Comdiv писал(а): adimetrius писал(а): Рискну предположить, что для криптографии или др задач вообще полезно с битовыми цепочками работать. А этого в универсальном ЯВУ вообще нет, и поделом. Для криптографии, вообще, лучше использовать специальные языки с формальными доказательствами с последующей трансляцией(экстракцией, как это принято называть в этой области).А криптовать лучше - вообще отдельными функциональными железячными блоками в процессорах.  | 
	|
| Страница 1 из 2 | Часовой пояс: UTC + 3 часа | 
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/  | 
|