Macroops don't execute, so setting serialization flags on them doesn't really make sense. It looks like the rdtsc microop is only used in the rdtsc instruction and I can't think of anywhere else it might be used, so you can probably change the flags on the microop fairly safely. The easiest way to do that is to change the flags that are implied with the TscOp operand is used in an "instruction" definition where instruction is in the ISA parser sense. In src/arch/x86/isa/operands.isa, you can see that TscOp is set up with a tuple returned by the controlReg function. The way the tuple is interpreted by the parser is described in some documentation somewhere, but basically each element is a list of flags that are set on the instruction object in various circumstances like if the operand is read, written, etc. You'd want to add flags that are implied when the TscOp (and only the TscOp) is read, in addition to the ones it already has when written.
According to the AMD manuals I have (I think the AMD manuals are a lot easier to read), the RDTSCP instruction is basically the same as the RDTSC instruction, except that it also sets the ECX register to the value from the TSC_AUX MSR. That value could be the processor ID, or it could be anything else software wants. The value is put there by software and it's interpretation is entirely up to software, so there's no need to determine the processor ID from within the microcode. To fully support RDTSCP you'd need to probably define a TSC_AUX msr/control register in gem5 though, and teach the MSR accessing bits what it's ID is, etc. Gabe On Wed, Mar 7, 2018 at 1:52 PM, Jason Lowe-Power <ja...@lowepower.com> wrote: > Hi all (specifically Gabe), > > I was trying to run some tests that use the RDTSCP instruction and I found > that the rdtsc micro op's current implementation isn't quite serializing > enough. From the Intel manual: > > The RDTSCP instruction is not a serializing instruction, but it does wait > until all previous instructions have executed and all previous loads are > globally visible. But it does not wait for previous stores to be globally > visible, and subsequent instructions may begin execution before the read > operation is performed. The following items may guide software seeking to > order executions of RDTSCP: > • If software requires RDTSCP to be executed only after all previous stores > are globally visible, it can execute MFENCE immediately before RDTSCP. > • If software requires RDTSCP to be executed prior to execution of any > subsequent instruction (including any memory accesses), it can execute > LFENCE immediately after RDTSCP. > > This sounds like the microop should be "serializing before" in gem5's > parlance. I believe that the two instructions RDTSC and RDTSCP have the > same semantics, but that is not clearly stated in the instruction manual. I > don't see any reason not to implement them the same in gem5. Correct me if > I'm wrong. > > In testing, I found that making the macro-op serializing doesn't work > because it only serializes the final instruction and the TSC has already > been read. For instance if you have the following code sequence: > > rdtscp > load miss > rdtscp > > The difference in the two counters is ~load miss time on real hardware. In > gem5, the difference is ~4 cycles. > > I've found that this can be fixed by adding the following code to the RDTSC > micro-op implementation generated by the ISA description in > decode-ns.cc.inc. > > flags[IsSerializeBefore] = true ; > > After this change, gem5 reports numbers closer to real hardware. > > I can't figure out the "right" way to get this code generated, though! I > assume I need to somehow change the rdstc micro-op definition in regop.isa. > Any help would be greatly appreciated! > > Other quick question: RDTSCP is supposed to return the CPU number along > with the TSC value. Any hints has to how to get this from the ISA language? > Would the best way be to add a new micro-op for this? > > Thanks, > Jason > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
