I vaguely recall that at some point the single IsSerializing flag got replaced by the SerializeBefore and SerializeAfter flags to provide a little more fine-grain control... some instructions just need one or the other and some need both.
Now that I've looked at 'hg annotate', your name is on the changeset that added these! In fact, SeralizeBefore and Serialize after were added in addition to (not in place of) IsSerializing, and the isSerializing() method will return true if any of these three flags are set (though there are separate isSerializeBefore() and isSerializeAfter() methods now too). This seems confusing to me: I think IsSerializing should be eliminated, and instructions marked IsSerializing should have one or both of the Before/After flags set. The status quo could be a problem; for example, if O3 checks isSerializeBefore() and isSerializeAfter() but never checks isSerializing(), then an instruction marked IsSerializing will never actually serialize. Steve On Tue, Apr 14, 2009 at 11:17 AM, Korey Sewell <ksew...@umich.edu> wrote: > Thanks for the insight. > > Looks like O3 has moved from squashing after system call to marking a the > "SerializeAfter" flag for system calls. > > MIPS had system calls marked as "IsSerializing" which (from grep'ing > around) happens to be a flag that isn't even used in the code anymore > (delete?!). > > > > On Tue, Apr 14, 2009 at 1:57 PM, Steve Reinhardt <ste...@gmail.com> wrote: > >> The syscall instruction is marked as serializing, and it's up to the CPU >> model to look at that flag and do whatever (if anything) is necessary to >> make sure that any register or memory changes that happen in the syscall are >> seen by the subsequent instructions--typically this means flush the >> pipeline, if there is one. >> >> As far as modeling a latency, the time required for a syscall will vary by >> many orders of magnitude depending on what the syscall does, and other >> effects like icache and dcache pollution of the kernel code that's execute >> are basically impossible to estimate. So the answer is that if you really >> care about syscall overheads, use FS mode. Trying to do anything at all to >> make syscall overhead more accurate in SE mode is really pointless at best, >> and misleading at worst (IMO). >> >> The difference with TLB overheads is that they're needed to more >> accurately model the execution time of the user code as well, so leaving >> them out is a more fundamental issue with respect to the things that SE mode >> is actually designed to get right. >> >> Steve >> >> On Tue, Apr 14, 2009 at 10:38 AM, Korey Sewell <ksew...@umich.edu> wrote: >> >>> I'm pretty sure that was in the code a while back, but I can not locate >>> this currently in O3. Has this been removed? >>> >>> In SE mode, I would think squashing after a system call is necessary >>> because real system calls would need to save/restore context to Memory >>> before returning to user-mode execution since the OS would naturally use the >>> context on the CPU to service the syscall. M5 in SE mode just models that >>> the register return values get set correctly. >>> >>> However, in O3 speculative execution, there is no dependency kept between >>> what registers a system call might update and the next PC counters of the >>> system call. >>> >>> It would probably be unrealistic to keep that type of dependency in the >>> 1st place, so I'm wondering how does SE mode work for other ISAs if we >>> aren't squashing after system calls? Or are we just lucky there? >>> >>> And lastly, since we are incorporating timing for events like TLB >>> translation in SE mode wouldnt it also make sense to have some default >>> latency for system calls as well? >>> >>> -- >>> ---------- >>> Korey L Sewell >>> Graduate Student - PhD Candidate >>> Computer Science & Engineering >>> University of Michigan >>> >>> _______________________________________________ >>> m5-dev mailing list >>> m5-dev@m5sim.org >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > > > -- > ---------- > Korey L Sewell > Graduate Student - PhD Candidate > Computer Science & Engineering > University of Michigan > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
