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