Prop2 Interactive debugger

24567

Comments

  • Seairth wrote: »
    Or are you saying that the DRVH was cancelled?
    No, the DRVH instruction was executed but should have been executed in the "next" step like the SKIPF variant did.
    Melbourne, Australia
  • ozpropdev wrote: »
    Seairth wrote: »
    Or are you saying that the DRVH was cancelled?
    No, the DRVH instruction was executed but should have been executed in the "next" step like the SKIPF variant did.

    Oh! I think I get what you are saying. An active SKIP disables interrupts, including the debug interrupt. Therefore, a pending debug interrupt should trigger on the instruction immediately after the last skipped instruction, which would be the DRVH instructions. In the case of SKIP, the interrupt occurred after DRVH. But, in the case of SKIPF, it interrupted correctly (prior to DRVH). Is that correct?
  • Ozpropdev,

    I believe I fixed the problem. Try this:

    https://drive.google.com/file/d/0B9NbgkdrupkHUEZ3VExnN0VZZXc/view?usp=sharing

    There's a two-cog/no-CORDIC image for the Prop123_A9 board in there, as well as a new PNut.exe which fixes the problem with AUGS/AUGD working with _RET_.
  • cgraceycgracey Posts: 8,374
    edited March 29 Vote Up0Vote Down
    Ozpropdev, one other thing:

    SKIPF and EXECF can now work in hub space, too, but they revert to cancelling instructions, like SKIP does. This matters for EXECF only if a subsequent branch gets you into hub memory, while there are still skip bits queued. This way, SKIPF/EXECF code could run faster in the cog/LUT space, but still works in hub space.

    Maybe you could check that out.
  • Chip
    SKIP looks good now, works as expected. :)
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00005: FD641C31              SKIP    #$00E
    00006: FD644049              OUTH    #$020
    00007: FD644249 <cancel>     OUTH    #$021
    00008: FD644449 <cancel>     OUTH    #$022
    00009: FD644649 <cancel>     OUTH    #$023
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    0000A: FD645E59              DRVH    #$02F
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    0000B: FD641C32              SKIPF   #$00E
    0000C: FD645049              OUTH    #$028
    0000D: FD645249 <skipped>    OUTH    #$029
    0000E: FD645449 <skipped>    OUTH    #$02A
    0000F: FD645649 <skipped>    OUTH    #$02B
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00010: FD645C59              DRVH    #$02E
    (? for help) >
    
    Melbourne, Australia
  • cgraceycgracey Posts: 8,374
    edited March 29 Vote Up0Vote Down
    ozpropdev wrote: »
    Chip
    SKIP looks good now, works as expected. :)
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00005: FD641C31              SKIP    #$00E
    00006: FD644049              OUTH    #$020
    00007: FD644249 <cancel>     OUTH    #$021
    00008: FD644449 <cancel>     OUTH    #$022
    00009: FD644649 <cancel>     OUTH    #$023
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    0000A: FD645E59              DRVH    #$02F
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    0000B: FD641C32              SKIPF   #$00E
    0000C: FD645049              OUTH    #$028
    0000D: FD645249 <skipped>    OUTH    #$029
    0000E: FD645449 <skipped>    OUTH    #$02A
    0000F: FD645649 <skipped>    OUTH    #$02B
    (? for help) >*
    -----------------------------------------------------------------------------------------(P2 Debugger)
    00010: FD645C59              DRVH    #$02E
    (? for help) >
    

    Super! I had erred on the side of caution, at first, because I wasn't completely sure.
  • Chip
    No joy with _ret_ and AUGD and WRLUT playing together.
    dat	org
    
    		or	dirb,##$ffff
    
    		call	#op1
    		rdlut	ax,#0
    		or	outb,ax
    
    		call	#op2
    		rdlut	ax,#0
    		or	outb,ax
    
    		call	#op3
    		rdlut	ax,#0
    		or	outb,ax
    
    		outh	#33
    
    here		jmp	#here
    
    op1	_ret_	wrlut	#1,#0		'ok
    
    op2		wrlut	##$8000,#0	'ok
    		ret
    
    op3	_ret_	wrlut	##$4000,#0	'returns ok but wrlut cancelled
    
    
    ax	res	1
    


    Melbourne, Australia
  • ozpropdev wrote: »
    Chip
    No joy with _ret_ and AUGD and WRLUT playing together.

    Woops, sorry! I modified the assembler, but didn't recompile the main app. Try this:

    https://drive.google.com/file/d/0B9NbgkdrupkHcTkwOE1ac3hlT1U/view?usp=sharing
  • Chip
    V17b fixed issue with ret_/augd/wrlt combination.
    Looking good. :cool:
    Melbourne, Australia
  • SeairthSeairth Posts: 2,252
    edited March 30 Vote Up0Vote Down
    Chip, can you also see if there's a bug in pnut with explicit calls to AUGD? When I took Op2 above:
    op2		wrlut	##$8000,#0
    		ret
    

    and changed it to
    op2		augd	#$40
    		wrlut	#0,#0
    		ret
    

    the AUGD gets encoded as FF800000 instead of FF800040.
  • Try
    op2		augd	#$40 << 9
    		wrlut	#0,#0
    		ret
    
    Melbourne, Australia
  • ozpropdev wrote: »
    Try
    op2		augd	#$40 << 9
    		wrlut	#0,#0
    		ret
    

    That worked, but is that intentional? I don't see a mention of this in the documentation or the instruction list.
  • Seairth wrote: »
    That worked, but is that intentional? I don't see a mention of this in the documentation or the instruction list.
    This would have worked too.
    Pnut ignores the lower 9 bits for AUGx instructions.
    op2		augd	#$8000
    

    Melbourne, Australia
  • cgraceycgracey Posts: 8,374
    edited March 30 Vote Up0Vote Down
    Seairth wrote: »
    ozpropdev wrote: »
    Try
    op2		augd	#$40 << 9
    		wrlut	#0,#0
    		ret
    

    That worked, but is that intentional? I don't see a mention of this in the documentation or the instruction list.

    Here's from the spreadsheet:
    EEEE 11110NN NNN NNNNNNNNN NNNNNNNNN	AUGS    #N
    
    Queue N to be used as upper 23 bits for next #S occurrence, so that the next 9-bit #S will be augmented to 32 bits.
    

    AUGS/AUGD have 23 bits of operand. They get tacked on above the 9-bit #S/#D of the next instruction using #S/#D.

    Ah.... Sorry! I see what you were getting at. I made the assembler just grab bits 31..9 of the operand for AUGS/AUGD. I figured it would be easier to use. I need to do something about the spreadsheet explanation, though.
  • ozpropdev wrote: »
    Chip
    V17b fixed issue with ret_/augd/wrlt combination.
    Looking good. :cool:

    Ah, thanks. I didn't see this, at first.
  • SeairthSeairth Posts: 2,252
    edited March 30 Vote Up0Vote Down
    either way, why? if someone is explicitly using AUGx, shouldn't they know what the value should be? Why make this one instruction work differently from all others?

    edit: Never mind. Chip's update in the spreadsheet is clear enough. No need to dwell on this...
  • cgraceycgracey Posts: 8,374
    edited March 30 Vote Up0Vote Down
    Ozpropdev, have you tried SKIPF in hub memory? It should work just like SKIP, cancelling instructions. Only v17a does it. I might make another release soon just to update this minor issue, but it could wait a little bit, in case some problems are discovered.
  • cgracey wrote: »
    Ozpropdev, have you tried SKIPF in hub memory? It should work just like SKIP, cancelling instructions. Only v17a does it. I might make another release soon just to update this minor issue, but it could wait a little bit, in case some problems are discovered.
    SKIPF appears to be working fine in HUBEXEC. :)

    Melbourne, Australia
  • ozpropdevozpropdev Posts: 1,979
    edited March 30 Vote Up0Vote Down
    Chip
    Hold off on the compile for a bit.
    Some weirdness with SKIPF in cog now
    .
    I'll get back to you.

    Edit: Doh! My bad, V17b is working correctly.
    Melbourne, Australia
  • ozpropdev wrote: »
    Chip
    Hold off on the compile for a bit.
    Some weirdness with SKIPF in cog now
    .
    I'll get back to you.

    Edit: Doh! My bad, V17b is working correctly.

    How about SKIPF branching from cog to hub and back again with a skip pattern?
  • Chip
    This worked Ok.
    SKIPF from cog to hub and back
    dat	org
    
    	skipf	#%11000
    	drvh	#32
    	jmp	#hubx
    cogx	drvh	#47
    
    here	jmp	#here
    
    	orgh	$7000
    hubx	drvh	#33
    	drvh	#40	'cancel
    	drvh	#41	'cancel
    	jmp	#cogx
    
    Melbourne, Australia
  • cgraceycgracey Posts: 8,374
    edited March 30 Vote Up0Vote Down
    ozpropdev wrote: »
    Chip
    This worked Ok.
    SKIPF from cog to hub and back
    dat	org
    
    	skipf	#%11000
    	drvh	#32
    	jmp	#hubx
    cogx	drvh	#47
    
    here	jmp	#here
    
    	orgh	$7000
    hubx	drvh	#33
    	drvh	#40	'cancel
    	drvh	#41	'cancel
    	jmp	#cogx
    

    How about one more instruction between 'cogx' and 'here', and testing one-bits out to that instruction? How they behave around the jumps is important.
  • cgracey wrote: »
    How about one more instruction between 'cogx' and 'here', and testing one-bits out to that instruction? How they behave around the jumps is important.

    I'm maybe pushing my luck here but this nearly worked!
    dat	org
    
    'cog-hub-cog-hub-cog skipf test
    
    	skipf	## |<3 | |<4 | |<7 | |<8 | |<12 | |<14
    	drvh	#32			'0
    	jmp	#hubx			'1
    
    cogx	drvh	#33			'6
    	drvh	#40	'cancel		'7	'ok
    	drvh	#41	'cancel		'8	'ok
    	drvh	#34			'9
    	drvh	#35			'10
    	jmp	#hubx2			'11
    
    cogx2	drvh	#36			'16
    	drvh	#37			'17
    
    here	jmp	#here
    
    	orgh	$7000
    hubx	drvh	#38			'2
    	drvh	#42	'cancel		'3	'ok
    	drvh	#43	'cancel		'4	'ok
    	jmp	#cogx			'5
    
    hubx2	drvh	#44	'cancel		'12	'executes!
    	drvh	#39			'13	'cancels!
    	drvh	#45	'cancel		'14	'executes!
    	jmp	#cogx2			'15
    

    Seems to have got out of step in the last stage.
    I am breaking the riles...
    Melbourne, Australia
  • ozpropdevozpropdev Posts: 1,979
    edited March 30 Vote Up0Vote Down
    Ok, the issue seems to be a Pnut AUGD/SKIPF bug.
    I changed the augmented immediate D


    Edit: Scratch the above theory.
    SKIP works fine in the above example.
    SKIPF nearly works except for the second hub snippet.
    Melbourne, Australia
  • cgraceycgracey Posts: 8,374
    edited March 30 Vote Up0Vote Down
    I'm seeing problems going from cog to hub using SKIPF.

    Aside from that, things are executing way faster than I understand. It seems that there is no rest cycle after a branch using SKIPF. It's hitting every needful instruction, anyway:
    dat	org
    
    	skipf	#%01011101
    	drvh	#32		'2 (cancelled)
    	jmp	#cogy		'4 (executed)
    
    cogx	drvh	#36		'0 (skipped)
    	drvh	#37		'2 (executed)
    	jmp	#$
    
    cogy	drvh	#33		'0 (skipped)
    	drvh	#34		'0 (skipped)
    	drvh	#35		'0 (skipped)
    	jmp	#cogx		'4 (executed)
    

    Here is what the pipeline sees:
    	skipf	#%01011101
    	drvh	#32		'2 (cancelled)
    	jmp	#cogy		'4 (executed)
    	jmp	#cogx		'4 (executed)
    	drvh	#37		'2 (executed)
    	jmp	#$
    

    I can't figure out how those JMPs are back-to-back. It looks like they are jumping directly to the address PLUS the needed skips! There's no time for that! In the above example, everything between the SKIPF and the JMP #$ took only 12 clocks.
  • SeairthSeairth Posts: 2,252
    edited March 30 Vote Up0Vote Down
    Here's my guess: it's because the jmp is relative. As soon as jmp #cogy is loaded in the pipeline, the instruction pointer is incremented by 3 because of the three skipped instructions (it has no idea that a branch is about to occur). If it weren't for the jump instruction, the next instruction to be executed would be drvh #33. In fact, I would expect you'd see this instruction in the pipeline. But as soon as the pipelined JMP instruction is executed, it adds 3 which is jmp $cogx. The drvh #33 in the pipeline would be cancelled, of course.

    But, if I am right, then this means that absolute branches will fail. In those cases, you cannot increment the IP until after the branch, or else you will end up skipping the wrong instructions that followed the branch.


    Edit: I finally got a chance to test this theory. Given the following code (note the absolute jumps)
    dat org
    
            skipf   #%01011101
            drvh    #32 
            jmp     #\cogy
    
    cogx    drvh    #36 
            drvh    #37 
            jmp     #$
    
    cogy    drvh    #33 
            drvh    #34 
            drvh    #35 
            jmp     #\cogx
    

    I am getting:
        skipf   #%01011101
        drvh    #32         ' skip[0]
        jmp     #\cogy      ' executed
                            ' <= skip[4..2]
        drvh    #33         ' loaded by skip[5], then cancelled by jmp
        drvh    #33         ' loaded in place of skip[5] by jmp, executed
        drvh    #34         ' skip[6]
        drvh    #35         ' executed (skip no longer active)
        jmp     #\cogx      ' executed
        drvh    #36         ' executed
        drvh    #37         ' executed
        jmp #$
    

    I assume this is only an issue with the fast skip, as I'm guessing that the slow skip doesn't touch the instruction pointer.

    I suggest the following:

    * Allow only slow skips to continue after a jump. This works with both relative and absolute jumps (I assume).
    * For fast skips, cancel if a jump is encountered. In order to do this, instead of modifying the instruction pointer directly, maintain a separate look-ahead counter (LC) that's driven by the skip pattern. The fetched instruction address will be IP+LC, except when it's a branch. In that case, it's just IP and skip is cancelled. When fast skip is not enabled, LC will just be zero.

    Given that, the rules would be:

    SKIP : works with all execution modes and branch addressing modes
    SKIPF : works with COG execution mode, cancelled if branch
    EXECF : JMP first, then enable SKIPF


  • jmgjmg Posts: 10,651
    Seairth wrote: »
    ..

    Given that, the rules would be:

    SKIP : works with all execution modes and branch addressing modes
    SKIPF : works with COG execution mode, cancelled if branch
    EXECF : JMP first, then enable SKIPF
    Chip did mention he had a case where SKIPF over branch was useful, but maybe he only tested that with relative jumps ?
    Guess it comes down to what is simplest - fixing ABS, or patching SKIPF ?

  • jmgjmg Posts: 10,651
    cgracey wrote: »
    Here is what the pipeline sees:
    	skipf	#%01011101
    	drvh	#32		'2 (cancelled)
    	jmp	#cogy		'4 (executed)
    	jmp	#cogx		'4 (executed)
    	drvh	#37		'2 (executed)
    	jmp	#$
    
    This code is a good example of why the # usage needs fixing.
    Notice the long column with all #, making it harder to see labels.

    More conventional/standard assemblers would support this
    	skipf	#%01011101
    	drvh	Pin_32		'2 (cancelled)
    	jmp	cogy		'4 (executed)
    	jmp	cogx		'4 (executed)
    	drvh	Pin_37		'2 (executed)
    	jmp	$
    

  • jmg wrote: »
    Seairth wrote: »
    ..

    Given that, the rules would be:

    SKIP : works with all execution modes and branch addressing modes
    SKIPF : works with COG execution mode, cancelled if branch
    EXECF : JMP first, then enable SKIPF
    Chip did mention he had a case where SKIPF over branch was useful, but maybe he only tested that with relative jumps ?
    Guess it comes down to what is simplest - fixing ABS, or patching SKIPF ?

    But fix it how? By the point that the absolute jump occurs, the crucial skip bits will have been shifted out of the skip mask. The only reason it happens to work for relative jumps is because it doesn't matter (mathematically) whether you skip-then-branch or branch-then-skip. Except, in the case of branch-then-skip, you're back to slow skips.
  • Seairth, you are right! I thought it was working differently, by design. Indeed, the absolute JMPs cause it to fail. I will study more what you wrote. This is kind of a mind-bender.
Sign In or Register to comment.