Considering writing a Prop Assembly debugger with breakpoints/single step. Has

epmoyer

I've been mulling it over and it seems very doable to create a mini-debugger for the prop that would allow a small bit of code (20-30 longs, added to an assembly module running in a cog) to support single step/breakpoints/debugging/disassembly of assembly code running in that cog. The debug "monitor" would communicate via shared memory with a serial communications engine running in another cog, and a Windows app would do all the real leg work of displaying the data.

Has anyone done this already for the Prop? I thought I had seen one go by but now I can find it. Perhaps I just remember reading about GEAR (which is a simulator, not a debugger). I didn't want to re-invent the wheel if it had already been done. I searched the forums and object exchange and couldn't find anything similar.

Thanks

nutson

There have been early attempts http://forums.parallax.com/forums/default.aspx?f=25&m=151863

Paul Baker

This is the other major attempt at it: http://forums.parallax.com/showthread.php?p=639020

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Harley

epmoyer,

Might this site refer to what you saw?

I'm presently running the single-cog (actually requires one more) 20 MHz sampling version of it to debug some assembly code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn

deSilva

A good debugger will need extra information from an assembler (at least address maps) . Thus the first step has to be to get a good assembler.

Without hardware support breakpoints have to be implemented by substituting instructions. This is a hard thing when having self modifying code

Good Luck!!

epmoyer

Ah! POD was the one I was trying to remember. Thanks for the link Paul! I don't know why I couldn't find it when I searched.

deSilva - Yes, you're right. Self modifying code would break an instruction-substitution breakpoint scheme. Without dedicated hardware debug hooks in the prop there's not much choice though [noparse];)[/noparse]

I haven't tried POD before. I'll give it a shot; at a glance it appears to do what I'm looking for.

Thanks everyone for the help.

Paul Baker

You're welcome, Graham Stabler's index thread is a good first place to check for that sort of thing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Mike Green

I had played with the idea of a single stepper/debugger, but never took it to the "useful" stage with a proper user interface. It's very doable. You copy each instruction to a fixed location in the debugger. You have to partially interpret the jump class instructions, basically substitute an address within the debugger for the source. You have to restore Z and C before executing the instruction and save them afterwards. If the instruction falls through, you use the incremented PC. If the instruction jumps to the internal debugger location, you use the original instruction's source to load the PC. JMPRET has to be interpreted so that the emulated PC can be used. That's pretty much it. Self-modifying code simply modifies the original instruction. It's not legal to modify the current instruction using itself because of the pre-fetch.

Paul Baker

Yeah for a while I was toying with doing a virtual cog debugger where 512 longs of memory would represent a 9th cog, bits of code would be loaded into a real cog with the source and destination of the instruction loaded into container registers with the instruction remapped to the container locations. Breakpoints were to be NOPs with the source field set to non-zero. Not having a direct means of setting the flags presents a hump, but it's not insurmountable.· But I've been too busy to pursue it's development.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Graham Stabler

Your posts really sum up the only real problem with the propeller, "so many possibilites, so little time"

deSilva

Mike,

MG said...
Self-modifying code simply modifies the original instruction.

But there is one pitfall: When illegally modifying the "next" instruction, it would work with the debugger, but not without

MG said...
It's not legal to modify the current instruction using itself because of the pre-fetch.

This is quite legal, and has no bad consequences at all

How large would that debugger become?

As you have to handle each instruction, even (and especially!) in "breakpoint" mode, there is no chance for real-time behaviour!

Ariba

Hi all

I've done such a debugger some month ago. It works exactly as epmoyer has described.
But I have no english documentation and I have not the time to make one (this is hard work for me).
So if someone is willing to translate a german site and add a little description of the menu and handling, and makes some demo-code, then I will send him the files and post it later in this forum.

The german version you can find here: www.insonix.ch/propeller/prop_pasd.html.
(the automatic translation by google is not totaly incomprehensible)

Some features:
- Allows realtime debugging on sourcecode level with labels !
- it needs a 12 longs wide debug kernel at the beginning of the code,
- a parallel running cog for communication with the PC,
- 2 shared longs at the end of the HubRAM for cog interaction.
- COM switching like PropTerminal.

Andy

epmoyer

