[Simulavr-devel] Re: Some questions and my offer to help you

[reinhard . jessich]

On Mon, 31 Dec 2001, Theodore A. Roth wrote:

First of all HAPPY NEW YEAR!!!

I will send mails directly to you and as copy to the list, until the list
works correctly (please send me a mail if you get the mails from the list).

> On Mon, 31 Dec 2001, address@hidden wrote:
> 
> :)I have tracked down the problem of typing <cntrl-c> in gdb. simulavr
> :)doesn't read the commands sent from gdb while executing gdb_continue.
> :)I don't thing this is a big issue, because typing <cntr-c> in simulavr
> :)will also do a break and this is detected by gdb. But for the long
> :)term I think simulavr should read the commands from gdb, because gdb
> :)send $c#63 periodicaly after a continue command. Maybe gdb expects an
> :)answer to the $Hc0#db command or maybe this is intended behavour. I
> :)have analysed this with gdb set to remote_debug mode. I couldn't find
> :)a command to set the remote_debug flag, so I did it in gdb/top.c.
> 
> Long term, your right. sim should respond to all gdb request immediately. 
> Short term, it doesn't. We'll have to work on it, but it's not a show 
> stopper at this point. I'll add it to the TODO list.
You are right this is no stopper, but I think in the loop in gdb_continue,
the commands sent from gdb must be checked and executed. This is no big issue.
The only complicated thing could be to handle the commands correctly, while we
are in a running phase. I mean we must ignore the continue command $c#63 while
we are already in gdb_continue, else we would get an endless loop and a stack
overflow.
I think the decoding part in gdb_main_loop must be a separated function, which
can be called from gdb_continue and from gdb_main_loop.
Then gdb_parse_packet must know, if gdb_continue is already executed or not.
This needs an enum in AvrCore, where we store the current executed command. I
don't like mixing flags over different structures. AvrCore is the data
structure for simulation, but it could be used to store this state. An other,
more separated possibility, would be to store it in a structure, which is known
only by gdbserver and which is the first parameter of any gdb function. This
is the more object oriented solution.

Maybe other commands need also to read gdb_commands while they are executing in
the future. With the concept metioned above, this would be possible. We still
have only one point where gdb commands are executed. It should be easy to
extend the decoding for the extended protocol.

> try `set debug remote 1`. Here's part of my .avrgdbinit:
> 
> cat <<EOF
> echo (gdb) set debug remote 1\n
> set debug remote 1
> 
> echo (gdb) file demo.elf\n
> file demo.elf
> 
> echo (gdb) target remote localhost:1212\n
> target remote localhost:1212
> 
> echo (gdb) load\n
> load
> 
> echo (gdb) break main\n
> break main
> 
> #echo (gdb) continue\n
> #continue
> 
> #echo (gdb) quit\n
> #quit
> EOF
Thank you, I will try it.

> 
> :)
> :)I plan to use simulavr in the following scenario:
> :)
> :)simulavr is started and is connected to an application, which will
> :)provide signals to the pins of the virtual processor. To do this, we
> :)need a specification how to connect this application to simulavr and
> :)when the application shall provide the next input and when a new
> :)output is generated by the virtual processor. You have mentioned such
> :)an interface in your todo list. You plan to use the same interface as
> :)gpsim uses. How far is this? Is it only an idea or is there done
> :)something? I don't know how gpsim does it, but if you like I can
> :)investegate it.
> 
> This is only an idea right now. I think simulavr still needs some 
> infrastructure work completed before it can become reality.
> 
> I've been rather busy working on gdb and fixing bugs in simulavr, so I've 
> not gotten to work much on extending simulavr's functionality. Once the 
> gdb patch is at a point where everything works, I'll get back to serious 
> sim work.
Which bugs?

I have read the gpsim documentation and I don't like the approach there.
I don't think it is a good idea to extend the simulator to much. The main task
of the simulator is to simulate the CPU. But this as much exact as possible.
It is not task of the simulater to provide complicated stimuli. The simulator
must be able to write its outputs and to read them. There must be a well
defined interface to the simulator, so that other applications can be connected.
There could be one application provided by us to use the stimuli definitions
of gpsim. If someone likes to have a different environment, he write its own
application.
This approach is not much work in simulavr and it is an open design.

I know, that there is a simulator for the power-pc. I don't know its external
interface definiton. Do you know it? Shall I have a look to it?

> 
> :)
> :)Back to the scenario.
> :)On the other end of simulavr, gdb is connected. I plan to see on my
> :)screen only gdb and the application mentioned above. simulavr is
> :)needed only to interpret the program and to set/read the ports. The
> :)output of simulavr is needed only in a bad error situation. It acts
> :)like a server. For this scenario simulaver must read all commands from
> :)gdb. I think it should be possible to restart the program from gdb
> :)without stop/start simulavr (if this is supported by gdb).
> 
> It is possible with the extended remote protocol. It should be an easy 
> hack to get simulavr to stay up.
So you will investigate it?

Some other issue:
I like documented SW. I have seen some comments in the code of simulavr, but I
missed a module header. This describes in a short form, what the module does.
We use doxygen commands in out company. This is not complicated and you get a
well structured document out of the source code. It can produced LaTex, HTML
and PDF documents. From my experience it is not much work, if I write a new
function, to also add the doxygen header for the function. This helps me,  to
still understand my programm after some time.

Regards,
   Reinhard

-- 
 Ing. Reinhard Jessich              mailto: address@hidden
 A-1190 Vienna, Goergengasse 2/2/1  phone: +43/1/3692600
 http://members.telering.at/jessich mobile: +43/664/1735439