Что означает "натуральный размер" на С++?

Ответ 1

"естественный размер" - это ширина целого числа, которое обрабатывается наиболее эффективно конкретным оборудованием.

Не совсем. Рассмотрим архитектуру x64. Арифметика на любом размере от 8 до 64 бит будет по существу той же скоростью. Итак, почему все х64-компиляторы установлены на 32-битном int? Ну, потому что там было много кода, который был первоначально написан для 32-битных процессоров, и многие из них неявно полагались на 32-битные int. И учитывая почти бесполезность типа, который может представлять значения до девяти квинтиллионов, дополнительные четыре байта на одно целое были бы практически неиспользованы. Итак, мы решили, что 32-битные ints являются "естественными" для этой 64-битной платформы.

Сравните архитектуру 80286. Только 16 бит в регистре. Выполнение 32-битного целочисленного добавления на такой платформе в основном требует разделения на два 16-битных дополнения. Практически все, что связано с этим, связано с расщеплением, действительно, и сопутствующим замедлением. 80286 "натуральный целочисленный размер" наиболее определенно не 32 бит.

Итак, "естественный" сводится к таким соображениям, как эффективность обработки, использование памяти и удобство программирования. Это не кислотный тест. Это вопрос субъективного суждения со стороны дизайнера архитектуры/компилятора.

Ответ 2

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

A short лучше всего продвигать до int перед выполнением интегральных операций, потому что так, как это было в C и С++, унаследовано это поведение с небольшой или вообще не основанием для его изменения, возможно, с нарушением существующего кода. Я не уверен, почему он был первоначально добавлен в C, но можно предположить, что он связан с "default int", где если тип не был указан, int был принят компилятором.

Бонус A: от 5/9 (выражений) мы узнаем: Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are defined as follows:

И тогда, в частности, интерес:

• правила с плавающей запятой, которые здесь не важны.
• Otherwise, the integral promotions (4.5) shall be performed on both operands
• Then, if either operand is unsigned long the other shall be converted to unsigned long.
• Otherwise, if one operand is a long int and the other unsigned int, then if a long int can represent all the values of an unsigned int, the unsigned int shall be converted to a long int; otherwise both operands shall be converted to unsigned long int.
• Otherwise, if either operand is long, the other shall be converted to long.

В заключение компилятор пытается использовать "лучший" тип, который может выполнять двоичные операции, причем int является наименьшим используемым размером.

Ответ 3

Что именно определяет этот "натуральный размер"?

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

Другие (например, Intel x64) более гибкие, и нет единого "натурального" размера; разработчикам компилятора выбрать размер, компромисс между эффективностью, диапазоном значений и использованием памяти.

почему это наиболее эффективно

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

почему короткий должен быть преобразован перед выполнением арифметических операций на нем

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

Что происходит, когда арифметические операции выполняются с целым числом long?

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

Ответ 4

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

Это отличный старт.

Q: Что именно определяет этот "натуральный размер" ?

В приведенном выше параграфе содержится определение "натуральный размер" . Ничто другое не определяет его.

Я хочу понять, почему это наиболее эффективно

По определению.

и почему короткое должно быть преобразовано перед выполнением арифметических операций на нем.

Это так, потому что определения языка C так говорят. Нет глубоких архитектурных соображений (возможно, некоторые из них были придуманы).

Бонус Q: Что происходит, когда арифметические операции выполняются по длинному целому?

Куча электронов проносится сквозь грязный песок и встречает кучу дыр. (Нет, действительно. Задайте неопределенный вопрос...)