Shop OBEX P1 Docs P2 Docs Learn Events
[resolved][puzzle] If a tree falls ... — Parallax Forums

[resolved][puzzle] If a tree falls ...

kuronekokuroneko Posts: 3,623
edited 2011-05-20 02:58 in Propeller 1
... let me rephrase that: If tj[n]z has the wr flag set is dst written to or not? Setting the flag doesn't seem to have a discernible effect on dst so how would you dis/prove that wr isn't simply ignored for this instruction?

Comments

  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-15 18:06
    You pose an interesting riddle. I have no idea even what effect these could have on the destination.
  • AribaAriba Posts: 2,690
    edited 2011-05-15 23:27
    kuroneko

    sent a solution to you by PM

    Andy
  • kuronekokuroneko Posts: 3,623
    edited 2011-05-15 23:36
    Ariba wrote: »
    sent a solution to you by PM
    10/10
  • CogSaverCogSaver Posts: 17
    edited 2011-05-17 06:07
    Kuroneko

    As pr my previous PM I have now verified that my suggested solution works.

    CogSaver
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-17 06:46
    This is the only way I can think to thoroughly test this. 
    CON
   _CLKMODE = XTAL1 +PLL8X
   _XINFREQ = 6_000_000

PUB BB
  '...Insert other need startup code (serial/VGA etc)...
  COGNEW(@PSTRT,0)
DAT

PSTRT  ORG 0
PLOOP      SUB PVAL,#1
           SUB OVAL,#1
           SUB OVAL,PVAL nr,wz,wc
    if_ne  JMP DONE0
           TJNZ PVAL,#PLOOP  wr
DONE0
           '...
           'Insert code to output PVAL, and OVAL
           '...
FOREVR     JMP FOREVR

OVAL       LONG $00010000
PVAL       LONG $00010000
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-17 07:05
    Actually If you wanted to be 100%, you would have to initialise OVAL and PVAL to 0, thus the first used value is $FFFF_FFFF.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-17 07:10
    Ok I will do it correctly: 
    CON
   _CLKMODE = XTAL1 +PLL16X
   _XINFREQ = 6_000_000

PUB BB
  '...Insert other need startup code (serial/VGA etc)...
  COGNEW(@PSTRT,0)
DAT

PSTRT  ORG 0
PLOOP      SUB PVAL,#1
           SUB OVAL,#1
           SUB OVAL,PVAL nr,wz,wc
    if_ne  JMP DONE0
           TJNZ PVAL,#PLOOP  wr
DONE0
           '...
           'Insert code to output PVAL, and OVAL.
           '...
           JMP PSTRT

