Searching \ for 'CLRW instruction side effects? [OT]' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=
Search entire site for: 'CLRW instruction side effects? [OT]'.

Truncated match.
PICList Thread
'CLRW instruction side effects? [OT]'
1998\08\27@115649 by Dmitry Kiryashov

flavicon
face
Dmitry Kiryashov wrote:

> I join with Chip question. What real code CLRW instruction compiled to ?

Just refine the question: It is interesting which code the CLRW is
compiled to
in case of other than standart MPASM compiler. Last MPASM is produced
something
like that:

clrf STATUS,w

according to my understanding of 0103h code.

WBR Dmitry.

1998\08\27@125220 by Chip Weller

flavicon
face
Dmitry Kiryashov wrote:


>Dmitry Kiryashov wrote:
>
>> I join with Chip question. What real code CLRW instruction compiled
to ?
{Quote hidden}

I have been using the Hi-Tech PIC C with its assembler. It appears to
assemble "clrw" as "clrf INDF,w" (0x100). It is interesting that
Microchip has used a different encoding. I scanned some old application
notes and noticed that Microchip used address 0 way back, at least on
its 12-bit systems. I don't use clrw very often, and will use it even
less often in the future.

Chip Weller

1998\08\27@141637 by shadedemon

picon face
Or why there is a CLRW instruction when ANDLW 0x00 works
just the same?  But if they're going to have a CLRF
instruction it is no more to have CLRW since it's CLRF
xx,w.  It specifically says the xx file address doesn't
matter if w is the destination though..


Dmitry Kiryashov wrote:
{Quote hidden}

1998\08\28@004428 by Dmitry Kiryashov

flavicon
face
It seems to me that first of all PIC read register xxxx then reset this
value
to zero then put zero value to W register. If register addr is 0 and FSR
is point
to some area of i/o related registers this may result to corruption of
event
conditions.

I think in this manner because Mchip was correct this code from previous
0100h
as you mentioned below to 0103h at current version of MPASM.

Reading STATUS didn't corrupt any else register and truely set all
status flags ;-)

WBR Dmitry.


Tony Nixon wrote:
{Quote hidden}

1998\08\28@022315 by Tony Nixon

flavicon
picon face
Dmitry Kiryashov wrote:
>
> It seems to me that first of all PIC read register xxxx then reset this
> value
> to zero then put zero value to W register. If register addr is 0 and FSR

I don't get the point of this at all.

CLRW = 0103 from MPASM (my version anyway)
f bit = 0

CLRF status = 0183 from MPASM
f bit = 1

CLRF Status,W is not allowed. (Illegal Character Error (,))
would imply that f bit = 0 and 1 at the same time

[Could be wrong mode ON]

The difference in code is that the 'f' bit is set for CLRF, obviously so
that the zero value is put into the register in question.
The 'f' bit is clear for CLRW instruction and any register address is
ignored.
Even if the PIC reads the value from the address supplied, surely the
data would be modified.

Here's another one...

The only real difference with a NOP instruction and MOVWF is the 'f'
bit. If 'f' = 1 then the PIC would use bits 0 to 7 for the RAM address
to put the W reg data in, indirect or not. Because 'f' = 0 in a NOP, the
address data would be ignored and is meaningless. You can't tell me that
these instructions get confused in the PIC.

[Could be wrong mode OFF]

Gee I'm glad it's Friday. I know where there is a beer can with my name
on it :-)

--
Best regards

Tony

Multimedia 16F84 Beginners PIC Tools.
**New PicNPrac**

http://www.picnpoke.com
Email spam_OUTpicnpokeTakeThisOuTspamcdi.com.au

1998\08\28@105733 by Dmitry Kiryashov

flavicon
face
Tony Nixon wrote:

> The difference in code is that the 'f' bit is set for CLRF, obviously so
> that the zero value is put into the register in question.
> The 'f' bit is clear for CLRW instruction and any register address is
> ignored.
 ???????

> Even if the PIC reads the value from the address supplied, surely the
> data would be modified.

Another try ;-) I told about some modification in flags only due to some
register is pointed by FSR being reading because CLRW code is wrongly
point
to INDF register. It is only MPASM know why clrf REG,w is incorrect ;-)
If I could be a Microchip designer I'll implement such a hidden joke ;-)
For such case CLRF reg,f will be translated to 00 0001 1fff ffff while
CLRF reg,w(CLRW) will be translated to 00 0001 0fff ffff. I think PIC
exe-
cute something like that in real hardware instead of masking and reading
from special dumb address.


> Here's another one...
> The only real difference with a NOP instruction and MOVWF is the 'f'
> bit. If 'f' = 1 then the PIC would use bits 0 to 7 for the RAM address
> to put the W reg data in, indirect or not. Because 'f' = 0 in a NOP, the
> address data would be ignored and is meaningless. You can't tell me that
> these instructions get confused in the PIC.

It is easy too ;-) MOVWF reg,f command is compiled to 00 0000 1fff ffff
while NOP is compiled to 00 0000 0xx0 0000. See the differency.

> Gee I'm glad it's Friday. I know where there is a beer can with my name
> on it :-)

Agreed with you totally in this question ;-)))

WBR Dmitry.

1998\08\30@084310 by Alex Torres

picon face
>It seems to me that first of all PIC read register xxxx then reset this
>value
>to zero then put zero value to W register. If register addr is 0 and FSR
>is point
>to some area of i/o related registers this may result to corruption of
>event
>conditions.
>
>I think in this manner because Mchip was correct this code from previous
>0100h
>as you mentioned below to 0103h at current version of MPASM.
>
>Reading STATUS didn't corrupt any else register and truely set all
>status flags ;-)
>
>WBR Dmitry.


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 ?

==================================
Alex Torres, Kharkov, Ukraine (exUSSR)
E-Mail: .....altorKILLspamspam@spam@geocities.com
2:461/28 FidoNet
Home Page: www.geocities.com/SiliconValley/Lab/6311
ICQ UIN  11083325

1998\08\31@123237 by John Payson

flavicon
face
|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.

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...