为什么没有内在访问CPU的状态寄存器在C和C ++的设计？ [英] Why was no intrinsic access to the CPU's status register in the design of both C and C++?
问题描述
在溢出标志的情况下，它似乎是获得此标志将是一个巨大的福音跨架构的编程。它将提供一个安全的替代依赖未定义行为检查符号整数溢出，如：
如果（A＆LT; A + 100）//检测溢出
我不明白，有安全的替代品，如：
如果（A＆GT;（INT_MAX - 100））//检测溢出
不过，它似乎是进入状态寄存器或个人标志在它从C和C ++语言都不见了。为什么这个功能不包括或什么语言设计决策所做被禁止包含此功能？
- 因为C ++被设计成一个可移植的语言，也就是一个在许多CPU编译（如X86，ARM，LSI-11/2，像游戏的男孩，手机，冷柜，飞机，人为操控芯片和激光剑设备）。
- 在CPU可用的标志可能大不相同
- 即使在相同的CPU，标志可能有所不同（坐86标量与向量指令）
- 某些CPU可能连你都 渴望的标志
- 的问题要回答：？如果编译器总是提供/启用标志时，它不能确定它是否在所有使用的，这不符合在只需支付你用什么不成文但神圣C和C ++ 法
- 由于编译器将不得不被禁止，以优化和例如重新排序code，以保持这些标志有效
实施例为后者：
<$ P为$ P> INT X = 7;
X + = Z;
INT Y = 2;
Y + = Z;
优化程序可能会改变这个给伪组装code：
alloc_stack_frame 2 * sizeof的（INT）
load_int 7，$ 0个
load_int 2，$ 1
加Z，$ 0个
添加ž，$ 1
这反过来会更类似于
<$ P为$ P> INT X = 7;
INT Y = 2;
X + = Z;
Y + = Z;
现在，如果你查询寄存器其间
<$ P为$ P> INT X = 7;
X + = Z;
如果（check_overflow（$ 0））{...}
INT Y = 2;
Y + = Z;
然后优化和dissasembling后您的可能的一端与这样的：
<$ P为$ P> INT X = 7;
INT Y = 2;
X + = Z;
Y + = Z;
如果（check_overflow（$ 0））{...}
这是不正确，然后
更多的例子可以构造，像什么用恒定折叠编译时溢出发生。
图片的标题说明：我记得有一个很小的API老的Borland C ++编译器读取当前CPU寄存器。然而，上述有关优化论证仍然适用。
在另一个旁注：要检查溢出：
//所需EX pression：INT Z = X + Y
would_overflow = X＆GT; MAX-Y;
更具体
自动would_overflow = X＆GT;的std :: numeric_limits＆LT; INT＆GT; :: MAX（） - Ÿ;
或更好的，更小的混凝土：
自动would_overflow = X＆GT;的std :: numeric_limits＆LT; decltype（X + Y）＆GT; :: MAX（） - Ÿ;
In the case of the overflow flag, it would seem that access to this flag would be a great boon to cross-architecture programming. It would provide a safe alternative to relying on undefined behaviour to check for signed integer overflow such as:
if(a < a + 100) //detect overflow
I do understand that there are safe alternatives such as:
if(a > (INT_MAX - 100)) //detected overflow
However, it would seem that access to the status register or the individual flags within it is missing from both the C and C++ languages. Why was this feature not included or what language design decisions were made that prohibited this feature from being included?
- 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
- even within the same CPU, flags may differ (take x86 scalar vs. vector instructions)
- some CPUs may not even have the flag you desire at all
- The question has to be answered: Should the compiler always deliver/enable that flag when it can't determine whether it is used at all?, which does not conform the pay only for what you use unwritten but holy law of both C and C++
- Because compilers would have to be forbidden to optimize and e.g. reorder code to keep those flags valid
Example for the latter:
int x = 7;
x += z;
int y = 2;
y += z;
The optimizer may transform this to that pseudo assembly code:
alloc_stack_frame 2*sizeof(int)
load_int 7, $0
load_int 2, $1
add z, $0
add z, $1
which in turn would be more similar to
int x = 7;
int y = 2;
x += z;
y += z;
Now if you query registers inbetween
int x = 7;
x += z;
if (check_overflow($0)) {...}
int y = 2;
y += z;
then after optimizing and dissasembling you might end with this:
int x = 7;
int y = 2;
x += z;
y += z;
if (check_overflow($0)) {...}
which is then incorrect.
More examples could be constructed, like what happens with a constant-folding-compile-time-overflow.
Sidenotes: I remember an old Borland C++ compiler having a small API to read the current CPU registers. However, the argumentation above about optimization still applies.
On another sidenote: To check for overflow:
// desired expression: int z = x + y
would_overflow = x > MAX-y;
more concrete
auto would_overflow = x > std::numeric_limits<int>::max()-y;
or better, less concrete:
auto would_overflow = x > std::numeric_limits<decltype(x+y)>::max()-y;
这篇关于为什么没有内在访问CPU的状态寄存器在C和C ++的设计？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
