PASM and SPIN debug with Zero Footprint

Cluso99 · 2008-09-03 03:15

Zero Footprint - eat your heart out Hippy

· (just kidding - great to get groups together for lateral thinking !)

I wouldn't have thought about placing the code in the shadow ram, but for your (Hippy's) code.
See PASM debug with just one long !·· http://forums.parallax.com/showthread.php?p=747204
Also see Debug SPIN and ASM - LMM style· http://forums.parallax.com/showthread.php?p=743062

This is how it works...

The first 3·long of the cog are copied out before loading from hub and replaced with a little bootstrap. When the cog is loaded this bootstrap copies 4 longs into the cog shadow ram at $1F0-1F3 and then jumps to $1F0 to execute.·This executes a micro-LMM kernel in hub ram (4 longs + 1 long for variable space) - this must be located in hub ram at and below $1FF.

Spin code controls the micro-LMM kernel. The spin firstly replaces the first 3 longs in the cog which had held the temporary bootstrap.

Now spin can control and execute any single-stepping, debugging, reading or writing to the cog as desired.

I still believe that the debug code can reside in LMM (rather than a seperate cog running spin). However, that will have to wait for another day.

I use the FullDuplexSerial object modified to FullDuplexSerial2.spin - it has out(txbyte) equivalent to tx(txbyte) and PST. This makes it easier to change to the TV object that Hippy uses.

The spin debug code is only proof of concept and will require further work. Enjoy

@Hippy: Is the copyright message as you want it??? I would rather acknowledge you directly.

Postedit: See the latest post(s) for the latest code release.
·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

Post Edited (Cluso99) : 1/10/2009 8:58:23 AM GMT

hippy · 2008-09-03 04:31

Tee Hee -- The joys of licensing. Though technically my request is not part of the license so could be ignored.

You did exactly what I'd asked but not what I'd intended - "Copyright : 2008, (undisclosed third party) - original code". The intent was to make you change the AiChip filename prefix ( as you did ) and remove any impression derivatives come from AiChip ( as you have ), but I hadn't intended that to stretch to deleting the original author credit

I'll think about re-wording. Thanks for pointing it out.

Cluso99 · 2008-09-03 12:17

Here is an updated version that displays debug information to the serial port. It allows single-stepping and multiple single-stepping using FDX and PST.

@Hippy: How is this copyright message? PM me if you'd·prefer something else.

Postedited - sample of debug output...

Cluso_CogDebug v010
   S = single step   1 instruction
 nnS = single step  nn instructions
   X = exit debugger
adr  conds        op       wc wz nr dst   src  : cz  dst_data  src_data  : new_dst
------------------------------------------------------------------------------------
$000 .  .  .  .   add      .  .  .  $101,#$001 : --  $04820D0A      $001 : $04820D0B
$001 .  .  .  .   add      .  .  .  $102,#$001 : --  $820D0B38      $001 : $820D0B39
$002 .  .  .  .   add      .  .  .  $103,#$001 : --  $0D0C3807      $001 : $0D0C3808
$003 .  .  .  .   rdlong   .  .  .  $008, $007 : --  $00000000 $00000200 : $233764F4
$004 if_c_or_z    movs     wc wz .  $008,#$055 : --  $233764F4      $055 : $233764F4
$005 .  .  .  .   jmpret   .  .  .  $008,#$006 : --  $233764F4      $006 : $23376406
$006 .  .  .  .   jmp      .  .  nr $000,#$000 : --  $80FE0201      $000 : $80FE0201
$000 .  .  .  .   add      .  .  .  $101,#$001 : --  $04820D0B      $001
------------------------------------------------------------------------------------

Enjoy

Post Edited (Cluso99) : 9/4/2008 12:46:14 AM GMT

hippy · 2008-09-03 12:47

That's fine, thanks. You can take out the "AiChip is a trademark" as well if you wish from the author credit.

Cluso99 · 2008-09-03 13:57

@ Hippy: "AiChip is a trademark" - your call - what woud you like?? I'll then update both releases.

Back to my interpreter tomorrow, before the .... hits the fan on Friday !

I have had great fun with this exercise. I have code (untested) which debugs the interpreter (spin) and single-steps the cog using LMM style code in the same cog. It's a little tricky to code but will ultimately save a cog. I think I will lave most of this for another day and oncentrate on what I have.

Did I say, OP_SHR_IWCNR and OP_SHR_IWZNR needed the cond bits set to execute.

I am trying to start the Interpreter only once to run the spin test code. I spent a lot of time before I realised that I had multiple copies running, all debugging with conflicting parameters.

hippy · 2008-09-03 15:11

Take the trademark acknowledgement out.

In using the technique to debug the LCC VM I'm finding I'm not really using it to its full potential. I'm breaking on every bytecode fetch and displaying stack so it's easier to push a value to stack where I'm interested in what's happening, jump to the Fetch loop and look to see what is at TOS.

This way of working is down to not having an easy way to interact with the debugger. To be really usable it needs a 'command shell' wrapper so this looks like a great way forward.

