Shop OBEX P1 Docs P2 Docs Learn Events
[resolved] waitpeq — Parallax Forums

[resolved] waitpeq

kuronekokuroneko Posts: 3,623
edited 2008-04-23 02:26 in Propeller 1
The following code fragment, gives me a difference of 4 between after and before:

entry   mov before, CNT
        mov after, CNT


the next one results in 8

entry   mov before, CNT
        nop
        mov after, CNT


which is all expected (i.e. NOP consumes an extra 4 cycles).

This one however

entry   mov     before, CNT
        waitpeq :null, #0
        mov     after, CNT

:null   long    0


gives me 10 and not the expected 9. So the question is, why does waitpeq consume 6 cycles when the data sheet states 5+ (which I read as 5 minimum)?

Post Edited (kuroneko) : 5/19/2008 11:44:59 PM GMT

Comments

  • AleAle Posts: 2,363
    edited 2008-04-20 07:42
    waitpeq will wait for a pin to be equal to the given value, in your case there is no pin... I'd not know why 6 in that case... ground a PIN and test again against that PIN to see if it gives 5.
  • kuronekokuroneko Posts: 3,623
    edited 2008-04-20 07:55
    Ale said...
    waitpeq will wait for a pin to be equal to the given value, in your case there is no pin... I'd not know why 6 in that case... ground a PIN and test again against that PIN to see if it gives 5.

    Nope, same result.
  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2008-04-20 08:00
    But the mask is 0 so it shouldn't matter what the pins are. Both the data sheet and manual say 5+ which I would assume to be minimum 5 cycles so I don't know what goes on.
  • AleAle Posts: 2,363
    edited 2008-04-20 08:29
    It makes sense, if the pipeline gets stalled or something like that, I doubt the order of reading arguments is kept, Fetch write-back read-source read-dest execute fetch, and so on. if It gets stalled in the execute phase, as far as I remember.
  • kuronekokuroneko Posts: 3,623
    edited 2008-04-23 02:26
    Well, that may be the case (doesn't say anywhere in the docs).

    So is there a situation where 5+ holds true or should I always read this as 6+? I also noticed that the shortest delay for waitcnt (i.e. without waiting for CNT to wrap) causes waitcnt itself to consume 6 cycles. Which makes me believe that at least waitp* and waitcnt are 6+ while waitvid is still an unknown but probably in the same league.

    Edit: waitp* issue has been resolved (6+) http://forums.parallax.com/showthread.php?p=727279

    Post Edited (kuroneko) : 5/19/2008 11:44:26 PM GMT
Sign In or Register to comment.