Hi Brenda, Bart et al; I am sorry to be back at this again, but I am about to write up a weeks worth of notes on how the ALU, twos complement, and how instruction sets interact with data. If I don't have this right, I could end up writing for hours going down the completely wrong track. On Sat, 2007-09-15 at 13:03 -0400, Brenda J. Butler wrote: > On Sat, Sep 15, 2007 at 12:23:04PM -0400, William Case wrote: > > Hi; > > > > Just double checking because the manuals I have are somewhat ambiguous > > -- trying to be all things to all people. Primarily I am using William Stallings, Computer Organization and Architecture, 6th ed.. Read it and YOU try to sort out signed from unsigned etc. etc.. Or visit, http://en.wikipedia.org/wiki/Two%27s_complement and unconfuse that. The only common chip architecture that I can see that still uses signed and unsigned numbers is the PowerPC. If that is so, shouldn't the description of what is happening in the ALU of a PowerPC be downgraded to something subsidiary like a footnote? "INT_MAX" > > > > Given that I am using an AMD Athalon 64 x2 CPU: > > And given that "sizeof(int)" returns 8 bytes or maximum of 4,294,967,295; while "INT_MAX" returns 2,147,483,647. I understand that "INT_MAX" shows one less bit for the case of signed integers which use the most significant bit to indicate the sign. 1 == minus, 0 == plus But, it seems to me that the distinction between "sizeof(int)" and "INT_MAX" is no longer important except for those people who have to learn how to program for mainframes. Or, for those who are programming on desktop but are concerned that their program someday, someway, my get ported to a mainframe. -- This, although written like a statement, is a question. > > (N.B. I do not need an explanation of twos complement. I thing I got > > it.) Two's complement is none other than inverting the bit representation of a decimal number (i.e. 1's become 0's; and 0's become 1's) and adding 1, followed by adding the two numbers (operands). When subtracting or using negative numbers this makes such obvious sense it is almost trivial. But, boy, can the academics ever mess it up. (As usual) > > > 2) This as been answered for me before, but so much is written about > > signed numbers, I would like to re-check. Using C programming, my > > system would not need or use signed numbers (integer and floating point) > > would it? The concern over signed/unsigned numbers is only if there > > exists the possibility that the C program might be later used on a > > system that requires signed/unsigned numbers -- right? > > A signed integer and an unsigned integer are not treated differently > by the machine. When they get added together, or subtracted > or whatever, they have exactly the same effect upon the accumulator > and the status register (NCZV). > > It is what the C compiler does with the contents of the accumulator and > the status register that makes it signed or unsigned. > I gather you are saying, that if there is a subtraction operation in some C code, it is the *compiler* that alters the value of the number to be subtracted (or negated) into it's two's complement binary representation and that is the value stored in memory. ?? Once stored as a two's complement representation, when fetched for use in the ALU, the ALU just performs a normal add instruction. I.E. For me, all I would probably ever use is an unsigned integer (or short or float or double) and the subtract operator -- correct?? Have I got the above right? -- Regards Bill