I'd suggest one possible improvement ( saves an extra cog ); rather than use FDX, as you're only transmitting when you've hit a breakpoint ( only the micro-LMM debugger is running ), temporarily replace some code in the cog being debugged with a bit-banged transmit serial byte routine and use that for transmit. As you'll only need to receive characters ("S" etc ) once data has been displayed you can temporarily add a receive routine in the same way. With a bit of clever working you should be able to get the receive doing single byte rx buffering while processing the last and be able to tell it to stop and return to the micro-LMM debugger when you need to continue. Don't forget to save and restore the state of C and Z !

hippy · 2008-09-03 17:02

You don't even need to launch a PASM bit-bang routine if you want serial up to 9600. I've just added the following to my Debug object ...

VAR

  byte  siPin    
  byte  soPin
  long  sxBaudRate    
  long  sxBitTime 
  byte  sxInvert 

PUB StartSerial( argSiPin, argSoPin, argSxBaudRate, argSxInvert )

  siPin      := argSiPin
  soPin      := argSoPin
  sxBaudRate := argSxBaudRate
  sxBitTime  := CLKFREQ / argSxBaudRate
  sxInvert   := argSxInvert

  if sxBaudRate =< 9600
    if ( OUTA[noparse][[/noparse] soPin ] <> 0 ) == sxInvert
      OUTA[noparse][[/noparse] soPin ] := sxInvert
      DIRA[noparse][[/noparse] soPin ] := 1
    else
      OUTA[noparse][[/noparse] soPin ] := sxInvert
      DIRA[noparse][[/noparse] soPin ] := 1
      WaitCnt( CLKFREQ / 1000 * 7 + CNT )
  
PUB Str( strPtr )

  if sxBaudRate
    repeat StrSize(strPtr)
      Out( byte[noparse][[/noparse] strPtr++ ] )

PUB Hex( n, w )

  if sxBaudRate
    n <<= ( 8-w ) << 2
    repeat w
      Out(lookupz( (n <-= 4) & $F : "0".."9", "A".."F"))
  
PUB Bin( n, w )

  if sxBaudRate
    n <<= 32 - w
    repeat w
      Out( ( n <-= 1 ) & 1 + "0")
        
PUB Dec( n ) | i

  if sxBaudRate
    if n < 0
      -n
      Out( "-" )
    i := 1_000_000_000
    repeat 10
      if n => i
        Out( n / i + "0" )
        n //= i
        result~~
      elseif result or i == 1
        Out( "0" )
      i /= 10
      
PUB Out( n ) | i, saved[noparse][[/noparse]9], timeout

  if sxBaudRate
    if sxBaudRate =< 9600
      i := (( (( n & $FF ) ^$FF ) << 2 ) | 2 ) ^ sxInvert
      timeout := CNT
      repeat 11
        waitcnt( timeout += sxBitTime )
        OUTA[noparse][[/noparse] soPin ] := ( i >>= 1 ) & 1
    else
    
      repeat i from $000 to $008
        saved[noparse][[/noparse] i ] := Peek( i )
       
      Poke( $000, 0 )           ' Bit-Banged PASM serial transmit goes here
      Poke( $001, 0 )
      Poke( $002, 0 )
      Poke( $003, 0 )
      Poke( $004, 0 )
      Poke( $005, 0 )
      Poke( $006, 0 )
      Poke( $007, 0 )
      Poke( $008, OP_JMP_IMM | X_DONE )
       
      Execute( OP_JMP_IMM, 0+0, $000 ) 
       
      repeat i from $000 to $008
        Poke( i, saved[noparse][[/noparse] i ] )

   if n == $0D
     Out( $0A )

Cluso99 · 2008-09-04 01:19

@Hippy: All code resaved with the updated copyright (TM removed) i.e. v008 & v010. Thanks for your input - I thought you would want recognition but your terms were so precise. I hate all this legal stuff, but I don't want to get trapped either.

I didn't want to change the FDX object as it is fairly simple to put your TV object back in (or probably VGA for that matter). It keep flexibility for others. However, I am sure I can do this inside the cog being debugged by using LMM later. I have written a fair bit of the routine but not the decoding (which you and· have done in spin).

Spin Debugger

You have found the same as me, you need to look at the stacks after an instruction executes. That is my task at the moment so that I can verify the Interpreter. I am going to use the new zero footprint version and add my debuging from my LMM code.

I am a little stumped on launching just 1 version of the Interpreter running the spin test code, without is replacing all versions of the Interpreter. Need to sit back and think a bit more.

Debugger (Spin & PASM)

Command structure... I was thinking something like...

On launch, asking if "S"pin or "A"sm. Then the debugger nows what format to use.

nnnT = Trace nnn instructions/bytecodes (nnn defaults to 1)
nnnS = Skip·· nnn instructions/bytecodes (nnn defaults to 1)· i.e. no display

BxxxxxxxxT = Run until breakpoint with Trace (xxxx hex = cog·address for instructions / hub address for bytecodes)
BxxxxxxxxS = Run until breakpoint with·Skip· ·(xxxx hex = cog address for instructions / hub address for bytecodes)

Dxxx,nnC······ ·= displays cog data at address xxx,······· nn longs (xxx hex, nn decimal)
Dxxxxxxxx,nnH = displays hub data at address xxxxxxxx, nn longs (xxx hex, nn decimal)

