Subject:
Re: gpsim todo list (wishlist)
From:
Scott Dattalo ####@####.####
Date:
13 Dec 2001 18:00:35 -0000
Message-Id: <Pine.LNX.4.33.0112061052270.20170-100000@ruckus.brouhaha.com>
On Mon, 3 Dec 2001 ####@####.#### wrote:
> Does anyone have a pet peeve?
Since there's been no response, I guess no one does! Maybe it means gpsim
has now been completed. :)
>
> In no order whatsoever:
>
> * 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.
> * Create a window for breakpoints.
This may be useful for RAM type breakpoints.
> * Enable loading (replacing) new files without need to quit in between.
> This implies freeing memory that are allocated.
This will open a nasty can of worms. But it's a can that really needs
opening. gpsim is fairly sloppy when it comes to freeing memory. This is
really not acceptable...
> * 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?
> * 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.
> * 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.
> * Display code coverage in the source windows. The data is there as a
> counter in the instruction class, incremented when the instruction is
> called (if profiling is enabled), it just has to be presented somehow.
I think there are two ways this information can be portrayed. One is as a
histogram: the horizontal axis is the memory location, the vertical
address toggleable between cycles spent at that address, # of times
instruction has executed, or # of times address has been skipped. The
other way to display it would be to color code the cycles or times
executed. Then in either the source browser or asm browser, change the
color of the displayed text or mnemonics based on this color coding.
> * 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.
> * An improved watch window, supporting any width of data.
> * A simplified way for connecting modules with each other, and perhaps
> even display any gtk windows inside this imagined window. It'd use one
> of the gtk based canvases out there (gnomecanvas, gtkcanvas or even
> diacanvas). Diacanvas implements tracks and boxes, and connecting them
> together, this should help a lot.
I'd actually proposed something like this on the gEDA mailing list. I just
searched the archives, but I couldn't find the discussion. Basically I
wanted to use gEDA, or specifically gschem, to connect modules and display
dynamic information. The consensus was that it was too much work.
> * A waveform viewer. It should support both analog and digital data.
Yes! I've looked at this off and on. GtkWave seems slick, but it doesn't
support analog. gWave is not as slick, but does analog. Neither works with
dynamic data. I've also looked at Adrian's gtk extra package. He's got a
few examples with gtkplot. Mark Edgington has sent me a suggestion on how
the waveform viewer can be implemented:
***************************************
It would be good to have
a graphical-waveform-viewer which plotted the state of one or more pins or
memory locations with respect to time (or instruction count). So one
could
click an "add" button to select various pins and/or memory-locations, and
these would show up on the left of the display window. Then, as you step
through the program operation (or run it automatically for x amount of
time) the display is updated, and can be zoomed in on, or scrolled through
with a bottom slide-bar. It might look like:
-----------------------------------------------------
pin1 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
pin2 ______-----_-------______----__---------_____
reg1:0 ---____---________--___--------__--------___
reg2 <FF><12><3A> ...
time | | | | | | | | | | | | | | | | | | | | | | |
------------------------------------------------------
where pin1 and pin2 are bits, and reg1:0 is the LSB of register #1, and
reg2 is the hexadecimal (or decimal, etc.) value of register #2. (on my
diagram it's not to scale).
****************************************
> * A serial port module, enabling you to connect a terminal to the serial
> port and talk to your simulated pic. And/or use some software terminal.
> * She is not a bad cook, she is microwave compatible.
But does she wash dishes?
> * Cummulative profiling. Add subroutine's exe time to routine's exe time.
> * Routine timing measurements. Sometimes it'd be interesting to see
> for example max/min/average number of cycles used for routine x (I'm
> working on this now). It could also be interesting to see the period of
> the calls of routine x. These two measurements can be displayed on a
> histogram using gtkplot.
Yes. I've seen your work in CVS. I'll comment on this later on.
> * Menu item to save the data from plots to text files.
How about a menu item to print a copy?
> * Add "[HLL-label + 0xnnnn]" in stack window.
> * Compile with -Wall and fix warnings.
> * Support for ICD.
> * Exponential Y-axis for axis representing cycles in the profile plot.
------------
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".
* Breakpoint ranges - execution or register breaks over ranges of
addresses
* 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.
* Boolean Breakpoints - Allow trigger points to be logically combined
to create a conditional breakpoint. For example, you may want to break
when register "TEMP" is accessed while the code is not running in the
main loop.
* Module Simplification. gpsim modules are quite powerful. However, there
hasn't been a whole lot of people besides Ralf, Robert Pearce, and
myself who have developed module code. Part of the reason is because
it's difficult to do so.
* gpasm/gpsim pragma interface. Wouldn't it be nice to create a stimulus
in your .asm file and have gpsim understand it? Or how about setting
a break point at "Main" when the .cod file is loaded? Or how about
assembler asserts that could halt execution in the event some register
doesn't match a certain state? One way these could be implemented is
is through a pragma interface. (We already do this somewhat with the
source level browsing.) The pragrmas could be something like:
Main:
;#gpsim break $ ; Set a break at main
...
movlw 0x10
movwf temp
;#gpsim assert temp != 0x10 ; Break if temp is not = to 0x10
* 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.
Scott
