Still no simulator for debugging assembly language code?

Bill Baird

I am puzzled why there is aparently little motivation in the propellor group to foster the development of an assembly level simulator that shows the states of all the registers in the propeller and allows step and breakpoint debugging.

Most of the development for such an emulator has already been done by Buddha back in July 2006 and made available in a free alpha version in his post called "PIPE is coming..."

PIPE already shows program and memory and register states in hex, decimal, and binary for assembly code in the hub and all 8 COGS. There is a step and a slow run mode but many other features like breakpoint debugging are still unfinished. Recently Kaio has produced an on chip degugger called "POD", but my understanding is that it won't show this kind of view of the state of all the registers in the propeller.

Buddha seems to have dropped off the map since his last message assuring that "PIPE is not dead" in August 06. His website appears to be gone and I have been sitting on an assembly project since then waiting for the development environment I need to complete the work.

I would think that Buddha's work could easily be completed and incorporated into the propeller tool to produce a debugging environment like Gunther Daubach created for the SX - which was essential for my work with that chip.

My impression is that the development of Spin language tools and the use of the video and keyboard systems on the protoboard is the top priority. I have the propstick and no interest in Spin or Video since I need the fastest assembly code I can write for signal processing functions.

My interests may represent only a small segment of your users, but couldn't some kind effort be put into encouraging the development of this register level tool. Maybe it already exists and I don't know about it. Then please tell me where to look for it if you can.

Thanks for you consideration,

Bill Baird

paulmac

Have a look at GEAR: Propeller Debugging Environment

The sourceforge website says:
"Gear is a Parallax Inc. Propeller emulator, with support for step through debugging and component plug-ins. Requires .NET 2.0"

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I stand on the shoulders of giants

TransistorToaster

I think it would be good to put the debugger tools in their own dedicated sticky thread on the top of the forum. The POD and GEAR tools are in the "Good thread" sticky, but I think they should stand out more. For any processor, the first few questions are: What kind of compiler? What debugging/ IDE tools are out there?
Frank

Bill Baird

Thanks guys for the point to Gear. Seems like the debugger efforts will produce a reliable result sometime soon. I can't get Gear to behave very well so far - but it is still early. At the moment I am using the unfinished preAlpha "PIPE" which has a more intuitive GUI for me than Gear, and seems to work on my programs.

A special thread to access all the work being done on debugging tools would be great.

Bill

Spork Frog

I used GEAR and had no problems whatsoever, other than speed.

Graham Stabler

You can keep adding sticky threads but then you end up with no room for current threads. In fact the idea of the thread index was to help get rid of loads of sticky threads which is why it starts with a list of the sticky threads. That idea was sadly not taken up.

Graham

Bill Baird

So far I can't find any docs on Gear. I can't find where all the special registers are displayed - I see IN and DIR so OUT is below IN? and what is "floating" I can't get the window split and float to make sense. Sometimes I get a window with my dissassembled code on Cog 0, sometimes on Cog 1 (where it is not) in a float window. The scroll bars don't work in the float windows for me. I don't know what "Follow PC" (program counter?) means at the cog window top and I can't get back to that after I click Show memory. Everything dissappears from the window if I click show memory in many cases. If I am in run and I click on a float window the run stops. I can't get step to work where I can see the instruction line change except for a brief section of a window that comes uo when I first load my binary with text I don't understand. I don't know what is the Spin Map or the logic probe and I don't know where the HUB instructions might be dissambled?

So Hell Am I clueless or what? Is this the wrong version off the link above or am I the wrong version?

Help !

Spork Frog

I think I can answer a few of your questions.

Floating basically means unset. No cog has set a state for those pins.

PC is program counter, as you thought. As you step through your code, the current highlited line will always be the one currently being executed.

The logic probe shows the current states of all of the I/O lines. (Basically, the OUTA states.)

Most of your other questions I wonder the same thing. Scroll bars don't work for me either.

Bill Baird

Thanks Larry

I am more getting the hang of it. If I skip the float windows and accept that the coginit code appears in COG 0 for some reason, and my COG 0 assembly shows up in COG 1, I can begin to use Gear. I still can't get the switching from show memory to follow pc to work but I can track my code line changes in follow pc mode. The logic probe now makes sense to me thanks to your explanation. It is very cool and will be of great use to me further along in my project.

I just went thru the original thread anouncing Gear and realize the tremendous effort going into plugins and deep features that I don't need myself right now. The GUI has not been the priority so far it seems.

And no documentation? Not for beginners.

Bill Baird

Actually I need to step thru the instructions and also see the changes made in COG memory. As long as I can't see both at the same time, I can't see how to use Gear. So the switch between Show Memory and Follow PC is critical. How do you get this to work?

Kaio