Mxxx,yyyyyyyyC······· = modifies cog data at address xxx······· to yyyyyyyy· ·(xxx and yyyyyyyy·hex)
Mxxxxxxxx,yyyyyyyyH = modifies hub data at address xxxxxxxx to yyyyyyyy· ·(xxx and yyyyyyyy·hex)

Any thoughts anybody ??

Cluso99 · 2008-09-08 09:06

Attached is ClusoDebugger v0.250
It uses Zero Footprint in the PASM code. Here are the commands and output sample. I believe it all works, so please report any bugs.

ClusoDebugger v0.250
     S = Skip   1 instruction {no trace}    c = Clear C
   nnS = Skip  nn instructions              C = Set   C
     T = Trace  1 instruction (or Enter)    z = Clear Z
   nnT = Trace nn instructions              Z = Set   Z
 BxxxS = Skip  until Break $xxx address
 BxxxT = Trace until Break $xxx address     X = exit debugger
 
adr  conds        op       wc wz nr dst   src  : cz  dst_data  src_data  : new_dst
------------------------------------------------------------------------------------
$000 .  .  .  .   add      .  .  .  $011,#$001 : --  $00000100      $001 : $00000101   <-- means dest changed
$001 .  .  .  .   add      .  .  .  $011,#$002 : --  $00000101      $002 : $00000103
$002 .  .  .  .   add      .  .  .  $011,#$003 : --  $00000103      $003 : $00000106
$003 .  .  .  .   and      wc .  nr $003,#$001 : --  $617C0601      $001 :             <-- means dest unchanged
$004 if_z         add      .  .  .  $011,#$010 : C-  $00000106      $010 :
$005 if_c         add      .  .  .  $011,#$020 : C-  $00000106      $020 : $00000126
$006 .  .  .  .   and      .  wz nr $006,#$000 : C-  $627C0C00      $000 :
$007 .  .  .  .   and      .  wz nr $007,#$001 : CZ  $627C0E01      $001 :
$008 .  .  .  .   and      wc .  nr $008,#$000 : C-  $617C1000      $000 :
$009 .  .  .  .   and      wc .  nr $009,#$001 : --  $617C1201      $001 :
$00A .  .  .  .   jmp      .  .  nr $000,#$012 : C-  $80FC2201      $012 :
$012 .  .  .  .   mov      .  .  .  $01B, $01C : C-  $00000000 $00000008 : $00000008
$013 .  .  .  .   mov      .  .  .  $1F6, $01A : C-  $00000000 $04000000 : $04000000
$014 .  .  .  .   xor      .  .  .  $1F4, $01A : C-  $00000000 $04000000 : $04000000
$015 .  .  .  .   djnz     .  .  .  $01B,#$015 : C-  $00000008      $015 : $00000007
$015 .  .  .  .   djnz     .  .  .  $01B,#$015 : C-  $00000007      $015 : $00000006
$015 .  .  .  .   djnz     .  .  .  $01B,#$015 : C-  $00000006      $015 : $00000005
$015 .  .  .  .   djnz     .  .  .  $01B,#$015 : C-  $00000005      $015 : $00000004
$015 .  .  .  .   djnz     .  .  .  $01B,#$015 : C-  $00000004      $015 : $00000003
$015 .  .  .  .   djnz     .  .  .  $01B,#$015 : C-  $00000003      $015 : $00000002
$015 .  .  .  .   djnz     .  .  .  $01B,#$015 : C-  $00000002      $015 : $00000001
$015 .  .  .  .   djnz     .  .  .  $01B,#$015 : C-  $00000001      $015 : $00000000
$016 -nop- .  .   nop      .  .  nr $000, $000 : C-  $80FC2201 $80FC2201 :
$017 .  .  .  .   mov      .  .  .  $01B, $01C : C-  $00000000 $00000008 : $00000008
$018 .  .  .  .   jmp      .  .  nr $000,#$014 : C-  $80FC2201      $014 :
$014 .  .  .  .   xor      .  .  .  $1F4, $01A : C-  $04000000 $04000000
------------------------------------------------------------------------------------

Just place your PASM code at the end of the file and use PST to communicate with the debugger. The debugger waits for PST to send a character (while outputting a message). Then the screen is cleared and the command set is displayed.

Special thanks to Hippy for all his original work, especially the idea to use the cog shadow ram

Now to add spin debugging to debug my Faster Ram Interpreter.

Enjoy

PS If you want to use the TV object for display, just add·a routine·"tv.tx" to the tv object, add the tv pin, and it·should work -·you will need to cater for the keyboard though.

Update:
I've been thinking about the command structure. Any suggestions would be appreciated (no promises).
These are things to I'd like to implement:
Hub memory dump
Cog memory dump
Modify cog memory
Modify hub memory
Jump cog address (changes execution)
Restart cog
Spin debugging (already working, just need to shoehorn it in here, and add some features)

Maybe 'Enter' should repeat the last command.
Maybe the following format XxxxxZ and nnnnZ where X indicates xxxx is a hex address; nnnn is a decimal number; Z is the command which cannot be A..F (hex numbering), X (prefix for hex) ??? Note this conflicts with my current implementation but that's not a problem yet.

Post Edited (Cluso99) : 9/8/2008 2:46:54 PM GMT

jazzed · 2008-09-08 14:16

