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

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

  • Subject: Re: [OCLUG-Tech] Double checking re: twos complement & and signed types ??
  • From: Bart Trojanowski <bart-oclug [ at ] jukie [ dot ] net>
  • Date: Sat, 15 Sep 2007 13:14:44 -0400
* William Case <billlinux [ at ] rogers [ dot ] com> [070915 12:22]:
> 1) All the texts I read say something like "If you are using a two's
> complement system" and go on to leave other explanatory statements open
> ended.  I have no choice do I ?  Twos complement is part of the
> architecture of the ALU is it not? 

You don't have a choice.

> 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?

Yes, you would chose your type based on the range of values you wish to
store.  There is no problem with using a signed int for a range that is
unsigned as long as it's smaller than INT_MAX as defined in
/usr/include/lmits.h

Variable storage is neither signed nor unsigned.  When you get 32bit
chunk of memory there is no notion if it's an unsigned or signed int.
It could even be a short string.

The only time that the encoding makes a difference is when it's
interpreted by an arithmetic operation or decoded for printing.

unsigned num = -1;              // stores 0xFFFFFF in num
printf ("%d", num);             // prints -1

Yes, you will get a compiler warning if they are enabled.

> 3) Using an operator is a distinct instruction -- isn't it?  I.e 
> int num1 = 23
> int num2 = -11
> int result = num1 - num2 
> printf("%d",result)
> $ 34
> 
> int result = num1 + num2
> printf("%d",result)
> $ 12

Sometimes, like in this case the compiler might optimize your operations
out.  However, in general an arithmetic operation generates one or more
instructions.

Multiplications can sometimes be done faster with series of shifts and
additions.

> Writing and viewing the above code is trivial.  I am trying to confirm
> that subtracting a negatively signed integer (or floating point) is
> *always* a double negative resulting in addition.

Unless there is an overflow or underflow, you are correct.

-Bart

-- 
				WebSig: http://www.jukie.net/~bart/sig/