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

kuroneko · 2011-05-15 17:39

... 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?

davidsaunders · 2011-05-15 18:06

You pose an interesting riddle. I have no idea even what effect these could have on the destination.

Ariba · 2011-05-15 23:27

kuroneko

sent a solution to you by PM

Andy

kuroneko · 2011-05-15 23:36

Ariba wrote: »

sent a solution to you by PM

10/10

CogSaver · 2011-05-17 06:07

Kuroneko

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

CogSaver

davidsaunders · 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

davidsaunders · 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.

davidsaunders · 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 Hein · 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) · 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

davidsaunders · 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) · 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 Hein · 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 Hein · 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) · 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

davidsaunders · 2011-05-17 09:49

Phil:
You have me curious, do tell.

Dave Hein · 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. · 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 Hein · 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. · 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.

kuroneko · 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?

tonyp12 · 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

kuroneko · 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?

davidsaunders · 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.

kuroneko · 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. · 2011-05-19 20:37

Always thought we would need those counters for something:)

Phil Pilgrim (PhiPi) · 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

Cluso99 · 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.

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

Comments