Awesome, this is exactly what I needed! Thanks for the pointers,
-Mark On Fri, Apr 27, 2012 at 4:54 PM, Steve Reinhardt <[email protected]> wrote: > Or to word it a little more precisely, quiesce the CPU in the system call, > which will keep it from scheduling new tick events until some other > condition comes along to call wakeup and start scheduling tick events > again. So the system call instruction will complete, but nothing else will > happen on that thread until the condition is satisfied. > > This is exactly what happens on an x86 halt instruction, which quiesces > the CPU until an interrupt, so if you're looking for examples, you can try > tracking down that path. I think Alpha even has a quiesce instruction IIRC. > > Steve > > On Fri, Apr 27, 2012 at 1:52 PM, Ali Saidi <[email protected]> wrote: > >> ** >> >> Hi Mark, >> >> >> >> You could return in the system call but schedule an event that quiesced >> the CPU in question until a the condition was satisfied. >> >> >> >> Thanks, >> >> Ali >> >> >> >> On 27.04.2012 16:23, Mark Browning wrote: >> >> Howdy all, >> I'm adding custom system calls to provide inter-processor communication >> in a special purpose network processor. However, I'd like emulate >> asynchronous/interrupt based communication, so was hoping to represent this >> with a blocking system call. However, it appears that gem5 is single >> threaded, so there is no way to block in the system call handler without >> blocking the entire simulator. Is there some way to "yield" in the system >> call handler to allow other processors to continue to be simulated? >> Does anyone have a suggestion for how best to achieve this communication? >> I could obviously make the system call non-blocking and handle the >> busy-wait loop in my simulated code, but I'm afraid that will skew my >> results, as potentially most of the simulated instructions will be this >> loop instead of the actual code I am interested in. >> Also, while on the topic of multiprocess SE simulation, how does "time" >> advance between these two processes? I guess since all system calls appear >> to return immediately, both will always be in approximately the same cycle, >> unless there is indeed some "yield" pathway to allow one processor to >> progress while the other is "blocked"? >> Thanks for your time and opinions, >> -Mark Browning >> >> >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
