>>QUOTING>>

I am using the PORTB interrupt on change. While using this feature any
read of PORTB can cancel the change condition. Also any
read/modify/write cycle will do the same. Since each write to a memory
location is implemented as a read/modify/write cycle, even if it is just
a write, in fact any access to PORTB can cancel the change condition.
(The RBIF bit is sticky, so this often is not a real problem except when
a new change is occurring.)

This brings up my question about the CLRW instruction. This instruction
appears to be implemented using a "CLRF X,W" encoding where X is a don't
care, but is always encoded as a 0 on all assemblers I have used. So if
FSR is set to PORTB then will CLRW clear the new RBIF set condition?

The same issues could exist in different devices with FSR set to SSPBUF,
RCREG and PORTD in PSP mode. Has anyone noticed this, is CLRW really
this dangerous?

>>ME>>
I think CLRW has the effect you described; many newer assemblers etc.
now use the coding "CLRx 1,W" to avoid any such FSR-related problems.
Otherwise, since PORTB, RCREG, etc. are not a particularly common
targets of FSR/IND, those addresses are unlikely to be hit by CLRW.

A related problem on earlier (non-A) 16C74's was that the RETURN
instruction (coded as MOVW 8,W) would read port D thereby clearing the
PSP-written flag.  According to a guy at Microchip, they've since
changed the instruction decode logic to prevent operand fetching on all
instructions of the form 00 0000 0xxx xxxx [it used to just disable the
operand fetch for 00 0000 0000 0000].  I don't know whether the operand
fetch is still performed for 00 0000 1xxx xxxx--the movwf instruction.