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
