Hi Bart; I know you must be tired of this subject, but for me it is the core of three years digging. First let me say, I trust your answers and I am not trying to be argumentative. But here is what I am dealing with. William Stallings, Computer Organization and Architecture, 6th ed. p 286; says "Because of these drawbacks [ a reference to sign magnitude and -0] sign magnitude representation is rarely used in implementing the integer portion of the ALU. Instead the most common scheme is the two's complement representation." "Like the sign magnitude, two's complement representation uses the most significant bit as a sign bit, making it easy to test whether an integer is positive or negative. It differs ... in the way that other bits are interpreted. Table 9.1 highlights key characteristics of two's complement representation and arithmetic, which are elaborated in this section and the next." "Table 9.1 Range -2^n-1 through 2^n-1 ... Negation Take the Boolean complement of each bit of the corresponding positive number, then add 1 to the resulting bit pattern viewed as an unsigned integer. ... ... Subtraction Rule To subtract B from A, take the two's complement of B and add it to A. His elaboration is then two to three pages of what a complement is in 8 bit and 16 bit formats; addition; and use of overflow. On Wed, 2007-09-19 at 15:04 -0400, Bart Trojanowski wrote: > * 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 > -- Regards Bill