Holy smokes Andy, it looks like you wrote PreSpin too, which is essentially the same as my ScUMM utiltity ( http://forums.parallax.com/showthread.php?p=654555 )!!!! We must think alike, because I was apparently about to do it again with the debugger

I really like your debugger at first glance. I will give it a try later tonight when I get home.

Kaio

Mike,

POD is able to do single step debugging you was thinking. And of course it has an UI. Did you have never tried POD?

Thomas

Ale

If what you want to debug is only assembler algorithms (that do not depend on external sources), you may try my assembler/debugger pPropellerSim at sourceforge.net/projects/ppropellersim, it has integrated editor and assembler (with symbol support). It has some caveats though.

deSilva

It seems there is a wealth of tools and programs out there ....

@Ale: Can you give us same hints, as how to install your program?

Post Edited (deSilva) : 8/17/2007 2:01:19 PM GMT

Leon

Download it, unzip it, and save the pPropellerSim folder somewhere. Just execute pPropellerSim.jar, in the pPropellerSim dist directory. You need to have Java on your system, of course. Or, run it from the command line, as described in README.TXT in the same directory.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Leon

Ale said...
If what you want to debug is only assembler algorithms (that do not depend on external sources), you may try my assembler/debugger pPropellerSim at sourceforge.net/projects/ppropellersim, it has integrated editor and assembler (with symbol support). It has some caveats though.

I can't get the assembler to work, it always gives up on the first line, whatever instruction I try. Does it use different nmemonics from the Propeller assembler?

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Ale

deSilva:

sure,

get the latest version out of sourceforge , as of writing, 0.6

Unix instructions below (you downloaded it under /home/pacito/download) :

pacito@Maulotaur $ pwd
/home/pacito

pacito@Maulotaur $ mkdir usr
pacito@Maulotaur $ cd usr
pacito@Maulotaur $ pwd
/home/pacito/usr
pacito@Maulotaur $ unzip /home/pacito/download/pPropellerSim-0.6.zip
pacito@Maulotaur $ cd pPropellerSim
pacito@Maulotaur $ cd dist
pacito@Maulotaur $ pwd
/home/pacito/usr/pPropellerSim/dist

pacito@Maulotaur $ java -jar pPropellerSim.jar

enjoy

You can create a launcher under Xfce, Genome, KDE, etc, just type in the command field "java -jar <path/to/dist/>pPropellerSim.jar", without quotes, most of the times. Don't forget to have jre v1.5 (or jdk1.5), and java in your PATH.

pPropeller.zip
+ pPropellerSim
+ build
+ dist
+ doc
+ nbproject
+ src
+ test

Release notes are included in the file readme.txt in the directory pPropellerSim.

Sources can be erased, if not needed (just leave the /dist directory)

In the doc directory, instructions and a Changelog can be found.


Have fun

Ale

Mike Green

deSilva,
I'm sorry. I was referring to an instruction modifying the next one to be executed. Although it has defined results, it doesn't do what one might expect because the hardware has already fetched the instruction before the changed instruction is written. This would work differently on the debugger than with the real Propeller, but I would not complicate or slow down the debugger to implement this like the hardware. I'd simply document it as discouraged and likely to change with future hardware versions.

The case of an instruction modifying itself would be performed properly by the debugger as I've outlined it since the original instruction is modified properly.

epmoyer

Everyone,

Andy's (Ariba's) "PASD" tool is just fabulous! His tool even manages to parse the .SPIN file so that you can step you ASM code at the source level, and see the labels associated with cog RAM locations. I'm working to help him translate his documentation into English, so hopefully a public release will be forthcoming soon.

Beanie2k

Ariba said...
Hi all

I've done such a debugger some month ago. [noparse][[/noparse]...knip...]
The german version you can find here: www.insonix.ch/propeller/prop_pasd.html.
(the automatic translation by google is not totaly incomprehensible)

[noparse][[/noparse]...knip...]

Andy

I go to the site and see:

Download: noch nicht m

epmoyer

Beanie2k,

Andy has not posted the download publicly yet. He wanted to get a good English translation of the documentation done before releasing. He sent me a pre-release so I could help translate the documentation and do some bug testing. The current release is very usable, and I wrote/translated about 1/3rd of the manual tonight, so a public release is probably not too far away.

Beanie2k

OK. Guess I got confused.