Shop OBEX P1 Docs P2 Docs Learn Events
Self-modified code execution timing — Parallax Forums

Self-modified code execution timing

Mark SwannMark Swann Posts: 124
edited 2007-10-08 04:04 in Propeller 1
If, due to pipelining issues beyond our control,·it is true that·we must insert at least·one·NOP, or perhaps something more meaningful, before an instruction that has been modified with MOVS,·MOVD or MOVI, then is the same true of a CALL or JMPRET if the first instruction in the subroutine is a return (i.e. RET)? (Please don't ask why I would do something so silly.)

Thanks

Comments

  • Ken PetersonKen Peterson Posts: 806
    edited 2007-10-07 19:28
    since the CALL or JMPRET is 4 cycles, I would guess that you still need the extra instruction.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    The more I know, the more I know I don't know.· Is this what they call Wisdom?
  • deSilvadeSilva Posts: 2,967
    edited 2007-10-07 19:58
    Yes, indeed. This is quite awkward!

    There might be people designing their program top-down according to some "stepwise refinement philosophy", first writing stubs with nothing but a RET in it....
  • Mike GreenMike Green Posts: 23,101
    edited 2007-10-07 20:04
    The CALL / RET issue is a bit more complex. It's the CALL instruction that's actually doing the store, so you can't CALL a RET and expect that it will work correctly. If you have any other instruction before the RET, you'll satisfy the timing requirement.
  • Fred HawkinsFred Hawkins Posts: 997
    edited 2007-10-07 20:50
    Mike, swap em?

    "CALL is a really a subset of the JMPRET instruction; in fact, it is the same opcode as JMPRET but
    with the i-field set (since CALL uses an immediate value only) and the d-field set to the address
    of a label named Address_ret.
    The return address is written to the Address_ret register unless the NR effect is specified."

    page 361
  • deSilvadeSilva Posts: 2,967
    edited 2007-10-07 21:01
    I just thought that the compiler could even check for this situation, as it is an unmistakeable bitpattern where dest and source have the same value and the i-bit is set....
  • deSilvadeSilva Posts: 2,967
    edited 2007-10-07 21:13
    lucidman said...
    ...due to pipelining issues...
    This is arguable; I should consider it a feature and not a bug smile.gif

    However as dest-address and new-instruction-address are available inside the processor at the right time, so - both being equal - it could postpone instruction fetch for 4 further cycles as it does in case of a conditional non-jump...
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2007-10-08 03:06
    It really is a feature! Due to pipelining, doing a jmpret to a ret will return to the previous caller and leave the caller's return address there for the next call. This is a way to implement task switching for a pair of coroutines, using immediate addressing. (For an example of coroutines using indirect addressing, see the TV.spin object.)

    -Phil
  • Mark SwannMark Swann Posts: 124
    edited 2007-10-08 04:04
    deSilva said...
    lucidman said...
    ...due to pipelining issues...
    This is arguable; I should consider it a feature and not a bug smile.gif

    However as dest-address and new-instruction-address are available inside the processor at the right time, so - both being equal - it could postpone instruction fetch for 4 further cycles as it does in case of a conditional non-jump...
    I did not intend to imply that it is a bug, but one must be aware of the issues that aren't intuitively predictable, such as waiting one extra instruction cycle before allowing a modified instruction to execute. Once you understand what's going on under the hood (bonnet to any Brits) , it all rather makes sense.

    Pipelines are great, except when they break. I'm sure you can ask a few native Alaskans about that. smilewinkgrin.gif
Sign In or Register to comment.