home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] Double checking re: twos complement & signed types ??

  • Subject: Re: [OCLUG-Tech] Double checking re: twos complement & signed types ??
  • From: William Case <billlinux [ at ] rogers [ dot ] com>
  • Date: Wed, 19 Sep 2007 13:20:35 -0400
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