Есть ли в настоящее время используемая система с компилятором C++, где int имеет ширину более 32 бит?

Стандарт C++ говорит только о том, что ширина int должна быть не менее 16 бит. И, по крайней мере, согласно cppreference, он почти всегда имеет ширину 16 или 32 бита:

data model       int width in bits
----------------------------------
C++ standard     at least 16
LP32             16
ILP32            32
LLP64            32
LP64             32
...

Другие модели очень редки. Например, ILP64 (8/8/8: int, long и pointer являются 64-разрядными) появился только в некоторых ранних 64-разрядных системах Unix (например, Unicos on Cray).

Есть ли пример используемой в настоящее время системы с компилятором C++, где int имеет ширину более 32 бит? Под используемым в настоящее время я имею в виду, например, некоторая старая система, возможно, все еще активно используется конкретной отраслью, потому что есть веская причина использовать ее для этой конкретной задачи и которую нельзя разумно заменить чем-то другим. Предпочтительно это будет что-то, что активно разрабатывается/работает, а не просто система, работающая на унаследованном коде, который не затрагивался в течение 20 лет. Современная система с, например, 64-битной int, которая используется для научных вычислений, также была бы отличным ответом.

Я не ищу систему, которая использовалась 2 года в 90-х, а затем была полностью сброшена. Я также не ищу что-то, что используется только в качестве хобби для игры, или какую-то старую систему, которую используют две компании в мире только потому, что они слишком дешевы для обновления.

Ответ 1

Пожалуйста, обратите внимание, что этот ответ задуман как каркасный вызов; что даже 64 операционные системы обычно не хотят> 32 бит из-за нескольких моментов. Это означает, что вряд ли команда приложит усилия для создания операционной системы, не приняв во внимание эти моменты и еще менее вероятно, что она не устареет к этому моменту времени. Я надеюсь, что будет найден более прямой ответ, но я думаю, что это оправдывает, по крайней мере, основные решения операционной системы.

Для начала вы правы, что черновик C++ разрешает использовать обычные целые числа, размер которых может превышать 32 бита. Цитировать:

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

^{Emphasis mine}

Казалось бы, это говорит о том, что на моей 64-битной архитектуре (и на всех остальных) обычный int должен иметь 64-битный размер; что размер, предложенный архитектурой, верно? Однако я должен утверждать, что естественный размер даже для 64-битной архитектуры составляет 32 бита. Цитата в спецификации в основном там, где желательны 16-битные обычные целочисленные значения.

Соглашение является мощным фактором, переходящим от 32-битной архитектуры с 32-битным простым int и адаптации этого источника для 64-битной архитектуры проще, если вы оставите его 32-битным, как для разработчиков, так и для пользователей двумя различными способами:

Во-первых, чем меньше различий между системами, тем проще для всех. Несоответствия между системами были лишь головной болью для большинства программистов: они только усложняют выполнение кода в разных системах. Это даже добавит к относительно редким случаям, когда вы не сможете сделать это на компьютерах с одинаковым распределением, только 32-битным и 64-битным. Тем не менее, как отметил Джон Кугельман, архитектуры перешли с 16-битного на 32-битное простое int, и сегодня можно снова столкнуться с трудностями, которые связаны с его следующим пунктом:

Более значимым компонентом является разрыв, который он может вызвать в целочисленных размерах или в новом типе. Поскольку sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long) находится в фактической спецификации, пробел форсируется, если int переводится в 64 бита, пробел просто неизбежен. Это начинается со смещения long. Если для простого int задано значение 64 бита, то ограничение sizeof(int) <= sizeof(long) заставит long составлять как минимум 64 бита, и оттуда будет свойственный разрыв в размерах. Так как long или обычный int обычно используются как 32-разрядное целое число, и ни один из них не может теперь, у нас есть только один тип данных, который мог бы, short. Потому что short имеет минимум 16 битов, если вы просто отбросите этот размер, он может стать 32 битами и заполнить этот пробел. Однако short предназначен для оптимизации под пространство, поэтому его следует сохранить таким же образом, а также есть варианты использования для маленьких 16-битных целых чисел. Независимо от того, как вы расположите размеры, ширина будет потеряна, и, следовательно, сценарий использования для int будет полностью недоступен.

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

В качестве примечания: если ваше приложение несовместимо с> 32-битным целым числом, вы можете использовать static_assert(sizeof(int) * CHAR_BIT <= 32, "Int wider than 32 bits!");. Однако, кто знает, может быть, спецификации изменятся, и будут реализованы 64-битные обычные целочисленные значения, поэтому, если вы хотите быть в будущем, не делайте статического утверждения.

Ответ 2

Я все еще думаю, что это вопрос самоуверенный. Хотя Univac отнюдь не является распространенным явлением, все еще есть работающие примеры, такие как Univac 9400 в музее живого компьютера technikum29 около Франкфурта в Германии. Люди все еще поддерживают это в рабочем состоянии.

"Новый стандарт С (выдержка из материала)" от 2002-2008 гг. Гласит:

Общие реализации

Значения, которые чаще всего превышают значения, показанные ниже, относятся к типу int. В размещенных реализациях они часто совпадают с соответствующими значениями для типа long. В автономной реализации проблемы эффективности процессоров обычно диктуют использование меньших числовых диапазонов, поэтому обычно используются минимальные значения, показанные здесь. Значения, используемые для соответствующего символа: short, long и long long, обычно совпадают с приведенными в стандарте.

Unisys A Series [5] необычна не только использованием величины знака, но и наличием единого размера (шесть байтов) для всех целочисленных типов, не являющихся символами (тип long long пока не поддерживается этими поставщиками). реализация).

#define SHRT_MIN (-549755813887)
#define SHRT_MAX 549755813887
#define USHRT_MAX 549755813887U
#define INT_MIN (-549755813887)
#define INT_MAX 549755813887
#define UINT_MAX 549755813887U
#define LONG_MIN (-549755813887L)
#define LONG_MAX 549755813887L
#define ULONG_MAX 549755813887UL

Тип символа использует двойную запись и занимает один байт.

The C compiler for the Unisys [email protected] Application Development Solutions (formerly known as the Universal Compiling System, UCS)[6] has 9-bit character types — 18-bit short, 36-bit int и long, и 72-bit long long.

REF: http://c0x.coding-guidelines.com/5.2.4.2.1.pdf