P2 Tricks, Traps & Differences between P1 (Reference Material Only)

124»

Comments

  • Dave HeinDave Hein Posts: 6,028
    edited 2020-03-13 - 02:51:15
    Jon, I think Roy is just saying that your statement about the maximum limit for milliseconds has a typo. Instead of
    -- waitms() is limited to 2^31 / clkfreq milliseconds (e.g., 10737 ms at 200MHz)
    
    it should be
    -- waitms() is limited to 2^31 / (clkfreq/1_000) milliseconds (e.g., 10737 ms at 200MHz)
    
  • Cluso99Cluso99 Posts: 16,147
    edited 2020-05-17 - 11:01:04
    Spin v Spin2: LOCKSET v LOCKTRY

    In spin we did
    repeat while(lockset(LockID))
    
    whereas in spin2
    repeat while not (locktry(LockID))
    
    Note the reversed status return ie the NOT requirement

    Postedit: Fixed the second line (remove -1 and rename)
  • Cluso99 wrote: »
    Spin v Spin2: LOCKSET v LOCKTRY

    In spin we did
    repeat while(lockset(LockID))
    
    whereas in spin2
    repeat while not (locktry(cardLockID - 1))
    
    Note the reversed status return ie the NOT requirement

    Isn't there a REPEAT UNTIL that is the same as REPEAT WHILE NOT (except potentially faster?)
  • Don't use REP in HUBEXEC if you care about speed.

    Just discovered (or maybe rediscovered) that the SD card reading code, FSRW, was twice as fast when I unrolled a REP loop in inline assembly.
    The P2 documentation says this: "REP works in hub memory, as well, but executes a hidden jump to get back to the top of the repeated instructions."
    What it doesn't say is that this makes it slow...
  • Rayman wrote: »
    Don't use REP in HUBEXEC if you care about speed.

    Just discovered (or maybe rediscovered) that the SD card reading code, FSRW, was twice as fast when I unrolled a REP loop in inline assembly.
    The P2 documentation says this: "REP works in hub memory, as well, but executes a hidden jump to get back to the top of the repeated instructions."
    What it doesn't say is that this makes it slow...
    It’s any jumps, calls and rets as well as reps that cause a fifo load and a pause to sync the hub egg-beater that cause hubexec to be slower than cog or LUT.
  • Cluso99Cluso99 Posts: 16,147
    edited 2020-05-25 - 03:07:24
    I/O PIN TIMING

    Warning:
    Please be aware that the documentation Parallax Propeller 2 Documentation 2019-09-13 v33 (Rev B silicon) appears to be incorrect.

    At 200MHz the clocks between an OUTx instruction and a following TESTP instruction appears to require a minimum of 7 clocks (waitx #5).

    At 200MHz the clocks between an OUTx instruction and a following TEST instruction appears to require a minimum of 8 clocks (waitx #6).

    Further clarification has been requested.
  • REP was only meant for cog exec but Chip made it execute a jmp if you tried to use it in hubexec, simply for source code compatibility. I find hubexec is almost or just as fast as cog exec if you have a large linear section of code to execute. Just one jump or looping will slow it all down again.
    However, if you need loops and you still want it fast but can't dedicate the memory for it in cog/lut, you use a SETQ + RDLONG at the start of your hubexec code and copy the code into cog or lut (SETQ2) and jump to that.
    This is something I certainly do for my upscaler from 320x240 to 640x480 in my video player.
Sign In or Register to comment.