Break line, Delete break on line, Run or Run to break, Single step, Step over call, Continue to break, etc....
Yes, return only repeating last command is nice for command line. Of course you will need a GUI some day.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Cluso99 · 2008-09-08 14:40

@Jazzed: The debugger does not reference the source so there are no line numbers (if that is what you mean). There is a single break which means that the code will run till that address is reached, either Tracing or Skipping (Skipping is misnamed because it just means without display which is faster). Single step and with a count (e.g. 1000T will trace 1000 instructions and stop while 1000S will skip (no display) 1000 instructions and stop.

Since PASM code is self-modifiable, the only way to have multiple breaks is by checking as each instruction is executed which is doable. Stepover doesn' have the same meaning in PASM (especially without source access) but it would be possible to run until a jmp/tj../dj.. is executed (presume not taken).

It doesn't faithfully reproduce the feature Hippy mentioned whereby he modifies the next instruction knowing it will have been fetched before it gets written.

I am not intending to do a GUI. I'll leave that for someone else. Currently you can use any serial program (as long as it doesn't reset the Prop by DTR). It is also simple to modify the code to use TV or VGA output - not sure about the keyboard drivers, but should be fairly easy. One step closer to standalone operation

jazzed · 2008-09-08 15:06

GUI is not necessary, but Ariba's PASD is a fair user experience to emulate for PASM (too many longs for the debugger of course and other style annoyances).

Break line really means break address for PASM. Not sure a spin debugger would be very usable without line info although one could reverse engineer the bytecode to determine the source line in run-time. BradC had a nice listing showing some spin source lines content.

