Ah, I remember now. It was called ucontext. Some googling says that's deprecated now though, and apparently was pretty slow.
Gabe On Thu, Jul 27, 2017 at 1:00 AM, Gabe Black <[email protected]> wrote: > 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
