Searching \ for 'number representation in PICs' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'number representation in PICs'.

Truncated match.
PICList Thread
'number representation in PICs'
2000\04\04@211531 by David E Arnold

picon face
I'm a newbie, maybe someone could answer this:

When the PIC does math operations with numbers does it view
all #'s as signed? or unsigned?

e.g.  you have the number 253d stored in a 8bit location. Is this
seen as +253d?(FDhex) or as -3( 2's complement )?

Is there a good reading on working with numbers and PICs?

thanks,
-Dave






Rich Leggitt <spam_OUTrleggittTakeThisOuTspamconcentric.net> on 04/04/2000 01:08:49 PM

Please respond to pic microcontroller discussion list <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>

To:   PICLISTspamKILLspamMITVMA.MIT.EDU
cc:    (bcc: David E Arnold/SYBASE)
Subject:  Re: Two ASCII bytes to one Hex byte?




{Quote hidden}

Aggh, hex!! But then what about lower case??

 movf char1,w ; '0'-'9'    'A'-'F'/'a'-'f'
 andlw 0x1f   ; 0x10-0x19  0x01-0x06
 addlw 0xf0   ; 0x00-0x09  0xf1-0xf6
 skpc
 addlw 0x19   ;            0x0a-0x0f
 movwf char1

-- Rich

2000\04\04@212605 by David Huisman

flavicon
face
The numbers are stored as 8 bit binary values ie 01000110
We treat the numbers in other formats as convenient.
ie. It is much easier on our minds to think in terms of hex
or decimal when manipulating numbers than trying to work
in raw binary.
Various high level languages allow you to define the types you use ie.
Modular 2 has cardinal, shortcard etc
C has signed and unsigned character, integer etc and floating point (real).
The assemblers also help by allowing us to set up default editing (ie. MPLAB
has ox for hex, ob for binary etc).

In assembler, you need to do all of the one's and 2's complements for
mathematic manipulation manually as required. Higher level languages
(including your basic) should hide this level most of the time so that you
can simply write
x = value1 x value2 + 6. etc etc

Regards

David Huisman

2000\04\04@222515 by Wagner Lipnharski

picon face
The short answer is:  "What do you want that number to be?"

For convention, the most significative bit *is* used as sign when
dealing with signed numbers, so, the biggest positive number would be
127 (7Fh) while the biggest negative number would be -127 (80h).

It is a decision you and your software do to know what FDh means. If it
is result of a signed calculation, then it is -3.

It is very interesting when playing to sound files, as VOC format for
example, when you can set the silence (no sound) as 80h, any lower value
is negative, any higher is positive waveform level. There is a reverse
situation when silence is 00h, with positive goint towards 7Fh value,
negative growing down FFh, FEh, FDh, etc. higher negative peak is 80h.
It turns to be complete uninteligible if you are decoding the file in
the wrong format, something good for a poor's man security encription.

As for the sign bit, I saw a 3 dimensional electronic puzzle with 4x4
(16) squares per level, 4 levels, 4 possible colors for each playing
element, everything in just one byte per playing element. All the
intrincated game status was saved in just 4 bytes. Simple math between
those 4 bytes could rule the game. Everything of specifying what each
bit means, as your sign MSB bit from the signed numbers.


David E Arnold wrote:
{Quote hidden}

2000\04\04@223549 by Gennette, Bruce

flavicon
face
Always and only positive binary numbers are *STORED*

It is up to the clever assembly language programer to manipulate the stored
value any way they want.  (If you are programing a Pic with a higher level
language then a clever assembly language programer wrote the rules for
manipulating the stored values).

Only ever *positive* numbers.  What do you get when you add 1 to 255d ?
You get 0.  What do you get when you add 1 to 0 ?  You get 1d. (Duh)
What do you get when you add 130d to 130d ?  You get 4d.

Bye.

       {Original Message removed}

2000\04\04@224622 by Richard Clemens

flavicon
face
Only if you assume they are positive.  Actually the numbers stored could all
be negative, or all the even numbers could be positive and odd negative, or
each could have three binary decimal places, etc.
--
Richard Clemens
Associate Professor, Computer Science
West Virginia Wesleyan College
59 College Avenue
Buckhannon, West Virginia 26201 USA

@spam@clemensKILLspamspamwvwc.edu
304.473.8421
----- Original Message -----
From: Gennette, Bruce <KILLspambruce.gennetteKILLspamspamTAFE.NSW.EDU.AU>
To: <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU>
Sent: Tuesday, April 04, 2000 10:34 PM
Subject: Re: number representation in PICs


> Always and only positive binary numbers are *STORED*
>
> It is up to the clever assembly language programer to manipulate the
stored
> value any way they want.  (If you are programing a Pic with a higher level
> language then a clever assembly language programer wrote the rules for
> manipulating the stored values).
>
> Only ever *positive* numbers.  What do you get when you add 1 to 255d ?
> You get 0.  What do you get when you add 1 to 0 ?  You get 1d. (Duh)
> What do you get when you add 130d to 130d ?  You get 4d.
>
> Bye.
>
>         {Original Message removed}

2000\04\04@225031 by Wagner Lipnharski

picon face
"Gennette, Bruce" wrote:
> Only ever *positive* numbers.  What do you get when you add 1 to 255d ?
> You get 0.  What do you get when you add 1 to 0 ?  You get 1d. (Duh)
> What do you get when you add 130d to 130d ?  You get 4d.

Correction, 1 + 255d and 130d + 130d will generate a carry bit, so the
result in real is not 0 and 4 respectivelly, but 256d and 260d.  Few
people "think" about it, but in 8 bits processors the ALU output has 9
bits, so it can represent up to 511d (1FFh).

Wagner.

2000\04\05@003945 by William Chops Westfield

face picon face
>> Always and only positive binary numbers are *STORED*

Nah.  Whatever you want.  For the math operations that the PIC does (add and
subtract, right?), the results will be correct as long as you interpret them
consistantly.

       255 + 1 = 11111111 + 1 = 0 (256 doesn't fit - overflow)
or      -1  + 1 = 11111111 + 1 = 0 (interpret the carry somewhat differently.)

BillW

2000\04\05@020222 by Andrew Warren

face
flavicon
face
David E Arnold <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU> wrote:

> When the PIC does math operations with numbers does it view
> all #'s as signed? or unsigned?
>
> e.g.  you have the number 253d stored in a 8bit location. Is this seen
> as +253d?(FDhex) or as -3( 2's complement )?

   David:

   The cool thing about the two's-complement representation for
   negative numbers is that IT DOESN'T MATTER whether you consider
   the numbers positive or negative; the math all works either way,
   so long as YOU are consistent in the way that YOU treat the
   numbers.

   To use your example...

       If YOU think of FD as representing 253, FD + FD = FA (with
       carry = 1).  Since YOU are thinking of those numbers as
       unsigned, YOU treat the result as equal to 506.

       If, on the other hand, FD means -3 to you, FD + FD still
       equals FA... But YOU treat that as a two's complement number
       equal to -6.

> Is there a good reading on working with numbers and PICs?

   I don't know how "good" it is, but I posted an explanation of
   two's-complement representation here a couple of years ago...
   It's reproduced on my web page; point your browser at:

       http://www.geocities.com/SiliconValley/2499/essays.html

   and click on the "Two's Complement and Binary Math" link.

   -Andy


=== Andrew Warren - TakeThisOuTfastfwdEraseMEspamspam_OUTix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...