OVAL       LONG 0
PVAL       LONG 0
    Run time before first result at 96MHz is about 12Minutes.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-17 07:36
    If you look at pasmsim.c in SpinSim, the tj[n]z instruction just writes the original value back to the cog memory location if the WR flag is set. I would expect that tj[n]z is implemented as a special case of djnz, except that the value is not decremented. So the only way you could get a different result is if something else modified the memory location. I don't how that's possible. It goes counter to my understanding of a predicatable programmable processor.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-17 07:53
    Dave Hein wrote:
    I would expect that tj[n]z is implemented as a special case of djnz, ...
    If only that were true, but djnz uses up a unique opcode. I've often wondered why they could not share opcodes, and be differentiated by the wr bit. Then we could have had a much-needed djz instruction. In operation, however, a tjnz is not simply the same as a djnz without writing the result. The reason is that the result that determines whether the jump occurs or not is what the destation would have been had it been written, not what the destination ocntains after execution. So a djnz with nr would be a "test and jump if not equal to one."

    -Phil
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-17 07:54
    If there is nothing modified, it does not make any since to write anything back. For the sake of predictability it seems that it is best to treat TJ[N]Z as if it never wrote back. The exception being if something else modifies the location between the time that TJ[N]Z reads a location and the time it writes it back. I can not see a way to test for this case short of an accurate simulator (does one exist that is that accurate).
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-17 08:04
    davidsaunders wrote:
    The exception being if something else modifies the location between the time that TJ[N]Z reads a location and the time it writes it back.
    But that can't happen in the prop*. The result of a previous instruction is always written before the destination register of the current instruction is read.

    -Phil

    *With "two" exceptions: I think I just figured out the answer to the puzzle.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-17 08:17
    Phil, I think you misunderstood my comment. I'm not saying that djnz is dintiguished from tjnz by the WR bit. I'm just suggesting that the circuitry that implements tjnz may be the same as the circuitry that implements djnz, except that the decrementer is either bypassed or a "1" is not fed into it.

    The 6-bit PASM opcodes are grouped into 8 groups of 8. Each group treats the result, carry and zero bits in a similar fashion, but there are many exceptions. djnz, tjz and tjnz fall into the same group of 8, and yes, they do have unique opcodes. I was just speculating that these three instructions may be implemented by the same chunk of logic.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-17 08:20
    Phil Pilgrim (PhiPi) wrote: »
    But that can't happen in the prop*. The result of a previous instruction is always written before the destination register of the current instruction is read.
    David said "something else", which is not necessarily a previous instruction. The answer must be counter-intuative.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-17 08:22
    Dave,

    I got that, but your post triggered something I've thinking about for awhile which is, "Why don't they share opcodes? Then we could have djz, and there would be an opcode freed up for something else."

    -Phil
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-17 09:49
    Phil:
    You have me curious, do tell.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-17 10:01
    The instruction set for the Prop 2 contains TJZ, TJNZ, IJZ, IJNZ, DJZ and DJNZ plus delayed variations of these instructions. It uses 3 opcode to distinguish between the Txx, Ixx and Dxx instructions. I believe the WZ bit is used for JZ verus JNZ and the WC bit is used to select delayed versus non-delayed jumps.
  • Heater.Heater. Posts: 21,230
    edited 2011-05-17 10:16
    Aghhh, my brain.

    Dave, your nice rocket avatar is no longer burning away gently with my latest up date to firefox on Debian. It's manically flashing on and off instead.
    Not your fault of course, it's just going to be really annoying until a fix is found.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-17 12:17
    Heater. wrote: »
    Dave, your nice rocket avatar is no longer burning away gently with my latest up date to firefox on Debian. It's manically flashing on and off instead.
    Not your fault of course, it's just going to be really annoying until a fix is found.
    When we switched to the new forum I used a static version of the avatar that I got with a screen capture from the old forum. I replaced it with the animated version about a week ago. I noticed it flashed in one of the image viewers on Windows 7, but it looked OK in anything else I used. I'll try a few other browsers and image viewers to see if there's a problem with it.
  • Heater.Heater. Posts: 21,230
    edited 2011-05-17 12:33
    Still looks OK in konqueror. Can't get chromium to run here just now. Other animated avatars around here are still working.
  • kuronekokuroneko Posts: 3,623
    edited 2011-05-17 16:38
    davidsaunders wrote: »
    If there is nothing modified, it does not make any since to write anything back.
    That's not the point of this exercise. Just show that wr is/n't ignored.

    Incidentally, you said Run time before first result at 96MHz is about 12Minutes. Did you get a result or is/was that pure speculation?
  • tonyp12tonyp12 Posts: 1,951
    edited 2011-05-17 17:58
    Due to pipelining, what if you self-modify the d-field?

    movd label:,#0
    label: TJNZ PVAL,#PLOOP wr
    test label:,mask wz
  • kuronekokuroneko Posts: 3,623
    edited 2011-05-17 19:02
    tonyp12 wrote: »
    Due to pipelining, what if you self-modify the d-field? 
    movd label,#0
label   TJNZ PVAL,#PLOOP  wr
        test label,mask wz
    What do you expect to happen?
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-17 19:13
    kuroneko wrote:
    Did you get a result or is/was that pure speculation?
    The result I got was not conclusive.
  • kuronekokuroneko Posts: 3,623
    edited 2011-05-19 20:31
    Before this gets stale, I've seen 3 valid tests so far (not counting mine). They all prove that wr does in fact have an effect despite not being obvious. Thanks to everyone who contributed.

    As usual, for the terminally curious: 
    movi    ctra, #%0_11111_000     ' LOGIC always, moving target
mov     frqa, #1                ' non-null increment
tjnz    phsa, #$+1 wr           ' instruction under test
mov     temp, phsa              ' temp = f(wr)
  • Heater.Heater. Posts: 21,230
    edited 2011-05-19 20:37
    Always thought we would need those counters for something:)
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-19 22:44
    I have a feeling kuroneko will be frustrated with the Prop II, though, since the phsx registers won't be in the cog's address space, but hidden behind special access instructions. :( OTOH, they probably won't be necessary for the kinds of service he's pressed them into on the Prop I. :)

    -Phil
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-05-20 02:58
    Oh I think kuroneko will still have fun finding obscurities in PropII. Goodness knows what goodies we will all find.
Sign In or Register to comment.