* Re: cgen, GNU gdb/sim, and full system simulation
[not found] <CAKEMJMqCY3DrU++LRZQMRCFwxndp0EK+4n-ufHMTz7OUGG7aiQ@mail.gmail.com>
@ 2012-05-16 17:07 ` Frank Ch. Eigler
2012-05-18 12:46 ` Peter Gavin
0 siblings, 1 reply; 3+ messages in thread
From: Frank Ch. Eigler @ 2012-05-16 17:07 UTC (permalink / raw)
To: Peter Gavin; +Cc: cgen, sid
Hi -
On Fri, May 11, 2012 at 01:57:11PM +0200, Peter Gavin wrote:
> [...]
> I'm working on a port of the gdb simulator for OpenRISC. I was
> wondering if anyone had any input on how difficult a full-system
> simulator would be to implement vs. the syscall emulated simulators
> the other ports seem to use.
Indeed. For full-system simulators, some projects have used the sid
framework instead of gdb/sim.
> The primary thing I'm concerned about at the moment is virtual
> memory. [...] But it doesn't look like there's a way to translate
> the PC prior to fetching an instruction. [...]
Actually, instruction fetching code can be hand-written in either
gdb-sim (see e.g. sim/m32r/mloop.in extract-*) or sid frameworks
(sid/component/cgen-cpu/m32r/m32rbf.cxx step_insns), and so that code
can map all it likes.
To me, the more interesting question would be the choice to model
virtual memory as a separate component between the CPU and the memory
and I/O buses (which would suite sid's modeling very well), vs
something purely internal to the CPU model. In either case, the
lookup is only one part: page tables, TLBs, page fault events, all
have to be modeled.
- FChE
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: cgen, GNU gdb/sim, and full system simulation
2012-05-16 17:07 ` cgen, GNU gdb/sim, and full system simulation Frank Ch. Eigler
@ 2012-05-18 12:46 ` Peter Gavin
2012-05-18 12:52 ` Frank Ch. Eigler
0 siblings, 1 reply; 3+ messages in thread
From: Peter Gavin @ 2012-05-18 12:46 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: cgen, sid
Hi Frank, thanks for the response.
> On Fri, May 11, 2012 at 01:57:11PM +0200, Peter Gavin wrote:
> Indeed. For full-system simulators, some projects have used the sid
> framework instead of gdb/sim.
Ok. But we're primarily doing this for GDB, and I suppose gdb can't
use sid, is that right?
> Actually, instruction fetching code can be hand-written in either
> gdb-sim (see e.g. sim/m32r/mloop.in extract-*) or sid frameworks
> (sid/component/cgen-cpu/m32r/m32rbf.cxx step_insns), and so that code
> can map all it likes.
Hmm, I'll look into this.
> To me, the more interesting question would be the choice to model
> virtual memory as a separate component between the CPU and the memory
> and I/O buses (which would suite sid's modeling very well), vs
> something purely internal to the CPU model.
Yeah, I was hoping I could just define a memory in the .cpu file with
define-hardware and have custom get and set methods, but it looks like
that won't work :)
-Pete
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: cgen, GNU gdb/sim, and full system simulation
2012-05-18 12:46 ` Peter Gavin
@ 2012-05-18 12:52 ` Frank Ch. Eigler
0 siblings, 0 replies; 3+ messages in thread
From: Frank Ch. Eigler @ 2012-05-18 12:52 UTC (permalink / raw)
To: Peter Gavin; +Cc: cgen, sid
Hi, Peter -
> Ok. But we're primarily doing this for GDB, and I suppose gdb can't
> use sid, is that right?
gdb can use sid (via the remote protocol). Several gdb/toolchain
ports have used sid as the execution backend for e.g. testsuites.
> [...]
> > To me, the more interesting question would be the choice to model
> > virtual memory as a separate component between the CPU and the memory
> > and I/O buses (which would suite sid's modeling very well), vs
> > something purely internal to the CPU model.
>
> Yeah, I was hoping I could just define a memory in the .cpu file with
> define-hardware and have custom get and set methods, but it looks like
> that won't work :)
Yeah, cgen by itself is not well-suited for modeling such aspects of
the microarchitecture.
- FChE
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-05-18 12:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAKEMJMqCY3DrU++LRZQMRCFwxndp0EK+4n-ufHMTz7OUGG7aiQ@mail.gmail.com>
2012-05-16 17:07 ` cgen, GNU gdb/sim, and full system simulation Frank Ch. Eigler
2012-05-18 12:46 ` Peter Gavin
2012-05-18 12:52 ` Frank Ch. Eigler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).