[sdiy] IIR Shift Filter problem - help with bug spotting in PIC ASM

[Richie Burnett]

> And yeah, Richie, you're right…I suppose I have to use the simulator and 
> see what it can tell me. It's a drag but sometimes an unavoidable 
> necessity!

At least it's a purely algorithmic issue, so you don't have to worry about 
running it on the target hardware or setting up a stimulus file.  And you 
know it works for positive numbers but fails for some reason on negative 
ones, so shouldn't be too hard to single-step through with the simulator and 
see where a wheel falls off.

I must confess I haven't had time to examine your two code examples, but 
when I mess up using shifts/rotates for maths, it's usually one of the 
following:

1. Used rotate where should have used a shift operation
2. Used rotate through carry, when should have been rotate without carry.
3. Used rotate through carry with unknown previous carry flag status 
(probably should have BCF STATUS,#C first to clear carry flag)
4. Used a logical right shift where it should have been an arithmetic shift 
to sign-extend a negative number.

Those are the things that have bitten me in the past.

Re writing to the PIC status register the issue is this:

If for instance you were to use a logic instruction like "IORWF" to modify 
the STATUS register so that the ZERO flag bit is *SET* this causes a 
paradox:

1.ORing a number with the STATUS register results in a value that has a one 
in the ZERO flag position, so the ZERO flag should be set by this operation.
2. ORing this number with the STATUS register results in a new value that 
has at least one bit set, which clearly isn't a result that equals zero, so 
the result of the IORWF operation should clear the ZERO flag!

One or other will take priority, and I can't remember which one.  You can 
modify to the STATUS register safely.  The way to do this is to use BCF and 
BSF, SWAPF or MOVWF, because they don't implicitly modify the STATUS flags 
based on their result.

-Richie,