I worked on a project with gem5 a while ago where I added context switching to create something pretty similar to what I understand SC_THREADs to be using a standard library call (I think) that I forget the name of, so that part isn't that scary and hopefully wouldn't be too heavy weight. The book I'm reading makes it sound like the system C scheduler is single threaded and just switches contexts in and out on the same thread, but the code I poked at in the gem5 tree seemed to be using pthreads, etc., which would suggest multiple simultaneous threads. But gem5 can run multithreaded now too, right? I think I saw some support for that in the code.
If there really is a significant performance penalty using TLM, I wonder if their simulation kernel has similar issues? I'd be more inclined to adapt the system C APIs to be a client of the gem5 event queue, but I'm probably biased since I'm much more familiar with the gem5 one. I'd think either absorbing an external system C implementation into gem5 or vice versa would be pretty hairy from a code management perspective. In any case, I'm glad to hear that there would be some interest if we were to push in that direction. Gabe On Thu, Jul 27, 2017 at 12:14 AM, Andreas Hansson <[email protected]> wrote: > Hi Gabe, > > The similarity between TLM2 and gem5 is not accidental. We did a lot of > work in 2011 and 2012 to make it that way. In fact, we even created a > version of the gem5 ports that use the 4-phase TLM2 non-blocking protocol, > but ended up never pushing it as it has a fairly sizeable negative > performance impact (15% or so if I remember correctly). We also separated > the actual protocol from the physical port, as in TLM2 > (http://reviews.gem5.org/r/1301/), but ended up never pushing it, again > for performance reasons. I still think it would make sense to try and > align the two, but there are undoubtedly challenges. > > When it comes to the simulation kernel, the problem you will run into is > that SystemC supports both blocking and non-blocking modelling semantics. > gem5 should be able to wrap SC_METHODS without problems, but will not be > able to deal with SC_THREAD and SC_CTHREAD without the addition of some > form of threading/fibres/contexts. There has been work done in the bast to > add boost fibres to gem5 (we never posted this), and it is definitely > doable, but the devil is in the details. > > Overall I strongly support aligning gem5 and SystemC further. The best > outcome, in my view, would be if gem5 was transitioned to work on the > SystemC kernel, allowing interoperability and more elaborate event > semantics, and then also transitioned to use the TLM ports. That would be > quite a work package though. > > Andreas > > On 26/07/2017, 01:53, "gem5-dev on behalf of Gabe Black" > <[email protected] on behalf of [email protected]> wrote: > > >Hi folks. As a part of some work I'm doing, I've been considering what it > >would take to run system C models inside gem5 as SimObjects. I'm working > >through some reading material I have about system C, but I haven't > >actually > >tried writing any of it yet. This seems similar to the work that was done > >to allow running gem5 as a system C model, but sort of in reverse and at a > >finer granularity, ie each object as its own thing and not system C as a > >large black box. > > > >One thing I was wondering is what sort of complications might make that > >not > >work out. So far, I can imagine how to adapt the system C model into gem5 > >without too much fuss, but there's still a lot of pages left in the book > >I'm reading and I haven't touched the actual spec yet. What was the > >thinking behind putting gem5 into system C and not doing something like > >what I'm thinking of? > > > >Another thing I'm wondering about is whether it would make sense to try to > >replace gem5's port protocol with the one in system C. Obviously that > >would > >involve touching a lot of code, but I was surprised at how similar the > >system C port setup and the gem5 one are. It might be nice generally to > >use > >a standardized mechanism that people might already be familiar with and > >have an implementation against. That might also obviate the > >bridging/adapter ports that are in the current system C/gem5 integration > >mechanism. Thoughts? > > > >Gabe > >_______________________________________________ > >gem5-dev mailing list > >[email protected] > >http://m5sim.org/mailman/listinfo/gem5-dev > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