Bill Baird,

if you does not need to debug more then one Cog at the same time, POD should be show you all what you want. If you are stepping through instructions the data view is automatically updated. With the current version you can also show main memory and it would be updated while debugging. Additional POD can now show data as hex view. Try it and you will see how your program is really running.

Thomas

Paul Baker

Graham Stabler said...
You can keep adding sticky threads but then you end up with no room for current threads. In fact the idea of the thread index was to help get rid of loads of sticky threads which is why it starts with a list of the sticky threads. That idea was sadly not taken up.

Graham

It will likely come down to there being a limited amount of true stickies, then a master sticky (or a sticky of stickies) so we cand keep the blue space down to a minimum. I demoted some stickies to non-sticky status only to have some others promoted in my absence. Ultimately we will need to implement an index system such as you have done.

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

Parallax, Inc.

rjo_

Paul, Graham and everybody,

There is such a huge amount of information floating around the forum that I think it leaves everyone's head spinning... almost constantly.

I don't think anything much can be done about it. And I think it is going to get worse.
I like the stickies and I would favor locking them in place...

Graham's good thread index is where I always end up when I forget where I need to look ... So spiffing up the structure of his index makes sense to me. But I don't think he can do it... I think he would have to tell you guys what he wants in terms of utilities that would be available to him.

For example, it would be nice if thread authors were able to put an "update notice"... right into Graham's index...with a date, when they sense that their thread has significant new information in it. That would help everybody... including Graham.


The other possibility would be some kind of a posting monitor... in a different place...it could even be external to the forum showing posts vs dates for all active threads. I would love to be able to look at a graphical representation of thread activity... We are essentially trading information... this is an exchange. Keeping track of the activity makes sense... and making that tracking available would improve everyone's efficiency.

Right now... I am planted in the same place. But... for instance over this weekend I'll be traveling ... Holiday weekend... probably few posts... probably doesn't matter.

In the next month or two I have been asked to travel to look at the medical infra-structure of a place that doesn't have a sewer system ... let alone internet hook-up. I had to think long and hard before saying yes.... mostly because I can just barely keep up with the current flow in the forum...and get some work done too!!! If I get behind, I am afraid I'll never catch up. Probably a neurotic fear... but a real one.

I can't compliment the regulars or Parallax enough for the current wealth of informed help available.

I would actually like a DVD of the entire forum... a CD might not be big enough[noparse]:)[/noparse] Periodically[noparse]:)[/noparse]

You guys are putting out the best technical information, in the best form that I have ever seen... and it is all free.

Give me us something that we can pay for... but please don't start charging for forum access... that is essentially what Apple did and in my mind, it hurt them.

Rich

Bill Baird

Kaio said...
Bill Baird,

if you does not need to debug more then one Cog at the same time, POD should be show you all what you want. If you are stepping through instructions the data view is automatically updated. With the current version you can also show main memory and it would be updated while debugging. Additional POD can now show data as hex view. Try it and you will see how your program is really running.

Thomas

Thanks for your suggestion. This sounds great. One COG at a time is fine for me for starters. I downloaded it, but hadn't actually tried to run POD because I wasn't sure the update display was at the assembly level. From the discussion about POD on your thread I had thought also that the demo board with LCD display was still required. I only have the propstick board. Can I see the display you mention here on the PC monitor I use to run the propellor tool? Is it uploaded from the actual state of the chip? I assume right now also you need to go back and forth between prop tool for code editing and then downloading to the chip for POD to run the new code. Is that right?

And thanks for your great work on POD. The debugging environment is coming together from generous contributions like yours. Good luck with the programming. May you have lots of free time to work!

Bill

Kaio

Bill Baird,

I'm sorry, but POD requires currently a keyboard and a tv to work. You could it be built on a breadboard like it's on the Propeller demo board.

If you want to debug your assembly program you have to make a special version of this using the debug kernel like in AsmDebugDemo.spin containing in the POD's archive. Then you load it together with the POD itself to your Propeller. This will start the debugging environment and you can debug your code which is running in one Cog. While you are debugging you does not need your PC. When you want to make changes in your code you can do this in a familiar manner using the Propeller tool. Afterwards you load it again together with POD itself to your Propeller to start debugging at your changed code.

I'm currently working on a version that will require only a serial connection to a PC, which would be working with your Propstick out of the box.

Bill Baird

That will be great Thomas! I will be eagerly waiting for this next development. Thank you - keep up the great work!

Bergamot

Kaio said...
I'm currently working on a version that will require only a serial connection to a PC, which would be working with your Propstick out of the box.

That would be awesome; I've hacked together working video and keyboard on my PE kit, but it's fragile and takes up so much breadboard space that it's not really practical for day-to-day debugging.