On Tue, 15 Jul 1997 03:50:44 +0000 John Payson writes: >> >[1] "forcef" this instruction would fetch its operand from a >register, >> >leave it in the operand buffer, and disable the operand fetch on >the >> >next >> >instruction. ... A more typical use would be: >> > >> > forcef foo >> > movnf Bar,f ; movnf = move, without bothering flags >> > >> >which would copy Foo into Bar without affecting anything else. >> >> I've never had much occasion to do this, more general-purpose is an >> instruction which exchanges W and a register. >> >> xchwf bar ;save W into bar >> movfw foo ;Get foo >> xchwf bar ;bar = foo, recover old W >> >> In the example above, the pesky MOVFW will affect Z. But, if the >value >> of foo didn't need to be preserved the movfw could be replaced with >an >> xchwf, leaving the old value of bar in foo (a complete exchange of >foo >> and bar). The xchwf could also be the no-flags load W, if it didn't >> matter that the value in RAM was lost (such as when returning from >an >> interrupt). > >But as your example itself illustrates, the exchange instruction >doesn't >help as much as the "forcef" instruction. In addition, the "forcef" >version would avoid the side-effects posed by your "xchwf" example >above >and would (conjecture here) probably be easier to implement. Combining the xchwf with a no-status movfw would avoid this, but then that's 2 new instructions. Really there'd be no reason for movfw to ever affect status if there were another status bit which indicated if the value in W were presently zero. There'd be no need to save this bit since it would always track the value in W. (for the rare cases where the other Z bit should indicate if w=0, use a iorlw 0 to set it.) > Most of this comes from a fascination with being able to move data without using the W register (whose primary purpose is to move data). Since you're proposing 2-word instructions, I'll propose something equally complicated, a data stack. If there were a data push-pop stack to make saving W easier then it wouldn't be OK to move data through W as intended. There could be a version of movfw which puts the old W on the stack, and a movwf which pops the stack. These could be the 'push' and 'pop' instructions by pointing them to a scratch location. Or a move foo into bar without affecting W would be movfwp foo movwfp bar The ability to pass parameters to subroutines on the stack would be tremendous especially for compiler writers who are used to doing that anyway, and a series of movfwp's could be used to quickly collect data from RAM or SFRs and place it on the stack. Stacking W and STATUS during an ISR would be simple too: movfwp STATUS ;W->stack, STATUS ->W movfwp scratch ;STATUS - stack [isr] movwfp scratch ;stack (old STATUS) - > W movwfp STATUS ;old STATUS -> STATUS, stack (old W) - > W retfie Having the data stack a dedicated special space may be simpler to make but to get the full advantage it should be in RAM with an accessable pointer. Even without adding special instructions, there could be two SFR's of SP and ST. SP is like another FSR and ST is like another INDF. The SP register should have some page-select capability so the stack could be way off in an otherwise unused When reading ST, SP is postincremented, and when writing ST it is predecremented. This would allow a subroutine to point FSR somewhere in the stack and work on data directly there, or to tear parameters off the stack by adding a constant to SP.