OberonCore

То, что Вас смущает, что верхние адреса при отображении в знаковые целые, как, например, это делается в BlackBox Component Builder через SYSTEM.ADR, будут отрицательными числами - это только Ваши проблемы, но не мои. Я лишь пишу о факте, а моё мнение, что так делать не надо, ровно как как и с отображением в целые без знака, я тоже писал.


1. Адрес данных, какими бы они не были
2. Вопрос слишком уж странный, учитывая что задаётся в виде комментария к ответу, что адрес не нужно засовывать в числа. Но если уж засунули, то это просто число, отличающееся от других адресов-чисел. Не нужно их трактовать именно как числа, иначе легко начать сравнивать несравнимое, складывать нескладываемое и т.д., о чём, в том числе, сказано в стандарте C. Особенно это характерно для платформ вроде Эльбрус, но и для распространённых 64-битных платформа не всё так просто, особенно, в связке с языками наподобие Swift.
3-4. Продолжайте, продолжайте.

То есть, опять речь о том, что так было заведено.

Это никак не влияет на представление целых. "В огороде бузина".

"Так заведено" не сводится к моде и привычке. Если конкретно Ваша специфика требует изо всех сил того, что Вы обозначаете за именно необходимое, то это Ваша специфика. Если коллеги, которые занимаются встроенными приложениями на Oberon-07, на самом деле тоже страдали от нехватки нужных типов, было бы интересно послушать. Если что, то в O7 BYTE как раз 0..FF в отличии от КП, но беззнакового INTEGER нет, по крайней мере, в оригинале.

Только если через кривое зеркало C. Максимальная типизация не так выглядит. Впрочем, и не эдак, скажут сторонники зависимых типов .

Это в любом случае нужно делать, потому что увеличение расхода памяти из-за внезапного удвоения размера INTEGER отрицательно скажется на общей производительности.

Для меня осталось загадкой, что для Вас загадка в том, что правильная программа на КП не может рассчитывать на определённое значение после переполнения, из-за чего поведение правильной программы не может измениться после перехода с 32-х битных вычислений на 64-х битные. Неправильные диагностируются прогоном после компиляции с включёнными проверками, которые были саботажно выключены по умолчанию.

Создатели блоков в процессорах всегда используют исходную модель на языке для компьютера, так что тут ничего принципиально не меняется, просто добавляется либо дополнительный этап ручной трансляции, либо сразу "экстракция" в HDL.

А вы - точно работали в тех областях, о "традициях" которых силитись рассуждать и изменить "в правильном направлении"?
Или это - очередное Ваше "в загали по загалям" из общих соображений?

Судите о ценности чужих суждений по цене собственных?

Стараюсь высказываться о тех вещах, в которых я понимаю по тем или иным причинам. Если суждения делаются на основе предположений или поверхностных знаний, то они сопровождаются соответствующими словами или контекстом. Недоразумения могут быть, но это обычная вещь. В мире травмированных своим опытом ничего изменить не пытаюсь(понимаю Дейкстру), наоборот, постоянно предлагаю не рассчитывать на изменения в mainstream и идти своим путём без ожидания "пока весь мир не поменяется".

Программы для встроенных систем и разрабатывал лично, и руководил в небольших проектах. Многим нравилась моя архитектура с принципом самоописываемых устройств (это мой общий подход(и здесь это "вообще")).

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

Или вы не согласны, что необходим минимально полный и непротиворечивый набор средств работы со ВСЕМИ формами представления чисел на ЛЮБОЙ архитектуре?

Постойте, язык высокого уровня предназначен для отображения понятий предметной области. Абстрактные типы данных и все такое.
А для отображения понятий архитектуры ЭВМ, в т.ч. форм представления чисел - предназначены другие языки - макроассемблеры, например. Тут тебе и регистры напрямую, и двоично-десятичные, и все такое.
Разные задачи - разные средства.
Разве нет?

ВСЕХ форм представления чисел СЛИШКОМ много.

а - что, кто-то говорит за китайские счёты?

Я считаю, что BYTE должен иметь значения от 0 до 255, потому что это наиболее простая форма представления значения 8-битника.

Так как показ такого юмора уровня 4-х летнего ещё не приговор, то, наверно, Вы сможете принять, что другие люди могут отклоняться от "единственно правильной" линии беседы, находящейся исключительно внутри Вашей головы. Если хотите во что бы то ни стало понять, в чём связь, то трактуйте это так - задачи решал, проблем не испытывал.

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

А я бы предпочел иметь BYTE нечисловым типом.

Нечисловой тип уже есть -- SHORTCHAR, или вам нужен ещё один?

Типа, BYTESET?

Типа того. Но он не должен включаться в SET. Все приведения только явные.

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

Вы окончательно хотите утвердить, что Вам ЛИЧНО достаточно в программировании оперирования только над полем целых знаковых? Таки я Вам имею сказать, что пусть этот любопытный казус остаётся Вашим личным ГЛУБОЧАЙШИМ убеждением. И - заблуждением.

Ветераны форумов и тем по оберонам помнят, ещё наверное, мой крайний радикализм конца 90-х-начала 00-х... Так я Вам скажу, что жизнь и работа в "поле" немножко заставила пересмотреть свой максимализм. Если с Вами этого не произошло, остаётся или позавидовать, или привлечь узкоспециализированных медспециалистов.

