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

124»

Comments

  • Dave HeinDave Hein Posts: 6,139
    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,595
    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,595
    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.
  • Cluso99Cluso99 Posts: 16,595
    edited 2020-06-16 - 07:52:53
    Just fell into this trap for loading LUT.

    You must make sure that the rdlong address uses a HUB address and not a LUT address.
    Note the positioning of the labels _hub_lut_begin and _USER_LUT_BEGIN with respect to ORGH and ORG $200,
    or the use of @
    '+-------[ Load LUT code ??? ]-------------------------------------------------+
                  setq2     ##_USER_LUT_END-_USER_LUT_BEGIN-1 '\ load LUT
    '             rdlong    0, ##_USER_LUT_BEGIN              '/   <-- uses a LUT address (wrong)
                  rdlong    0, ##_hub_LUT_BEGIN               '/   <-- uses a hub address (correct)
    '             rdlong    0, ##@_USER_LUT_BEGIN             '/   <-- uses a hub address (correct)
    '+-----------------------------------------------------------------------------+
    .....
                            orgh
    _hub_lut_begin
                            org     $200                            ' LUT
    _USER_LUT_BEGIN
    
    go_lut        drvl      #57
                  mov       lmm_x,      #"L"
                  call      #\_hubTx
                  ret
    
    _USER_LUT_END
    
    Postedit: added version using @ per the following post
  • You can always use "@_USER_LUT_BEGIN" if you want the hub address of "_USER_LUT_BEGIN", rather than creating a new label for this.
Sign In or Register to comment.