Truncated match.
PICList
Thread
'number representation in PICs'
2000\04\04@211531
by
David E Arnold
2000\04\04@212605
by
David Huisman
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

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}>
> 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 <
.....rleggittKILLspam.....concentric.net> on 04/04/2000 01:08:49 PM
>
> Please respond to pic microcontroller discussion list <
EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU>
>
> To:
PICLISTspam_OUTMITVMA.MIT.EDU
> cc: (bcc: David E Arnold/SYBASE)
> Subject: Re: Two ASCII bytes to one Hex byte?
>
> > Here's a way that works for the whole range:
> >
> > LIST R = DEC
> >
> > MOVLW '0'
> > BTFSC CHAR1,6
> > MOVLW 'A'10
> > SUBWF CHAR1
> >
> > MOVLW '0'
> > BTFSC CHAR2,6
> > MOVLW 'A'10
> > SUBWF CHAR2
>
> Aggh, hex!! But then what about lower case??
>
> movf char1,w ; '0''9' 'A''F'/'a''f'
> andlw 0x1f ; 0x100x19 0x010x06
> addlw 0xf0 ; 0x000x09 0xf10xf6
> skpc
> addlw 0x19 ; 0x0a0x0f
> movwf char1
>
>  Rich
2000\04\04@223549
by
Gennette, Bruce
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

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@clemensKILLspamwvwc.edu
304.473.8421
 Original Message 
From: Gennette, Bruce <KILLspambruce.gennetteKILLspamTAFE.NSW.EDU.AU>
To: <RemoveMEPICLISTTakeThisOuTMITVMA.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
"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
>> 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

David E Arnold <spamBeGonePICLISTspamBeGoneMITVMA.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'scomplement 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'scomplement 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  TakeThisOuTfastfwdEraseMEspam_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...