编译器对不同进制常量的不同处理

lli_njupt

在看补码的时候遇到一个古怪的问题，似乎编译器对十进制常量汇编的时候，会做一个转换，但是其它进制不会：

1. 
   
2. test.c
   
3. #include <stdio.h>
   
4. 
   
5. int main()
   
6. {
   
7.         char a = 0b00000000;
   
8.         char b = 0b10000001;
   
9. 
   
10.         printf("a: %d, b:%d\n", a, b);
    
11. 
    
12.         return 0;
    
13. }
    

复制代码

#make  test
#./test
a: 0, b:-127

为什么b不是-1而是-127呢，看来是用二进制表示的时候，汇编器将0b10000001直接读入了，而printf读出的时候，
CPU内部做了转换，也即10000001 取反11111110再加1求得11111111，也即-127

查看生成的反汇编代码为：
80483cd:       c6 44 24 1f 00          movb   $0x0,0x1f(%esp)
80483d2:       c6 44 24 1e 81         movb   $0x81,0x1e(%esp)

第一句将0x0放入堆栈esp+0x1f处，第二句将0x81放入堆栈esp+0x1e处，0x81就是0b10000001。
看来当使用二进制给出初始值的时候，汇编器忠实于原数值。

再看下面程序：
#include <stdio.h>

int main()
{
        char a = 0b00000000;
        char b = -1;

        printf("a: %d, b:%d\n", a, b);

        return 0;
}

#./test
a: 0, b:-1

查看生成的汇编代码为：
80483cd:       c6 44 24 1f 00          movb   $0x0,0x1f(%esp)
80483d2:       c6 44 24 1e ff          movb   $0xff,0x1e(%esp)
第一句将0x0放入堆栈esp+0x1f处，第二句将0xff放入堆栈esp+0x1e处，0xff就是-1的补码。
看来当使用十进制给出初始值的时候，汇编器将翻译原数值为补码到机器指令。

假如我们使用十六进制呢，char b = 0x81; 打印结果与二进制给出的结果是一致的，另外测试8进制是结果也为-127。
难道只有十进制的时候，编译器会忠实于赋予的值？ 为什么要这样处理？ 请不吝指点！

hellioncu

哪个编译器支持 0b表示二进制？
-1的二进制应该是11111111，而不是10000001

tempname2

补码10000001本来就是－127。

lli_njupt

#gcc -v
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

看来二进制大家用的都很少啊，
-1的二进制应该是11111111，而不是10000001，这点楼上应该是指计算机内部表示了？
因为它用补码表示负数，看来是-1的十进制编译机器指令的时候直接由汇编器转化为二进制的
内部表示11111111了，恩，其它进制也是如此罢了，没甚奇怪的了！

liwangli1983

补码表示的二进制有符号序列 10000001 就是代表-127。 11111111代表-1

lli_njupt

用以下方式更好理解，不妨假设汇编器做了以下转换：

8/16进制  =>  2进制            
10进制    =>  16进制 => 2进制，10转16的时候已经转为补码了，然而8/16进制  =>  2进制直接放入机器指令了