c-flag for movs/movd/movi instructions?

ags · 2013-08-23 12:13

Can anyone offer a precise explanation of when the c-flag is set with the movd & movs instructions? It can't be random (but it might not be useful). There is no specific treatment in the text and there are not enough entries in the concise truth table to figure it out. One guess (based on the truth tables) would be c is set if the 9th bit of the 9 set with each instruction is changed from a 0 to 1 after the operation. It would be consistent with mov if it was simply S:8 (as mov is S:31].

Also, has anyone reported the error regarding the text explanation of the z-flag (Propeller Manual v 1.2)? It is not set based on Value=0, but on Result=0. This appears to be the same text used for mov, where Value=Result; that's not the case here. Note the opcode table correctly states z set if Result=0.

Phil Pilgrim (PhiPi) · 2013-08-23 13:11

I used the following program to generate additional examples:

CON

  _clkmode      = xtal1 + pll16x
  _xinfreq      = 5_000_000

  LED_PIN       = 16

PUB  start | i

  cognew(@tst, 0)

DAT

              org       0
tst           mov       dira,mask

              movd      target,#511 wc
              muxc      outa,mask
:forever      jmp       #:forever

target        long      0

mask          long      1 << LED_PIN

Based upon cursory testing, it would appear that C is set iff the destination register started out zero and became non-zero as a result of the movx. Nope, 'found a counter-example.

Further testing hints that C is an unsigned borrow resulting from dst - src (all 32 bits of each), regardless of which field the movx is destined for. If so, it could actually be useful in the case of movs.

This result, if it holds up, is not surprising, since the movx instructions are in the same block of opcodes as min and max. And I'd almost bet that jmpret, which is also in that block, behaves the same way.

-Phil

ags · 2013-08-23 16:29

Phil Pilgrim (PhiPi) wrote: »

If so, it could actually be useful in the case of movs.-Phil

This is not just an academic exercise. I actually have an application where if I can take advantage of movx setting the carry flag, I can use that in a timing-critical subroutine to signal success/failure using the c-flag. (the z-flag can't work for me without adding an instruction)

I was thinking of writing some code like yours, only looping over "interesting" blocks of values. Unfortunately, its analyzing the output and finding the pattern that is the hard part.

I'm somewhat surprised that with all the detailed work that's been done with the Propeller since its introduction, no one asked/answered this yet. Is there a way to ask a question and get a definitive from the folks at Parallax, those with the "source code" so to speak?

Thanks.

kuroneko · 2013-08-23 17:15

ags wrote: »

I'm somewhat surprised that with all the detailed work that's been done with the Propeller since its introduction, no one asked/answered this yet. Is there a way to ask a question and get a definitive from the folks at Parallax, those with the "source code" so to speak?

This question has been answered [post=864343]before[/post] (there are most likely older posts). But unless it ends up in a central place, i.e. datasheet, it will all happen again. As for the rest, raise a support ticket with them.

c-flag for movs/movd/movi instructions?

Comments