|I don't undestand why Microchip implement this instruction! It is the same
|as MOVLW 0,  risk processirs have a small  OP-code  numbers, and as for me -
|maybe preferable to implement a useful command against this ?

On the 16C5x, all of the instructions whose two high-order bits are "00"
are executed as follows:

 (1) Read the address specified in the LSB's of the instruction

 (2) Feed the contents of that address, W, and the carry flag into a
     "magic box" [the ALU]

 (3) The ALU will output an 8-bit value based upon the 8 bits from the
     f-register, the 8-bits of W, 4 bits from the opcode, and the carry
     flag.  For some instructions it will also output a new value for
     the C, DC, and Z flags.

 (4) The ALU's output will be stored to either W or back to the source
     "F" register, based upon the "D" bit of the opcode.

While there is special logic to cause other things to happen with certain
"0000 00xx xxxx" opcodes, these happenings are in addition to the sequence
of events described above [typically latching the ALU output somewhere
other than W].

For the "movf" command, the ALU's output value is simply a copy of what
came from the "f" register, for "movwf" it's a copy of what came from
"W", and for "clrx" it's all zeros.  The fact that the ALU ignores some
of its inputs does not prevent that data from being fed into it.

On early 16Cxx parts, the above rules held with precisely one exception:
logic prevented the all-zeros nop instruction from performing the operand
fetch described in (1).  This was necessary not only to ensure that "nop"
instructions didn't do something they shouldn't, but also to ensure that
skipped instructions (which get turned into NOP's in the instruction
latch) didn't have any odd side-effects.  While no registers were affected
by reads on the 16C5x (so a read from INDF was not a problem) spurious
reads of PORTB, PORTD, RCDATA, etc. can cause problems.

Unfortunately, Microchip did not disable operand fetches on all of the
"00 0000" class instructions on the early 16Cxx chips, and on the 40-pin
parts the RETURN instruction (00 0000 0000 1000) would generate a spur-
ious read of PORTD.  While generally not a problem in most applications,
such reads wreak havoc on PSP-port applications.  Fortunately, Microchip
fixed that problem; I don't know exactly what instructions have disabled
the pre-read (in particular, it would be useful to know how CLRx and
MOVWF behave) but at least the RETURN problem is fixed.