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 , а format - описатель расположения байтов и битов в числе (знакового и порядок) Примеры: 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/ |