* William Case <billlinux [ at ] rogers [ dot ] com> [070919 14:44]: > Sorry Bart, but that is not the way I read it? It seems to me, the > compiler only has to change values that will be subtracted. Either > because one is a negative value or one is preceded by the subtraction > operator. During optimization, if there is both a negative quantity and > a subtraction or the addition of two negative quantities, then the > numbers are left as addition. There is only one instruction to subtract: SUB. There is only one instruction to add: ADD. They are used irrigardless of the *signed prefix on your integer type. > At least that was why I asked in my previous post "I am trying to > confirm that subtracting a negatively signed integer (or floating > point) is *always* a double negative resulting in addition". Don't mix float and double into this. int a = get_user_input(); int b = get_user_input(); int c = a + b; How does the compiler know what is in an integer before the add is done? > Well then, if my ALU uses twos complement arithmetic, at some point one > of the unsigned ints has to be transformed into a two's complement > representation. Your ALU does not use two's complement at all. Not for ADD and SUB instructions. Your ALU does addition and subtraction. Two's complement is ... oh, wiat... I already said that.. > > I said that the signed bit only matters if you are encoding or decoding > > the value. And for updating the CPU flags register which includes > > things like sign bit and overflow bit. > > That makes sense, you have to have that info stored somewhere so that it > can be reattached, as it were, to the outcome. Say we are working with 8 bit integers. How would you decode the number 0x80? Well that depends on weather the integer is signed or unsigned. 0x80 is 128 if the number is signed and -128 if it is signed. Let's look at a nice example of adding -1 and -1. -1 in hex is 0xFF (11111111 in binary) Our ALU is 32bit (or 64bit), when I add 0xFF and 0xFF in an ALU I get 0x1FE. However we are using 8 bit integers, so when stored in memory it's truncated at 8 list significant bits. So 0xFE. And what is 0xFE in hex? If the number is unsigned it's 254, but when it's signed it's -2. Hey look! -1 + -1 = -2 and I didn't do any fancy addition. This works for any numbers that don't overflow your storage type. You just add the bits and carry. -Bart -- WebSig: http://www.jukie.net/~bart/sig/