I forgot the "Until" command which would step until the current address is passed ... good for loops [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Cluso99 · 2008-09-09 06:17

v0.251: Oops! Jmpret/Call bug fixed.

I now have it·tracing the spin interpreter

See What are your cogs doing ? http://forums.parallax.com/showthread.php?p=749977

Cluso99 · 2008-09-09 14:16

v0.252 Another jmp/jmpret/tj../dj.. bugfix (indirect src >$1FF)

Ale · 2008-09-09 14:28

One thing I always hated about most debuggers: No one key commands. So single step should be only one key, do not wait for enter. You have this huge loop and you wait for the variable to be 500 (starting at 0), so you have to press S and the Enter... no thanks, S should be enough... (Breakpoints to values in memory are very useful...)

I did not use it though, I have no love for the serial interface (

), so I use my simulator. But all these tools may become handy some unexpected day !

Cluso99 · 2008-09-09 14:40

@Ale: You only have to press 'Enter' or 'T' or 'S', etc. Lower & uppercase equivalent except when presetting Z or C. If you want to trace 1000 instructions then type '1000t', without display '1000s'.

Here is the output of the Spin section of the debugger (still being tested and refined). You can turn the Pasm and the Spin on/off seperately, so the trace can be mixed. The RamInterpreter is required.

ClusoDebugger v0.260x
     S = Skip   1 instruction {no trace}    c = Clear C
   nnS = Skip  nn instructions              C = Set   C
     T = Trace  1 instruction (or Enter)    z = Clear Z
   nnT = Trace nn instructions              Z = Set   Z
 BxxxS = Skip  until Break $xxx address
 BxxxT = Trace until Break $xxx address     X = exit debugger
adr  conds        op       wc wz nr dst   src  : cz  dst_data  src_data  : new_dst
------------------------------------------------------------------------------------
$000 .  .  .  .   mov      .  .  .  $000,#$005 : --  $A0FC0005      $005 : $00000005
$001 .  .  .  .   mov      .  .  .  $001, $1F0 : --  $A0BC03F0 $08FFE4BC : $00002E14
$002 .  .  .  .   add      .  .  .  $001,#$002 : --  $00002E14      $002 : $00002E16
Cog 7, Par 2E14: 0010 2CE0 2E10 03E6 2E14
spin: pc(03E6) 36 38 1A 3D sp(2E14) 0000 0000 <0000> 0000 0010
spin: pc(03E7) 38 1A 3D B6 sp(2E18) 0000 0000 <2CE0> 2CE0 2E10
spin: pc(03E9) 3D B6 35 38 sp(2E1C) 0000 0000 <03E6> 03E6 2E14
spin: pc(03EB) 35 38 1A 3D sp(2E14) 0000 0000 <0001> 0001 0000
spin: pc(03EC) 38 1A 3D B4 sp(2E18) 0000 0000 <001A> 001A 0000
spin: pc(03EE) 3D B4 3F 91 sp(2E1C) 0000 0000 <03E6> 03E6 2E14
spin: pc(03F0) 3F 91 C5 81 sp(2E14) 0000 0000 <0000> 0000 0000

jazzed · 2008-09-09 14:47

Ale said...
One thing I always hated about most debuggers: No one key commands. So single step should be only one key, do not wait for enter. You have this huge loop and you wait for the variable to be 500 (starting at 0), so you have to press S and the Enter... no thanks, S should be enough... (Breakpoints to values in memory are very useful...)

Well at least in gdb "enter" repeats the last command

Convenience is just another reason to have a GUI. All IDE: MSVC++, Eclipse, Visual·*blah* have step buttons... All GUI except Ariba's PASD that is·

·.· Most IDE GUIs take your frustration one-click-step-away.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Ale · 2008-09-09 15:29

gdb was done by programmer for programmers, not by marketeers for I-do-not-know -nothing-about-the-white-box people

. (I use F7)

Ariba · 2008-09-09 17:11

jazzed said...
GUI is not necessary, but Ariba's PASD is a fair user experience to emulate for PASM (too many longs for the debugger of course and other style annoyances)...

What kind of "style annoyances" do you mean?
One seams to be: No Toolbar with Step buttons. - This can be added very easy! I've not done it, because I always use Shortkeys for single stepping, also in VB, VisualC ....

The 12 longs for the Debugger kernel was never a problem in my Assembly codes, I never filled a cog to its limits.
To debugging a complicate LMM kernel or a Spin kernel, PASD is shurely not the right tool.

If mpark add a listing output, and perhaps some debug support to his 'Homespun Spin compiler" much better debuggers will be possible in the future!

Andy

Cluso99 · 2008-09-10 02:22

@Ariba:
I originally tried your PASD on the RamInterpreter. I made room for the 12 longs, but that didn't help because I didn't have control for the fact I had multiple cogs running the same code.
In the end I wrote my own, which just used the PST, and used a LMM model to spit out the debugged code (spin bytecode tracing). I did this in 6 longs and could be anywhere in the cog. Then I expanded it to use 8 longs for PASM debugging and Hippy took up the challenge to reduce it. He put it in the shadow ram and ended up using 1 long but it had to be $1EF which caused problems with the Interpreter. I found a way to make it all fit in 4 longs in the shadow ram $1F0-1F3.

I wasn't interested in writing the GUI, so I just used PST. (I did a lot of VB4-6 work in the 90's but really haven't done much in the last 6 years).

If you want, I am sure you could merge your code and mine (and Hippy's) for zero footprint. Mpark is doing a lot of work with his compiler and Hippy with PropList. Hopefully we can make these function together for a combined set of tools.

I have it debugging spin as well (on the fly you can flip in/out of pasm) so you can see what·the bytecode really does. I need this for·debugging my RamInterpreter.

The command structure is still evolving.

PS. Unfortunately, my time comes in bursts, which means I have to·go back to where I left off and remember what I have done/tested and what I have not. I modified the RamInterpreter heavily (without hardware to test) and now it doesn't work I am looking for a needle in a haystack. My debugger is helping with that.

Post Edited (Cluso99) : 9/10/2008 2:28:30 AM GMT

Cluso99 · 2008-09-20 16:49

Attached is Release v0.270S·of the zero footprint Cluso Spin Debugger. It uses PST or Praxis's PropViewer to monitor and control the debugger via the serial port.

There are 3 files in the example.

ClusoDebuggerDemoSpin3.spin is the top object and requires the code at the beginning to be present and unmodified. This is also where the user's spin·code to be debugged goes.

ClusoDebuggerSpin3.spin is the next object and is a self contained file which is called by the top object to launch and configure the debugger.

ClusoDebugger.spin is the actual debugger which is called and will launch itself in a separate cog. This·object·is used for both pasm and spin debugging.

ClusoDebuggerSpin.spin and subsequently ClusoDebugger.spin launch the FullDuplexSerial object in a separate cog. Only one FDX object is present at a time.

Currently there is an issue with the PAR register values being returned, giving what I think is an incorrect usage of the stack. This requires further investigation.

User debugging will need to be done in conjunction with the spin source code. PropList and PropView provide·extra·information of user source code. When the homespun compiler has a listing available, this will be a great aid also. The debugger does not provide a bytecode translation.

"P" toggles pasm output on and off. This means that you can actually see the Interpreter executing the bytecode interpretation.·"O"·toggles spin output on and off. "T" traces and "S" traces (without display) nnnn instructions. The enter key is equivalent to "T". Upper and lower case·are interchangable, except for c and z which can be used to force condition code changes in pasm. No hub instructions (coginit, locknew, etc have been tested. There is a summary of most keys in the display. (I am not happy with the key assignments, so this may change is later releases)

Enjoy (and please report any bugs)

Update:

See the posts below for updated version v0.275. Note the new version is incompatable with that posted here, so I have removed these attachments.

Included in the posts below is an alternative method to trace spin code using·the RamInterpreter instead of the Rom version.

Post Edited (Cluso99) : 9/23/2008 2:39:02 AM GMT

Cluso99 · 2008-09-20 17:24

For anyone that is interested, I have attached Chip's Interpreter with a compiler style listing. It goes well with·my spin debugger if you·are interested·to see what is happening in pasm to the bytecode (just turn pasm on with the "p" key).·

Cluso99 · 2008-09-22 13:58

Release v0.275 for both PASM and SPIN. A common debug object is used for both PASM & SPIN.

There are 3 modes of debugging:

-1: PASM
-2: SPIN (uses RamInterpreter) Limited to tracing cog 7; sqrt function is disabled.
-3: SPIN (interrupts existing RomInterpreter) - [noparse][[/noparse]See next post for code v0.275 - See previous post·v0.270S for more information]

Commands: 
nnnnT     Trace nnnn instructions {enter is equiv to T}
nnnnS     Trace nnnn instructions (without display)
BxxxT     Break at xxx instruction (currently pasm only?)
BxxxS     (without display)
Bxxx>     display cog address xxx (hex)
BxxxxH    display hub address xxxx (hex)
BxxxJ     changes pc counter in cog (jump to address)
R         Reboots cog
X         Exits debugger (better to Reboot
C c       Set/reset C flag
Z z       Set/reset Z flag
<esc>     will interrupt display
O o       toggles spin code trace on/off
P p       toggles pasm code trace on/off

Sample output of spin trace (including partial pasm trace of Interpreter)...

ClusoDebugger v0.275
 
     S = Skip   1 instruction {no trace}    c/C = Clear/Set C
   nnS = Skip  nn instructions              z/Z = Clear/Set Z
     T = Trace  1 instruction (or Enter)
   nnT = Trace nn instructions
 BxxxS = Skip  until Break $xxx address     R = Reboot
 BxxxT = Trace until Break $xxx address     X = exit debugger
 
Cog 7, Par 28C4: 0000 pb0010 vb28B8 db28C0 pc00ED sp28C8
adr  conds        op       wc wz nr dst   src  : cz  dst_data  src_data  : new_dst
------------------------------------------------------------------------------------
spin: pc(00ED) 3B 77 77 77 77  sp+00(28C8) -------- -------- -------- --------       (1,29)
spin: pc(00F2) 61 38 37 65 66  sp+01(28CC) 77777777 -------- -------- --------       (2,73)
$009 .  .  .  .   rdbyte   .  .  .  $005, $1EE : --  $00000000 $000000F2 : $00000061 (2,74)
$00A .  .  .  .   add      .  .  .  $1EE,#$001 : --  $000000F2      $001 : $000000F3 (2,75)
$00B .  .  .  .   sub      wc .  nr $005,#$040 : --  $00000061      $040 :           (2,76)
$00C if_nc        jmp      .  .  nr $000,#$0F9 : --  $00000000      $0F9 :           (2,77)
$0F9 .  .  .  .   sub      wc .  nr $005,#$080 : --  $00000061      $080 :           (2,78)
$0FA if_c         jmp      .  .  nr $000,#$15D : C-  $00000000      $15D :           (2,79)
$15D .  .  .  .   mov      .  .  .  $001,#$002 : C-  $000028CE      $002 : $00000002 (2,80)
$15E .  .  .  .   mov      .  .  .  $007, $005 : C-  $0CFFD201 $00000061 : $00000061 (2,81)
$15F .  .  .  .   and      .  .  .  $007,#$01C : C-  $00000061      $01C : $00000000 (2,82)
$160 .  .  .  .   and      .  wz nr $005,#$020 : C-  $00000061      $020 :           (2,83)
$161 .  .  .  .   jmp      .  .  nr $000,#$172 : C-  $00000000      $172 :           (2,84)
$172 if_c_and_z   add      .  .  .  $007, $1EC : C-  $00000000 $000028B8 :           (2,85)
$173 if_c_and_nz  add      .  .  .  $007, $1ED : C-  $00000000 $000028C0 : $000028C0 (2,86)
$174 .  .  .  .   shl      .  .  .  $001,#$003 : C-  $00000002      $003 : $00000010 (2,87)
$175 .  .  .  .   movi     .  .  .  $1B8, $001 : C-  $08280007 $00000010 :           (2,88)
$176 .  .  .  .   or       .  .  .  $001,#$001 : C-  $00000010      $001 : $00000011 (2,89)
$177 .  .  .  .   movi     .  .  .  $1C6, $001 : C-  $08A80007 $00000011 :           (2,90)
$178 .  .  .  .   and      .  .  .  $005,#$003 : C-  $00000061      $003 : $00000001 (2,91)
$179 .  .  .  .   jmpret   .  .  .  $019,#$017 : C-  $5C7C00DA      $017 : $5C7C017A (2,92)
$017 .  .  .  .   and      .  wz nr $005,#$001 : C-  $00000001      $001 :           (2,93)
$018 .  .  .  .   and      wc .  nr $005,#$002 : C-  $00000001      $002 :           (2,94)
$019 .  .  .  .   jmp      .  .  nr $000,#$17A : --  $00000000      $17A :           (2,95)
$17A if_nc_and_z  jmp      .  .  nr $000,#$1C5 : --  $00000000      $1C5 :           (2,96)
$17B if_nc_and_nz jmpret   .  .  .  $1DE,#$1DC : --  $5C7C0000      $1DC : $5C7C017C (2,97)
$1DC .  .  .  .   sub      .  .  .  $1EF,#$004 : --  $000028CC      $004 : $000028C8 (2,98)
$1DD .  .  .  .   rdlong   .  .  .  $000, $1EF : --  $00000000 $000028C8 : $77777777 (2,99)
$1DE .  .  .  .   jmp      .  .  nr $000,#$17C : --  $77777777      $17C :           (2,100)
$17C if_nc_and_nz jmp      .  .  nr $000,#$1B7 : --  $77777777      $1B7 :           (2,101)
$1B7 .  .  .  .   and      wc wz nr $005,#$00C : --  $00000001      $00C :           (2,102)
$1B8 if_z         wrlong   .  .  nr $000, $007 : -Z  $77777777 $000028C0 :           (2,103)
$1B9 if_z         jmp      .  .  nr $000,#$008 : -Z  $77777777      $008 :           (3,104)
spin: pc(00F3) 38 37 65 66 2E  sp+00(28C8) -------- -------- -------- --------       (3,105)
$008 .  .  .  .   mov      .  .  .  $000,#$000 : -Z  $77777777      $000 : $00000000 (3,105)
$009 .  .  .  .   rdbyte   .  .  .  $005, $1EE : -Z  $00000001 $000000F3 : $00000038 (3,106)
$00A .  .  .  .   add      .  .  .  $1EE,#$001 : -Z  $000000F3      $001
------------------------------------------------------------------------------------

I noted while doing a trace of coginit bytecodes, that in preparing for the call, spin code executes from hub ROM $FFFC, then lower FF70-FFF4 code. This code presets the parameters on the stack (pbase, vbase, dbase, pcurr, dcurr). It seems like it is the 'Runner Code' that Chip spoke about - I thought it was a bug.

Post Edited (Cluso99) : 9/23/2008 2:44:37 AM GMT

Cluso99 · 2008-09-22 15:52

Release v0.275 for·SPIN (mode -3: interrupts the Rom Interpreter).

See my post 9/21/2008 2:49 AM (GMT +10) for more information on this mode of operation.

Uses the·common debug object·used for both PASM & SPIN (see previous post for ClusoDebugger_275.spin)

WARNING: Mode -3 uses a differently configured Debug_Block to modes -1 and -2.

Post Edited (Cluso99) : 9/23/2008 2:50:31 AM GMT

Cluso99 · 2008-11-06 14:43

Attached below is the screen output (working) for the windows version of the ClusoDebugger (Spin version). I will release it when ready.

I use the listing output from the Homespun compiler.

Spin debugging will be singlestep or by breakpoints. The debugger can break down the spin debugging into pasm debugging when desired.

dMajo · 2008-11-06 16:19

Hi Cluso99,

I see your debugger as a great plug-in for Praxis Developer Studio (both of you use the same compiler: wonderful).

Do you think it's possible ?

Cheers

Cluso99 · 2008-11-07 06:44

Yes, we've been talking offline for quite a while.

When I've finished I will just need to make it a dll.

Cluso99 · 2009-01-10 07:43

SPIN DEBUGGER
There is some confusion about how my debuggers work, so here goes - let me know if there is something you do not understand.
Attached is the latest debugger for spin (all files required are included).

ClusoDebuggerDemoSpin_275.spin
This is the Top Level file. It contains YOUR spin code to be traced/debugged - just replace the section "PUB TestSpin" with your code.
Your code is loaded by the CogInit instruction a few lines above.

  CogInit( 7, TestSpin , @priStack )                            '<---- YOUR spin code to be debugged

Your code is in a PUB called "TestSpin", uses a stack called "priStack" and has been defined as $40 in length. If you need more, change it.

Note: Your code MUST run in Cog 7 because the RamInterpreter has been modified to only use Cog 7.

ClusoDebugger_276.spin
This is my debugger (written in spin). It uses FullDuplexSerial.spin to communicate with PST (Parallax Serial Terminal) using the serial downloader on pins 30 & 31 at 115,200 baud. It is the same code as used in my·Pasm debugger.

FullDuplexSerial.spin
Used by the ClusoDebugger described above.

RamInterpreter1_275.spin and RamInterpreter2_275.spin
These are Ram versions of Chip's Interpreter with minor modifications to force the RamInterpreter2 to be loaded if Cog 7, else load the RamInterpreter1. The SQRT function has been disabled in both versions·(for space to perform the RamInterpreter load section). The two versions have a minor difference to force the compiler to think they are different. Otherwise the compiler will optimise (removing one copy).

Operating Instructions
1. Compile and load "ClusoDebuggerDemoSpin_275.spin" (set as Top Object) using PropTool
2. Run PST (check it uses the same port as PropTool and is set to 115,200 baud)
3. You should see the (repeating) message "ClusoDebugger: Press Enter to start."
4. Press "Enter" (or any key) to start
5. You should now see the Instructions displayed on the PST screen.

ClusoDebugger v0.276                                   
     S = Skip   1 instruction {no trace}    c/C = Clear/Set C     
   nnS = Skip  nn instructions              z/Z = Clear/Set Z     
     T = Trace  1 instruction (or Enter)    O = Toggle Spin debug 
   nnT = Trace nn instructions              P = Toggle Pasm debug 
 BxxxS = Skip  until Break $xxx address                           
 BxxxT = Trace until Break $xxx address                           
 Bxxx> = Show COG memory                    R = Reboot            
 BxxxH = Show HUB memory                    X = exit debugger

(I don't recall BxxxS and BxxxT working·- I haven't unpacked my Prop since returning from holidays to test it.)

These commands should be fairly self-explanatory. If you wish to see the Pasm instructions being executed by the RamInterpreter for each spin bytecode, type "P" to toggle the pasm debug on and off. A counter displays the instruction numbers being executed, so you can see how many pasm instructions have been executed for each spin bytecode executed.

Note:
If you compile using the Homespun compiler, you will see the spin bytecodes in the listing. These will equate to the spin instructions executed in the ClusoDebugger.

I have a crude VB program which works with the debugger and the homespun listing to highlight the spin bytecodes as they are executed. If anyone is interested in programming·the VB code, please PM me. I don't mind doing any changes in the debugger required, but currently I don't have the time to do the VB.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

Post Edited (Cluso99) : 1/10/2009 8:51:12 AM GMT

Cluso99 · 2009-01-10 08:38

PASM·DEBUGGER
There is some confusion about how my debuggers work, so here goes - let me know if there is something you do not understand.
Attached is the latest debugger for·PASM (all files required are included).

ClusoDebuggerDemoPasm_275.spin
This is the Top Level file. It contains YOUR·Pasm code to be traced/debugged - just replace the DAT section "PasmCode" with your code.
Your code is loaded by the CogNew instruction a few lines above.

    CogNew( @PasmCode, 0 )                                      '<---- YOUR PASM code to be debugged

ClusoDebugger_276.spin
This is my debugger (written in spin). It uses FullDuplexSerial.spin to communicate with PST (Parallax Serial Terminal) using the serial downloader on pins 30 & 31 at 115,200 baud. It is the same code as used in my Spin debugger.

FullDuplexSerial.spin
Used by the ClusoDebugger described above.

Operating Instructions
1. Compile and load "ClusoDebuggerDemoPasm_275.spin" (set as Top Object) using PropTool
2. Run PST (check it uses the same port as PropTool and is set to 115,200 baud)
3. You should see the (repeating) message "ClusoDebugger: Press Enter to start."
4. Press "Enter" (or any key) to start
5. You should now see the Instructions displayed on the PST screen.

ClusoDebugger v0.276                                   
     S = Skip   1 instruction {no trace}    c/C = Clear/Set C     
   nnS = Skip  nn instructions              z/Z = Clear/Set Z     
     T = Trace  1 instruction (or Enter)    O = Toggle Spin debug 
   nnT = Trace nn instructions              P = Toggle Pasm debug 
 BxxxS = Skip  until Break $xxx address                           
 BxxxT = Trace until Break $xxx address                           
 Bxxx> = Show COG memory                    R = Reboot            
 BxxxH = Show HUB memory                    X = exit debugger

(I don't recall BxxxS and BxxxT working·- I haven't unpacked my Prop since returning from holidays to test it.)

These commands should be fairly self-explanatory.·A counter displays the instruction numbers being executed.

Note:
If you compile using the Homespun compiler, you will see the·instructions in the listing. These will equate to the Pasm instructions executed in the ClusoDebugger.

I have a crude VB program which works with the debugger and the homespun listing to highlight the Pasm instructions as they are executed. If anyone is interested in programming·the VB code, please PM me. I don't mind doing any changes in the debugger required, but currently I don't have the time to do the VB.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

jazzed · 2009-01-10 17:10

Hi Cluso99. Good work [noparse]:)[/noparse]

I can see pasm listings which is great. Wasn't there a program that could associate the byte-codes with spin source from BradC (or someone)? Maybe I just dreamed seeing that, but I remember Hippy being impressed.
Ok, got it now using brad's bstc:

1. compile binary and source list C:\somedir\bstc -sl -b ClusoDebuggerDemoSpin_275
 
2. cleanup list to make less verbose (requires utils like in cygwin stuff)
c:\somedir\cat ClusoDebuggerDemoSpin_275.list | grep -v Addr | grep -v "|==" | grep -v " | " | sed "s/Spin Block .*//g" > debug.lst
 
3. Load and Connect to Propeller
4. trace or step, etc...

From here it would be quite easy to create a spin-step debugger GUI thanks to your and BradC's excellent work.
So break-points are broken?

Thanks a bunch.

BTW was the first hard disk drive bigger than a washing machine? I remember having to carry ~15" disk packs around for CDCs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Post Edited (jazzed) : 1/10/2009 6:39:40 PM GMT

Cluso99 · 2009-01-11 04:21

@jazzed (Steve):

Great work with the steps to produce a listing with BradC's bstc. As I said, I started a VB program to step through the listing with the debugger. It works for both Pasm and Spin (VB6 and VB2008) but I haven't found a nice way of displaying the listing for stepping. In VB6 I used the TextBox and could highlight the line as it stepped. Similarly in VB2008 I used another control (can't remember as this is the only code I have done on VB2008). However, it requires a control (maybe a grid) so that you can click to show a breakpoint (like VB). When the code hits a breakpoint the VB would recognise this and stop the debugger (the debugger would always be in single-step mode and the VB would just be saying proceed to the next instruction).

Homespun's listing was good for the spin code trace. I haven't looked at Brad's listing lately. Would you like to post the listing of ClusoDebuggerDemoSpin_275 ?

OT: The drives of the 70's were typically 19" platters. A 10MB was 6 high, 10 heads and 11 high, 20 heads were 40MB. In 1976 a 10MB drive cost A$16,000. The drives were about the size of a typical washing machine. They required the heads to realigned by engineers at least every 3 months. I used to teach engineers to take a machine (disc drive) to pieces and build it back up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439

My cruising website http://www.bluemagic.biz

PASM and SPIN debug with Zero Footprint

Comments