An Issue with REP blocks, Single step interrupts and HUB execution

13»

Comments

  • ozpropdev wrote: »
    Seairth wrote: »
    Does it work for D>1 and the last instruction in the REP block is a JMP? (I can't look at your test code at the moment.)
    I had tested for D>1 which worked OK, but in all my tests I hadn't tried JMP as the last instruction in the block.
    Your onto something there Seairth, it seems that if the last instruction is a JMP the issue raises it's head again.
    I'll keep digging....

    We could just have a rule that no branches are allowed within a REP block.
  • IIRC to switch execution modes it's enough to JMP in the right (address) execution space, isn't it?
    In this case I think that every REP loop (I mean in every exec mode) has to be tested for both cases, JMP into same mode and JMP into different mode.
    cgracey wrote: »
    We could just have a rule that no branches are allowed within a REP block.
    Isn't (conditional) JMP within REP an efficient way to replicate "do-until" or "do-while" structures with timeout (max count at given clock)?

    Propeller Object Exchange (last Publications / Updates) --- Oldbitcollector's guest map
    JustForMe
  • cgracey wrote: »
    We could just have a rule that no branches are allowed within a REP block.
    That would simplify things

    Melbourne, Australia
  • dMajo wrote: »
    In this case I think that every REP loop (I mean in every exec mode) has to be tested for both cases, JMP into same mode and JMP into different mode.
    All of my REP tests did just that.
    Three different tests, jump to the same exec mode and jump to the other two modes.


    Melbourne, Australia
  • dMajo wrote: »
    IIRC to switch execution modes it's enough to JMP in the right (address) execution space, isn't it?
    In this case I think that every REP loop (I mean in every exec mode) has to be tested for both cases, JMP into same mode and JMP into different mode.
    cgracey wrote: »
    We could just have a rule that no branches are allowed within a REP block.
    Isn't (conditional) JMP within REP an efficient way to replicate "do-until" or "do-while" structures with timeout (max count at given clock)?

    It's slightly more efficient than a branching loop, as the loop is automatic, but it's really valuable for repeating just a few instructions, since that's where overheadless looping makes a significant difference.
  • Instead of cancelling a REP block with a JMP instruction what about a "QUIT" instruction that cancels the REP block and simply ignores any remaining instructions in the block (treats remaining instructions as NOP's).
    Melbourne, Australia
  • Chip's got a point. While it's nice to have the option of conditions, the moment they are added then a regular loop construct may as well be used instead.
    Money is a placeholder for cooperation.
  • The only solid reason I can think of breaking a REP is for interrupts, but that would also need the ability to subsequently resume the REP.
    Money is a placeholder for cooperation.
  • SeairthSeairth Posts: 1,900
    edited January 27 Vote Up0Vote Down
    ozpropdev wrote: »
    Instead of cancelling a REP block with a JMP instruction what about a "QUIT" instruction that cancels the REP block and simply ignores any remaining instructions in the block (treats remaining instructions as NOP's).

    Actually, QUIT (REXIT?) could use the same encoding as REP #0, #0! In other words, if there's an active REP, QUIT NOP's the remaining instructions. If there's not an active REP, it's just a NOP itself.
  • Seairth wrote: »
    ozpropdev wrote: »
    Instead of cancelling a REP block with a JMP instruction what about a "QUIT" instruction that cancels the REP block and simply ignores any remaining instructions in the block (treats remaining instructions as NOP's).

    Actually, QUIT (REXIT?) could use the same encoding as REP #0, #0! In other words, if there's an active REP, QUIT NOP's the remaining instructions. If there's not an active REP, it's just a NOP itself.

    Good point. Doing a 'REP #0, S/#' would turn REP off. We could have an assembler alias, "REPQ" that is really "REP #0,#0".
  • Maybe we figured out a long time ago that jumping out of a REP loop was too much trouble to deal with?

    This sounds like adding new features to me, which I wish we'd stop doing...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Maybe we figured out a long time ago that jumping out of a REP loop was too much trouble to deal with?

    This sounds like adding new features to me, which I wish we'd stop doing...

    Maybe we did. I don't remember. I'm just trying to make it work right.
  • cgracey wrote: »
    Seairth wrote: »
    ozpropdev wrote: »
    Instead of cancelling a REP block with a JMP instruction what about a "QUIT" instruction that cancels the REP block and simply ignores any remaining instructions in the block (treats remaining instructions as NOP's).

    Actually, QUIT (REXIT?) could use the same encoding as REP #0, #0! In other words, if there's an active REP, QUIT NOP's the remaining instructions. If there's not an active REP, it's just a NOP itself.

    Good point. Doing a 'REP #0, S/#' would turn REP off. We could have an assembler alias, "REPQ" that is really "REP #0,#0".

    Except, in this case, I think REPQ should also NOP the remaining instructions in the REP block.
Sign In or Register to comment.