Вы так и не осознали до конца, для чего нужна модульность, и о чём были мои конкретные возражения, отсюда и ложные выводы о моих утверждениях. Это Ваш очередной диалог самого с собой.

По-моему, вам уже - точно медпомощь нужна. Поверьте, я искренне огорчён и скорблю.

Всё просто - думать что осознаёте, и действительно осознавать - это не одно и то же. Вот, например, в этом сообщении Вы, ведь, тоже выражали нереализованное желание сейчас делать проекты, в том числе, на Обероне, но во многих сообщениях и в этой теме Вы ярко показываете, что на самом деле не осознаёте, что такое программировать на Обероне и зачем в нём так сделано. Вот и модульность осознаёте не до конца, и как стоит поступить с типами для особых случаев, учитывая модульность.

И эти слова про медпомощь - это же о Вас гораздо больше говорит, чем обо мне. Вам только и остаётся выдумывать утверждения "сопернику" и с наслаждением его "побеждать"? Но это только говорит, что Ваши истории, вероятно, стоит делить на 10 для правильной оценки. Тот же рассказ с консилиумом по 2-х связному списку(!) выглядит очень подозрительно

Уууууу... Как всё запущено. "В огороде - бузина, а в Киеве - дядька" - это ещё мягко сказано.
Я нисколько не хочу вас лично унизить. Просто по способу и стратегии пострения вашей аргументации и согласованности её пунктов, и яркому, явному приписыванию оппонентам смысла высказываний и точек зрения, которые являются лишь продуктом вашей фантазии, я вам серьёзно уже советую: обратитесь к доктору по мозгам. У вас - какая-то вавка там.

Надоело фактически общаться со своим кривым отражением, преломляя слова собеседника через свои сознание и понимание себя, и Вы решили ещё и зеркалить обращённые к Вам слова, приправляя это лексикой, которая "не" должна унизить?

Так уточните, пожалуйста, для примера - когда Вы писали о том, что Вы будете создавать код на C и С++, потому что Вам не попадаются проекты, в том числе, на Oberon, Вы понимали, что в Oberon сознательно не было задействовано беззнаковых целых, и без внесения изменений в язык, программируя на нём, Вам бы пришлось "бомбить" не меньше, чем Вы "набомбили" в этой теме? Это фантазия?

А вы, сударь, - наглец. Я скидываю это - лишь на подверженность большинства индивидуумов локальному мощному ментальному прессингу и пропаганде. Не у многих хватает силы просто "выпасть" из-под их влияния, что бы не получить "отпечаток" на мировидение и способ мышления.
Это - только если не брать во внимание вариант уже озвученный мной.

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

Сила языка - не только в лёгкости и эстетичности явления мысли конструктора какой-то системы, но и - В ВОЗМОЖНОСТИ УМОЛЧАНИЯ чего-то. Если в языке чего-то нет и нет возможности легко нарастить это что-то пользователю (как в Форт-ах или Лисп-ах), то приходится тащить в проектах эстетически-идеологически-тяжеловесные части кода и получать неэффективный и неоптимизированный код на выходе.
Если в языке НЕТ базовых механизмов конструирования типов, равных (по лёгкости оперирования в программе, на уровне исходного текста и - по эффективности обработке в рантайме) "встроенным", то что бы ты не предлагал в дальнейшем, это будет и выглядеть, и работать, как "залепуха". На всех уровнях представления системы и реализации программы.

Тем более не понятно упорство, когда многолетний отказ (и постулирование его даже в "стандартах" - к языку и системе исполнения!) от базовых возможностей объявления и манипулирования всем спектром целых. То есть, даже в самом низу, где следовало бы дать возможность гибко определять базис представления информации, взяли и отсекли не только наличие априори легкости манипулирования, представления и "выражения смысла" через целые разной природы, но и саму возможность лёгкого введения таких типов и операций над ними. При этом были отсечены огромные пласты возможностей в решении более мощного множества задач.

Мне, как эмбеддеру, с огромным опытом применения ООП, например, совершенно естественным видится правило получения знака результата после сдвигов значений целых. Более того, сами операции сдвигов вправо или влево, по этим свойствам, естественным образом, попадают в логичную категорию "виртуальных"/"перегруженных" (по своим аргументам). А теперь вспомните "интересности", которые могут возникнуть со сдвигами, при портировании Си/Си++ кода в, например, тот же Борланд Паскаль или Дельфи. Забылось? Или - никогда не попадалось? А мне - "попадалось". Результатом становились, чаще всего, строки на встроенном ассемблере.

Складывается уродская ситуация.
С одной стороны, душа, свидетельства опыта проектов, личные предпочтения - тянутся к виртовским языкам. С другой, сталкиваешься с совершенно искажённой картинкой подхода к формированию некоторых базовых, низкоуровневых вещей; и приходится делать, не относящуюся к делу, работу, о необходимости которой в Си даже мысль не закрадывается.
Получается, что будучи совершенно выдающимся явлением с точки зрения построения систем "в большом" и формирования (и описания) архитектурного облика проектируемых систем, эта группа языков вынуждает нас уделять неоправданно большое внимание вещам, которые должны были "намертво вмурованы" в базис языка.