Почему не было встроенного доступа к регистру состояния ЦП при разработке как C, так и C++?

• Because C++ is designed as a portable language, i.e. one that compiles on many CPUs (e.g. x86, ARM, LSI-11/2, with devices like Game Boys, Mobile Phones, Freezers, Airplanes, Human Manipulation Chips and Laser Swords).
  • the available flags across CPUs may largely differ
  • даже в пределах одного и того же процессора флаги могут отличаться (возьмите скалярные инструкции x86 против векторных инструкций)
  • некоторые процессоры могут вообще не иметь желаемого флага
• Необходимо ответить на вопрос: Должен ли компилятор всегда устанавливать/включать этот флаг, если он не может определить, используется ли он вообще?, что не соответствует плате только за то, что вы использовать неписаный, но священный закон как C, так и C++
• Поскольку компиляторам нужно было бы запретить оптимизировать и, например. переупорядочить код, чтобы сохранить эти флаги действительными

Пример для последнего:

int x = 7;
x += z;
int y = 2;
y += z;

Оптимизатор может преобразовать это в код псевдоассемблера:

alloc_stack_frame 2*sizeof(int)
load_int 7, $0
load_int 2, $1
add z, $0
add z, $1

который, в свою очередь, будет больше похож на

int x = 7;
int y = 2;
x += z;
y += z; 

Теперь, если вы запрашиваете регистры между

int x = 7;
x += z;
if (check_overflow($0)) {...}
int y = 2;
y += z;

то после оптимизации и дизассемблирования вы можете закончить следующим образом:

int x = 7;
int y = 2;
x += z;
y += z;
if (check_overflow($0)) {...}

что тогда неверно.

Можно было бы построить больше примеров, например, то, что происходит с переполнением времени компиляции с постоянным свертыванием.

Примечания: я помню старый компилятор Borland C++ с небольшим API для чтения текущих регистров процессора. Тем не менее, приведенная выше аргументация об оптимизации остается в силе.

С другой стороны: чтобы проверить переполнение:

// desired expression: int z = x + y
would_overflow = x > MAX-y;

более конкретно

auto would_overflow = x > std::numeric_limits<int>::max()-y;

или лучше, менее конкретно:

auto would_overflow = x > std::numeric_limits<decltype(x+y)>::max()-y;

Потому что C и C++ спроектированы так, чтобы быть независимыми от платформы. Статус регистра нет.

В наши дни дополнение до двух повсеместно используется для реализации целочисленной арифметики со знаком, но так было не всегда. Раньше дополнение или знак и абсолютное значение были довольно распространены. И когда C был впервые разработан, такие процессоры все еще широко использовались. Например. COBOL различает отрицательный и положительный 0, которые существовали в этих архитектурах. Очевидно, что поведение переполнения на этих архитектурах совершенно другое!

Между прочим, вы не можете полагаться на неопределенное поведение для обнаружения переполнения, потому что разумные компиляторы увидев

if(a < a + 100)

напишет предупреждение и скомпилирует

if(true)

... (при условии, что оптимизации включены, а конкретная оптимизация не отключена).

И обратите внимание, что вы не можете полагаться на предупреждение. Компилятор выдаст предупреждение только тогда, когда условие заканчивается true или false после эквивалентных преобразований, но во многих случаях условие будет изменено при наличии переполнения, не заканчиваясь простым true/false.

Я могу предположить следующие причины.

1. Разрешая доступ к регистровым флагам, переносимость языка между платформами сильно ограничивается.

2. Оптимизатор может кардинально изменить выражения и сделать ваши флаги бесполезными.

3. Это сделало бы язык более сложным

4. Большинство компиляторов имеют большой набор встроенных функций для выполнения наиболее распространенных операций (например, сложения с переносом), не прибегая к флагам.

5. Большинство выражений можно переписать безопасным способом, чтобы избежать переполнения.

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

Доступ к регистрам состояния кажется недостаточным для проведения стандартизации.