[puzzle] waitcnt, is the destination/source field read before or after the wait?

tonyp12

Waitcnt is a read-modify-write instruction, just like Add is.
So you could say that it's just an Add that freezes midway.

After the required wait, the source fields value is added to the destination fields value
So internally it will do a read dest, add source, write dest.

Prove that the destination fields value is read before the wait or at time of exit.

Phil Pilgrim (PhiPi)

It's the destination's value that determines when to stop waiting and continue execution. If it weren't read before the wait, there would be no way for the instruction to know how long to wait. A more interesting question might be to prove when the source value is read (before the wait, or just prior to adding it), since it's what gets added to the destination to get the next wait target. This could easily be determined by using phsx of an operating counter as the source register. I'm sure it's read in the normal pipeline order, though: i.e. before the wait is executed.

-Phil

tonyp12

More about proving the destination field is not double read.

Once by the cogs wait and cmp routine that halts pc
And then on exit its run as regular Add from scratch. (that for some reason it saved ic curcuit estate to do so)
Question:
By putting phsx in dest field with its pseudo shadow properties could you prove or disprove that?
What other ways could you use to prove/disprove that's the case.

Or you could change the puzzle to when is scr read (much simpler)

Is waitcnt just an Add that freezes midway at one of the two choices below:
dest , source, (wait) ,dest
dest , (wait), source ,dest

kuroneko

tonyp12 wrote: »

More about proving the destination field is not double read.

Once by the cogs wait and cmp routine that halts pc
And then on exit its run as regular Add from scratch. (that for some reason it saved ic curcuit estate to do so)

I think you're asking the wrong question here. All wait* instructions are based on add. If there is a two stage process involved (wait-circuitry and ALU) then - based on your statement above - you'd have to double read src as well (for waitpxx). And that's not going to fly as you only have 2 cycles left after the match. Evidently src isn't re-fetched so there is no reason for dst to be treated differently.

Besides, why would the operand fetch behaviour be different for wait* instructions? Even a nop follows the src/dst/live src pattern.

Phil Pilgrim (PhiPi)

If there's an interesting question buried in this puzzle, it might be this: "When does the addition take place [Edit: no way to know] result of the addition get written? Before the wait or after?" Here's a program and the scope trace which proves that, as expected, it takes place after the wait:

CON

  _clkmode      = xtal1 + pll16x
  _xinfreq      = 5_000_000

PUB  start

  cognew(@tester, 0)

DAT

              org       0
tester        mov       dira,#3

loop          mov       outa,cnt
              add       outa,#32
              andn      outa,#1
              or        outa,#2
              waitcnt   outa,#1
              andn      outa,#2
              jmp       #loop

Channel1 is outa[0]; channel 2, outa[1].

-Phil