Subject:
Re: gpsim todo list (wishlist)
From:
Ralf Forsberg ####@####.####
Date:
13 Dec 2001 19:28:07 -0000
Message-Id: <20011213192652.GA12058@home.se>
On Thu, Dec 13, 2001 at 09:59:44AM -0800, Scott Dattalo wrote:
> On Mon, 3 Dec 2001 ####@####.#### wrote:
>
> > * Saving breakpoints,watches,more between startups opening the same file.
>
> I've thought about this. What will most probably be wanted is to save the
> break point information symbolically. The reason is that when you exit and
> re-enter gpsim, then presumably you've made changes to the code in
> between. Things could have moved around.
Your pragma idea sounded better than this.
> > * Improve the program memory disassembly output. Add menus and stuff.
>
> The only problem I have with it is that the text is squashed together.
> e.g. Tabs take only one space. (Actually, I just double checked, this only
> occurs in the profile dump). What exactly are you thinking about here?
Run here, Find PC, Profile start/stop, displaying of profile starts/stops, a
search dialog. I don't use that window too much, but it'd be nice to have.
>
> > * Create a window that displays a dynamically built call tree. It'd tell
> > "from which addresses is this routine called", "how many times has it
> > been called", "which subroutines are called from this routine".
> > Essentially it's about monitoring stack changes and states/changes
> > before and after.
>
> Essentially, you're talking about something like gdb's backtrace on
> steroids. I think a simple backtrace would be useful. The concept of
> "routine" doesn't have much meaning in assembly.
The stack window shows backtrace, no? A routine would be a call/ret pair.
I was thinking about saving the call paths to memory and enable you to
search the data in some way.
>
> > * A way to add symbols to a simulation session, makes it easier to
> > debug and follow plain .hex files.
>
> This would be useful, but how would this be done? I could see registers
> perhaps getting symbolic names.
I remember using a debugger for windows that had that feature. You
could add comments and rename/add labels as you went along reverse
engineering the code. At the end you had found the purpose of all
routines, and you could clearly see what was beeing done. Very useful
when looking at unknown or complicated code with no source available.
It was called ice something, could have been softice.
> > * An improved source window, making it easier to select symbols and
> > perhaps display data values using some kind of popup tooltips. C
> > source coloring/styling. Use some other widget.
>
> You'd almost need a C-parser to get this! This sound very ambitious. One
> problem with .asm source is that it's not always obvious which memory
> location is being referenced. I've seen people use 0x05 to refer to port
> A, and then toggle rp0 and refer to 0x05 for tris A. But even in well
> written code, this behavior is still present. For example, the assembler
> will force Port A and Tris A to be the same too (because only 7 bits are
> significant in the opcode). If you parse the assembly source then it may
> be possible to determine the programmer's intent.
Well, I'm not limiting my ideas to what can be done :-). But the first
step would be making the known symbols sensitive to the mouse pointer,
so when you click on a code label, the window jumps there. When you
click on a variable, the ram window jumps to that address. This is
already possible with the "select symbol" menu item, but it's difficult
to use as it is now. You have to select the word with the mouse and then
using the "select symbol" menu item. Simply clicking would be better.
The value in file symbols could be displayed in a tooltip.
But then as you mention, when you have C code in the source browser the
data can be complicated (e.g structs) but that's step two.
> > * Menu item to save the data from plots to text files.
>
> How about a menu item to print a copy?
You can already print, if you right-click in the plot window...
> Whew!
> This is a lot of stuff.
> But let me add some more! From gpsim's TODO:
>
> * Stimuli - Stimuli are really limited at the moment. It would be useful
> to add different kinds of stimuli and also simplify the way they are
> used. This ties into your canvas suggestion somewhat, but doesn't
> necessarily require a canvas. For example, maybe a popup window can be
> selected from a menu item in the BreadBoard window that will allow a
> user to add/modify a stimulus connected to a pin. Or perhaps we can
> add something like an interactive "Netlist Editor".
I've been thinking a lot about this, but it gets complicated on the gui
side. You really don't want to have to manually route the connections.
I'd like to be able to open any .stc file and see how things are connected.
Does anyone know of code for _simple_ autorouting? Or have another idea
about how to do this without drawing a full schematic, that still clearly
show how stuff connects?
> * Trigger Points - Like a breakpoint, but instead of halting execution
> it tells gpsim to start doing something. For example, we could add
> trigger points to invoke the execution profiling.
I made a Notify_Instruction, that's kind of like this. I use it to
notify the gui when executing a profile start/stop instruction.
> * gpasm/gpsim pragma interface. Wouldn't it be nice to create a stimulus
> in your .asm file and have gpsim understand it?
Yes, I like this idea a lot.
> * Architecture command. Right now, one can only query the processor's
> state by examining registers. But suppose you want to know how many
> bits the USART has received or how much more time before the ADC
> conversion is complete? This information is known to gpsim, but
> not accessible to the user.
This is also interesting.
>
>
> Scott
This should be added to the TODO file.
/ Ralf (too many things to do, too little time to do it)
