Based on my extremely elementary understanding of SLICC, if we can guarantee that there are no outstanding messages in Ruby, we should be able to implement SLICC-Atomic-Flavor that interoperates with SLICC-Timing-Flavor. Am I wrong?
And by 'we' I mean 'not me', naturally. This sounds like a pretty big project overall. Perhaps there is an intern somewhere that is lacking a fall project? Regards, Dan On Fri, Sep 10, 2010 at 11:12 AM, Steve Reinhardt <[email protected]> wrote: > On Fri, Sep 10, 2010 at 8:53 AM, Dan Gibson <[email protected]> wrote: > > - Performance optimizations: I can't commit anyone. The semester is > starting > > and the younger students are figuring out their class schedules, and in > one > > instance, studying for the qualifying examination. If the optimizations > are > > important to be done quickly, someone else should look into them. > > Hard to say they're urgent, since apparently we've been living with > them for quite some time, but there does seem to be the opportunity to > get a lot of return on a small time investment. Not sure if we'll get > to them soon here either. > > > - Atomic mode: I like the idea of a SLICC implementation that spits out a > > 'timing protocol' and an 'atomic protocol'. I.e., have slicc spit out its > > current set of files, plus *_Atomic.[cc,hh] versions? However, I don't > have > > the SLICC knowledge to know if we can expect them to inter-operate -- in > > particular it seems that in-flight messages would be very troublesome. > > Perhaps the proper approach is to quiesce ruby, then switch to atomic > mode > > SLICC? > > Yea, this is exactly what we do with m5 classic when switching from > timing to atomic. Basically you're only allowed to have one or the > other type of transaction in the memory system at a time, so there's > no real inter-operation (except that the non-transient states are > identical, so there's no overhead to switching other than draining out > the in-flight transactions if you're switching out of timing mode). > There's a flag in the System object that tells you what mode you're in > in case you don't know. The CPU models are tied to a particular mode > (AtomicSimpleCPU uses atomic mode, all the others use timing mode) but > things like DMA devices will just check that System flag and issue > atomic or timing requests accordingly. > > Steve > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > -- http://www.cs.wisc.edu/~gibson [esc]:wq!
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
