Well, I can tell you that while we've been discussing this to death for two
days on the PIClist, CCS help has *yet* to respond!

-- Lawrence Lile
----- Original Message -----
From: "Andrew Kunz" <akunz@TDIPOWER.COM>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Tuesday, October 17, 2000 8:35 AM
Subject: Re: Signed Int vs Int


> This is one of the reasons I had when I left use of CCS eons ago.
>
> Andy
>
>
>
>
>
>
>
>
>
> Bob Ammerman <RAMMERMAN@PRODIGY.NET> on 10/17/2000 09:13:16 AM
>
> Please respond to pic microcontroller discussion list
<PICLIST@MITVMA.MIT.EDU>
>
>
>
>
>
>
>
>
>  To:      PICLIST@MITVMA.MIT.EDU
>
>  cc:      (bcc: Andrew Kunz/TDI_NOTES)
>
>
>
>  Subject: Re: Signed Int vs Int
>
>
>
>
>
>
>
>
> ----- Original Message -----
> From: M. Adam Davis <adavis@UBASICS.COM>
> To: <PICLIST@MITVMA.MIT.EDU>
> Sent: Tuesday, October 17, 2000 8:40 AM
> Subject: Re: Signed Int vs Int
>
>
> > Bob Ammerman wrote:
> > > This is _not_ true.  In ANSI "C", a comparison of an 'int' and an
> 'unsigned
> > > int' is performed as a 'unsigned int' comparison, _not_ a 'signed
long'
> > > comparison.
> >
> > If so, what is the conversion?  You can't represent 250 (or even 128) in
a
> > signed int.  I suppose that there is no conversion, it just refers to
the
> uint
> > as an int, in which case it becomes -6.  <sigh>
>
> Yes, there is no conversion. The bits are just reinterpreted as signed.
>
> ANSI says an 'int' is at least 16 bits!  If your compiler calls an 8-bit
> variable an 'int' that is YANAC (yet another non-ansi construct).
>
> Actually, ANSI says that _all_ arithmetic is done at at _least_ int
(16-bit)
> precision. Not very friendly in the microcontroller world. Compilers can
do
> 'char' (8-bit) arithmetic and still call themselves ANSI when the final
> result of the 8-bit operation is certain to be the same as that in a
16-bit
> operation. For example:
>
> unsigned char a;
> unsigned char b;
> unsigned char c;
>
> c = a + b;
>
> The standard says this should be treated as:
>
> c = (unsigned char) ( (int) a + (int) b);
>
> ie: 'a' and 'b' are promoted to 16-bit signed values and added together.
The
> result is then truncated to 8 bits and stashed in 'c'.
>
> In this case the compiler _can_ use 8-bit arithmetic because it'll
_always_
> come up with the same value for 'c' that it would have obtained with
16-bit
> arithmetic followed by truncation.
>
> > Well, this is a reason for good coding practices.  Always cast variables
> when
> > they are dissimilar...  Portability is better then, as well.
>
> This is a pretty good idea. Be careful tho' that you don't force your
> compiler into 16-bit math by casting.
>
> > -Adam
> >
> > --
>
> Bob Ammerman
> RAm Systems
> (contract development of high performance, high function, low-level
> software)
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST
>
>
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST