Thanks for setting that up and testing, it's appreciated.
I don't know how hard it is to set up but you might try the following;
DC= 1
C = 1
W = 32
(This would be the result of adding 99 + 99)
Then execute the 'DAW
The result should be (according to Microchip for the 18F series)
DC= 1
C = 0
W= 98
Using a 18F452, I arrived at the results (as above) that Microchip
said you should get.
I found a question nearly identical to mine in the Microchip
Developers conference and their answer was as above. I still
don't know why but I asked. Maybe I'll get a response in a day or
two.
asp.microchip.com/webboard/wbpx.dll/~devtools
Search for DAW
If Wreg = d'32' that is 0x20
After DAW every thing remains the same d'32' and C=0 DC=0
The only time DC will be 1 when goes over d'15' and
C will be 1 if your number goes over 99.
99+99=198 in decimal
if Wreg=198
after DEW
your Wreg is 98 C=1 DC=0
Andre Abelian
-----Original Message-----
Thanks for setting that up and testing, it's appreciated.
I don't know how hard it is to set up but you might try the following;
DC= 1
C = 1
W = 32
(This would be the result of adding 99 + 99)
Then execute the 'DAW
The result should be (according to Microchip for the 18F series)
DC= 1
C = 0
W= 98
Using a 18F452, I arrived at the results (as above) that Microchip
said you should get.
I found a question nearly identical to mine in the Microchip
Developers conference and their answer was as above. I still
don't know why but I asked. Maybe I'll get a response in a day or
two.
asp.microchip.com/webboard/wbpx.dll/~devtools
Search for DAW
> Hi to all,
>
> I did some test using DAW instruction on MPLAB ICE2000
> and this is the result.
>
> Movlw 0x0F ; w reg has d=15: B=00001111
> DAW ; do decimal adjustments
> Movwf BCD_REG ; BCD_REG has d=21 b=00010101 C=0
>
>
> Second digit (F) 05
> First digit (0) + 01
> Result 015 ; 0 means C=0: 1 is bits 4,5,6,7 and
> 5 is bits
> 0,1,2,3
>
>
> Now lets deal with higher numbers
>
> Movlw 0xEF ; w reg has d=239: b=11101111
> DAW ; do decimal adjustments
> Movwf BCD_REG ; BCD_REG has d=85 h=55 b=10101010
>
>
> Second digit (F) 15 ; decimal
> First digit (E) + 14 ; decimal
> Result 155 ; 1 means C=1: 5 is bis 4,5,6,7 and
> 5 is bits
> 0,1,2,3
>
>
> Andre Abelian
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body
>
My apologies, I should have been a little more clear. When I said
W=32 I was thinking, but not writing, packed BCD 32, or 0x32.
I'm not really sure how that should be written.
However, the status bits DC and C should both
be set to '1' before the DAW in order to simulate the results
an addition (ADDWFC or similar) of two packed BCD
numbers, 99.+ 99 in this case.
BTW I heard from Microchip already, not much but they said
they will look into it. Not sure what that means but it's a start.
> Mike,
>
> If Wreg = d'32' that is 0x20
> After DAW every thing remains the same d'32' and C=0 DC=0
> The only time DC will be 1 when goes over d'15' and
> C will be 1 if your number goes over 99.
>
> Andre Abelian
>
>
>
part 1 4939 bytes content-type:text/plain; (decoded 7bit)
Let me try this again. I probably wasn't clear enough in explaining
what I was really getting at.
This is probably nothing new to most but it may help some avoid
at least one pitfall.
What I finally learned is that, for example, if you are adding
two multi digit decimal numbers in packed BCD format (such
as 9990 + 9990) and are using DAW to adjust the
results after each 'add', you need to save the
carry after each add and restore it after each DAW
(or at least before the next 'add').
If you don't, the final results may not be what
you expect. In re-reading the description of the
DAW opcode, it only says that the C bit is affected,
not how or why. Apparently the C bit is simply a
result of the additions that took place when
performing the adjust, not a result of the previous
addition (like ADDWFC) as you 'might' have liked
or expected.
In an attached file are a couple of tested examples
that, I hope, illustrate the above. BTW Example 1
was confirmed by Microchip in a response to a
question I found on their web site.
The original question was "Why is this Binary to BCD
Conversion" macro not working correctly?".
www.piclist.org/techref/postbot.asp?by=time&id=piclist/2002/12/24/164
925a
I applied a rather brute force method of saving and restoring
the carry bit as per the above and it now works as expected.
Now I need to find a more elegant way to save and restore the
carry than with the cycle eating brute-force method I tested the
'fix' with.
You're obviously right about the second example and the need to 'or' the
carry bits. . My notes were right, I just can't seem to consistently copy
from
one medium to another correctly. I'm truly embarrassed. I think I'm going
to lower the noise level and just listen.from now on.
BTW Your 'fix' was one instruction less than mine. Thanks.
Considering long BCD numbers that was DAA or DAW developed for, the carry
never is set when you add two proper BCD numbers.
(99 + 99 = 198).
DAW or DAA in 8086 or other mnemotechnics used years ago, even in IBM 360
worked by the same way. If I remember well, COBOL, PL/1 and early versions
of Pascal used so called long BCD numbers that saves memory and were enough
long for accounting.
Who needs such arithmetics today...
>Considering long BCD numbers that was DAA or DAW developed for, the carry
>never is set when you add two proper BCD numbers.
>(99 + 99 = 198).
Sorry, this is not true. When you are adding BCD 99 + BCD 99 you are really
adding
Hex 99 to Hex 99 or decimal 153 + decimal 153, which can obviously generate
a carry.
>DAW or DAA in 8086 or other mnemotechnics used years ago, even in IBM 360
>worked by the same way. If I remember well, COBOL, PL/1 and early versions
>of Pascal used so called long BCD numbers that saves memory and were enough
>long for accounting.
>Who needs such arithmetics today...
BCD is very convenient if entering an displaying decimal values is an
important part of the project.
Correct me if I am wrong, but I don't think this will work reliably;
>
> Here is the best I have come up with for saving and merging carry.
>
> ADDWFC var,x ; add two bytes
> RRCF temp,f ; remember the carry
> DAW ; adjust the value
> BTFSC temp,7 ; was carrry set?
> SETC ; yes: set it again
>
The RRCF will also shift a bit into the carry bit that may or may not
be what you want daw to make a decision on whether to add 6 to
the upper nibble or not. This initially looked good but when I tried it
I got some really strange results until I figured out what as going on.
The following is one instruction cycle longer but seems to work reliably.
ADDWFC var,x ; add two bytes
MOVFF status, temp ; remember the carry
DAW ; adjust the value
BTFSC temp,0 ; was carrry set?
SETC ; yes: set it again
It sure would have been nice if they had made Status Affected: None!
mitvma.mit.edu with SET PICList DIGEST in the body
