Subject:
Where's the bug this time?
From:
Declan Moriarty ####@####.####
Date:
8 Oct 2002 12:49:24 -0000
Message-Id: <02100718292600.00907@genius.chateau.dec>
I'm totally impressed with the work in gpsim. It certainly makes my job
possible here. It's a great program for sorting code. Before you all chide me
for reinventing the calculator (below), I cannot use GPL code as my customer
requires propietary software. I'm coding for a 16f877, and am having serious
hassle with under carrying. Is this a bug in gpasm, gpsim, my installation,
or my code? All instructions in bank 0. Sorry about the length of this post.
Let us enter this with 0x29= 0x09.
CARRY:
movf 0x29, 0 ; copies LSB into W
movwf 0x2b ; dump in scratch register
movlw 0x09 ; 9 --> W. STATUS =0x18
subwf 0x2b, 0 ; 0x2b -w -->W. STATUS=1F
; (=DC, Z, & Carry all set if 0x2b < 0x0a)
Now to my inexperienced line of thinking, the correct coding at this stage
would surely be
btfsc STATUS, C; Do next if we overflowed
return ; forget the idea. We do not carry now
movwf 0x29 ; new value to LSB. We are carrying.
decf 0x29, 1 ; corrects mathematically for carry test above
When I step through in gpsim, that jumps the wrong way :-o. It carries with
0x29 < 0x0a and fails to carry above :-((. When I have a lower value in 0x29,
it fails to carry. I presumed there must be some logic inversion I'm unaware
of, although this carry check earlier
addwf 0x2a, 1 ; Adds to fractions
btfsc STATUS, C ; Overflow? Do next.
incf 0x29, 1 ; Done only on overflow
Does what I would expect, and increments only on the carry flag.
This code, however, as the continuation of the CARRY routine
btfss STATUS, C; Remember with 0x29=0x09, DC, C, & Z are all set
return
movwf 0x29
decf 0x29, 1 ; corrects mathematically for carry test above
Works correctly for EVERY value, high & low except 0x29 = 0x09 on entry.
Otherwise it carries in gpsim at 0x0a & higher, and doesn't carry beneath.
where although zero, dc and carry are all set and W=0, it carries, and the
end result is a most undesirable 0xff in 0x29 :-(. I circumvented it with
this:
movf 0x29, 0 ; copies LSB into W
sublw 0x0a ; Subtracts 0x0a from W
movwf 0x2b ; Dump W in scratch Register
btfss 0x2b, 7 ; Did it roll under? :-D
return ; no carryover
movlw 0x0a ; 0x0a (10 decimal) in W
subwf 0x29, 1 ; reduce value
incf 0x28, 1 ; msb = msb+1
return
It's all lousy code and early drafts anyhow.
Which avoids the flag issue altogether, because I have to move on. But I'm
bewildered. (gpsim-0.20.14, and gpasm -0.10.1 alpha are the versions).
--
Regards,
Declan Moriarty
Applied Researches - Ireland's Foremost Electronic Hardware Genius
A Slightly Serious(TM) Company
Without the optimist, the pessimist wouldn't know how happy he isn't
