补码学习

one's complemen:即将每位二进制求反即反码。

000...00001 = +1  000...00000 = +0  111...11111 = -0 

问题出现在(+0)(-0),在人们的计算概念中零是没有正负之分的.这种简单的机制会产生-1 + 2 = +0,为避免这种情况,引入twos-complement. 

        binary    decimal
11111110     -1
+  00000010     +2
............    ...
1 00000000      0   <-- not the correct answer
1     +1   <-- add carry
............    ...
00000001      1   <-- correct answer

two complement: 是将二进制求反加一,忽略溢出。

这就避免了对0的两种表示。

000...00001 = +1    000...00000 = 0    111...11111 = -1 

注意:111...11111,111...11111在不同规则下表示的是不同的值。Sign-and-magnitude表示原码。

在two complement 下1000 0000b表示是多少?

分析:首先它是负数,所以取反加一得到他相对应的正数的补码,而正数的补码为其本身,所以1000 0000b就表示为28次方即为-128,故而8为补码所表示的范围为-128----127(1111 1111)

故而two complement表示的范围是:

sign bit
01111111=127
00000010=2
00000001=1
00000000=0
11111111=−1
11111110=−2
10000001=−127
10000000=−128
8-bit two's-complement integers

 而源码,反码的范围都是-127-127.

Table G.3: Three-bit two's-complement binary fixed-pointnumbers.
BinaryDecimal
0000
0011
0102
0113
100-4
101-3
110-2
111-1


Note that according to our negation rule, $ -(-4) = -4$. Logically, what has happened is that the result has ``overflowed'' and ``wrapped around'' back to itself. Note that $ 3+1=-4$ also. In other words, if you compute 4 somehow, since there is no bit-pattern assigned to 4, you get -4, because -4 is assigned the bit pattern that would be assigned to 4 if $ N$ were larger. Note that numerical overflows naturally result in ``wrap around'' from positive to negative numbers (or from negative numbers to positive numbers). Computers normally ``trap'' overflows as an ``exception.'' The exceptions are usually handled by a software ``interrupt handler,'' and this can greatly slow down the processing by the computer (one numerical calculation is being replaced by a rather sizable program).

Note that temporary overflows are ok in two's complement; that is, if you add $ 1$ to $ 3$ to get $ -4$, adding $ -1$ to $ -4$ will give $ 3$ again. This is why two's complement is a nice choice: it can be thought of as placing all the numbers on a ``ring,'' allowing temporary overflows of intermediate results in a long string of additions and/or subtractions. All that matters is that the final sum lie within the supported dynamic range。

 mov   al,27h   

mov   bl,73h   

add   al,bl   

    

 

27h       00100111   

73h       01110011   

    

如果是无符号数al的结果为10011010(9A),如果是有符号数结果是什么?   

    

    如果是有符号数,结果依然是10011010(9A)。注意,此时溢出标志置位。表明这个加法如果是作为有符号数的加法时,结果是不能用的。当然,如果你把这个加法作为无符号数的加法来看,结果则是可用的(虽然此时仍有溢出,但它是无意义的。溢出只针对有符号数而言的)。   

    这是个特例。因为无符号数的加减法与有符号数的补码的加减法是恰巧是一致的。因此有符号数与无符号数可以使用同一指令,得到同一结果。而这一结果是作为有符号数还是无符号数,是由程序员来定义的:如果程序员认为是有符号数的加减法,则他将关心运算结果的溢出标志,以判别结果是否可用;如果程序员认为是无符号数的加减法,则他将关心运算结果的进位标志,看运算结果是否有进(借)位。   

    正是基于这样的原因,计算机的有符号数才采用补码表示。  

 例如:   
    al=1001   1100(9C),bl=1110   0111(E7),则   
    add   al,bl    
    运算结果是:   
    al=1000   0011(83)   且进位标志CY=1,溢出标志OV=0.   
    
    对于这个结果,你可以把它作为无符号数运算,即有:   
    al=9Ch=156d,bl=E7h=231d,运算结果al=83h=131d,考虑到进位,运算结果应为131+256=387,而al+bl=156+231=387.正确。   
    
    同样对于这个结果,你也可以把它作为有符号数的运算,即有:   
    al=9Ch=-100d,bl=E7h=-25d,(注意有符号数均看成补码,9Ch是-100的补码,下同)。   
    而运算结果al=83h=   -125d,因为没有溢出(有符号数是不考虑进位的),运算结果可用。   
    而al+bl=9Ch+E7h=(-100)+(-25)=-125.可见结果亦完全正确。   
    
    由上例可见,无符号数的加法与有符号数的补码加法是完全一致的。CPU没有必要去区分。关键在于程序员如何去看待。CPU的运算结果将同时影响进位标志与溢出标志。如果程序员认为这是无符号数运算,则只考虑进位标志而忽略溢出标志。反之,如果程序员认为这是有符号数运算,则只考虑溢出标志而忽略进位标志。   

 

Both Csharp and Visual Basic uses twos complement representations of numbers. Understanding twos complement isn't strictly necessary for most applications but it sometimes comes in handy. With a little thought, you can discover the value of every bit in a number whether it is positive or negative.

Bitwise operators in c# OR(|), XOR(^), AND(&amp;), NOT(~)

http://weblogs.asp.net/alessandro/archive/2007/10/02/bitwise-operators-in-c-or-xor-and-amp-amp-not.aspx 

参考:http://en.wikipedia.org/wiki/Two's_complement 

        http://ccrma.stanford.edu/~jos/mdft/Two_s_Complement_Fixed_Point_Format.html

       http://www.cs.cornell.edu/~tomf/notes/cps104/twoscomp.html

http://topic.csdn.net/t/20030913/20/2256856.html#

 

转载于:https://www.cnblogs.com/luyong/archive/2008/09/05/1284905.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值