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

[Theodore A. Roth]

On Tue, 1 Jan 2002, address@hidden wrote:

:)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 got a patch from Tor Ringstad yesterday that kinda fixes this up a 
little. It still needs some work to do what you want though.

:)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.

So you're basically saying that the decoder part needs to be re-entrant? 
That makes some sense. I think it's doable.

Threads here might make things easier, although I must admit I have an 
aversion to threading the simulator. I might be more inclined to do it if 
the threaded parts are not pushed down in the actual simulator part of the 
code. For example, keeping all threading in the gdbserver.c part might be 
easier to handle. If it can be done without threads for now, I'd like that 
better. I do agree we need to work on this.

:)
:)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.

I've used the extended protocol already a little bit. It just doesn't 
bother me to have the sim and gdb quit every time I run it. Since I'm 
doing heavy debugging work, it's actually a plus for me. I do see where it 
would be advantageous though.

:)
:)> 
:)> :)
:)> :)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?

Check the ChangeLog. Mostly sneaky little opcode handler bugs. I think 
I've fixed all the known bugs with the version 12 release. Any existing 
bugs in simulavr, I haven't heard about. ;)

:)
:)I have read the gpsim documentation and I don't like the approach there.

I haven't looked at how gpsim does things, so I don't know what his 
approach is.

:)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.

I agree. I think this still needs to be designed. Also, there's still work 
to be done to achieve complete simulation. The rest of the simulation 
though, might be tightly coupled with the interface to stimuli. I've been 
putting this off since it looks like it will be complicated. Alas, it's 
getting to the point where it needs to be thought about. I'm open to 
discussion here.

:)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?

I've looked at some of the sims included with the gdb source. There's some 
really complicated stuff going on there and I couldn't get a good grasp of 
what was going on from the little time I spent looking at it. I've wish to 
try digging through it, that's fine. If you find something interesting, 
point me at it and I'll try to grok 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?

Yeah, I try to make some time to look into it. My plate seems to be 
filling up rather quickly right now though. ;)

:)
:)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.

Can you give me an example of what you missed or wanted?

I do agree with having the code documented.

:)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.

Ken Restivo has shown me some output of doxygen on simulavr already. I
thought it was a bit much to document every function in simulavr. It
didn't seem to add anything that I couldn't do with etags/ctags and the
comments in the code. It just seemed to duplicate it. _But_, for
documenting an external interface API, I think it would be great. I 
haven't completely written doxygen off yet.

Ted