为什么在生成的程序集中将C代码中的1.0f表示为1065353216? [英] Why is 1.0f in C code represented as 1065353216 in the generated assembly?

问题描述

在C中，我有以下代码块:

In C I have this code block:

if(x==1){
    a[j][i]=1;
}
else{
    a[j][i]=0;
}

a是浮点值的矩阵，如果我尝试以nasm语法查看此代码的已编译程序集

a is a matrix of float values, if I try to see the compiled assembly of this code in nasm syntax

a[j][i]=0;行的分配是用这种方式编码的

the line a[j][i]=0; assignment, was coded in this way

dword [rsi+rdi], 0

但是行a[j][i]=1;的分配是以这种方式编码的

but the line a[j][i]=1; assignment, was coded in this way

dword [rsi+rdi], 1065353216

1065353216 如何表示 1.0f ??

推荐答案

因为 1065353216 是32位浮点值1.0的无符号32位整数表示形式.

Because 1065353216 is the unsigned 32-bit integer representation of the 32-bit floating point value 1.0.

更具体地说，1.0作为32位浮点数变为:

More specifically, 1.0 as a 32-bit float becomes:

0....... ........ ........ ........ sign bit (zero is positive)
.0111111 1....... ........ ........ exponent (127, which means zero)
........ .0000000 00000000 00000000 mantissa (zero, no correction needed)
___________________________________
00111111 10000000 00000000 00000000 result

所以最终结果是2 ^ 0 + 0，即1 + 0，即1.

So the end result is 2^0 + 0, which is 1 + 0, which is 1.

您可以使用 binaryconvert.com 或

You can use binaryconvert.com or this useful converter to see other values.

关于127为什么突然在指数中表示零的原因:实际上，这是一个非常巧妙的技巧，称为指数偏差比较浮点值更容易.尝试使用截然不同的值(10、100、1000 ...)的转换器，您还会看到指数也增加.排序也是符号位是存储的第一位的原因.

As to why 127 suddenly means zero in the exponent: it's actually a pretty clever trick called exponent bias that makes it easier to compare floating-point values. Try out the converter with wildly different values (10, 100, 1000...) and you'll see the the exponent increases as well. Sorting is also the reason the sign bit is the first bit stored.

这篇关于为什么在生成的程序集中将C代码中的1.0f表示为1065353216?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！