Release 2 (01/01/96)

DISCLAIMER: I will accept no responsibility whatsoever for any loss or damage that may occur directly or indirectly by the use or misuse of this information.

Mail: tim@legend.co.uk
IRC: TimJ

If any technical information is incorrect, PLEASE let me know.

[size="5"]Contents

1. Introduction
2. The P5 Pipelines
3. The New Profiling Registers
4. Some MSR and TSC Macros

[size="5"]Introduction

This time round I've gone into more detail. There's still no ground breaking information in here, but all the same it's still useful if you want the basics.

New :
- More about the P5 pipelines
- Some TSC and MSR macros for profiling and timing assembly code

[size="5"]The P5 Pipelines

First of all... writing about the pipeline is REAL boring.. I hate it. If you want detailed information about the dual pipelines I suggest you either find another good p5 doc, or muck about with it.

Right, the P5 has two instruction pipelines - U and V. The V pipe can only execute selected RISC instructions which are generally ones that take 1 cycle.

If it is possible, the V-pipe will execute the next available instruction at the same time as the U-pipe. To visualise this:

The V-pipe isn't a full pipeline and can only execute these instructions:

For the above instruction - if using an address (memory) as the destination, it can only be execute if there is NO displacement. eg: mov [mydata + 4],22 will NOT execute in the V-pipe.

The P5 can only execute these in the V-pipe is one of these instructions are in the U-pipe. These are called "pairable" instructions.

The same applies to the MOV,AND,OR etc.. instructions with displacements. If they contain a displacement the V-pipe stalls. You can check all the stalls using the profiling registers, or the TSC (see the later section on these).

In general, pairable instructions are those RISC-type ones.

If the V-pipe can't execute an instruction, it "stalls" and passes it to the U-pipe on the next cycle. So the V-pipe skips an instruction. If the instruction in V pipe depends on the instruction in the U pipe then the V pipe stalls and misses a cycle.. eg:

On the other hand

Now, onto AGI's. Address Generation Interlocks, are evil. On the 486 AGI's occurred if you used a register 1 cycle before using it in an EA (Effective Address). This stalled the addressing pipeline and gave you a 1 cycle penalty while it recalculated the EA.

All you need do on the pentium is make sure there is 1 cycle between the register load and using it in an EA. This includes both pipes.. if the instructions pair, then you may not be leaving 1 cycle between the two.

If the instruction going through a pipe require memory read/writes and is NOT mov,push or pop, then it cause a lockstep. This means the other pipe is locked for all until the last last cycle:

Another thing... uncached code causes a pipeline stall. The code needs to be executed at least twice before it is DEFINITELY in the cache. On the 2nd loop some code may still not be cached. I did some tests and usually it cached after the first loop, but other times it wasn't. I suppose it depends on the state of the code cache at that point. Perhaps it was a freak of the code I was using.. do some tests and see what you come up with.

[size="5"]The New Profiling Registers

The P5 also has some internal profiling and timing registers that can be accessed through RDTSC, RDMSR and WRMSR. These allow you to count cycles and events like cache misses etc..

RDTSC - Read Time Stamp Count. The TSC is incremented every cpu cycle. We can use it to get a cycle count.
RDMSR - Read an MSR register. MSR index in ECX, value put in EDX:EAX.
WRMSR - Write an MSR register. MSR index in ECX, value to store in EDX:EAX.

If you don't have a p5 compiler these are the opcodes:

The values are all 64 bit (EDX:EAX). All the counters are reset on power-on. So the TSC variable can last about 5800 years on a P100 if you left it on all the time.

Your code need to be running at CPL0 to execute RDMSR or WRMSR. So if you are running Window, or in a Win95 DOS BOX, then it will crash.

Also the TSC counts ALL cycles. So the cycle count includes those of any multitasking environment you're in (like Win95).

The MSR registers are pretty cool. Or more to the point, registers 11h,12h and 13h are cool.

You see, register 11h can be used to tell two timers what to count. These timers can be read from 12h and 13h. Using these timers you can count lots of profiling information like data reads, data read misses, pipe stalls and misaligned data references etc. etc.

Armed with these timers and the TSC, you can tell exactly what you're code is doing and where cycles are lost.

To tell the timers what to count you set the bits in 11h like so:

The bits for each timer are set like so:

Generally you can leave most of the bits alone. Set bits 0-5 to the event type, and set either bit 6 or 7. Under most dos-extenders your code runs at CPL0 (bit 6), but it the counting doesn't seem to work, try bit 7 instead.

So, to count an event you'd do something like this:

And that's it. Of course you have to take into account the overhead code for timing whatever event you want.

Event types:

[size="5"]Some MSR and TSC Macros

These are basically self explanatory I think, mail me if any problems. Oh, they we're tested in 32bit protected mode.

[size="3"]Section 1 - TSC Cycle Counter

These Macros require a memory variable, _TSC , a dword. This varaible is used to store the count takes. In StartTSC, it is cached before the start value is stored, so we won't get an unpredictable cache miss.

StartTSC:

• cache the stack memory
• cache _TSC count variable
• save registers
• stall the pipeline with an idiv.
• get TSC register (this is definitely executed in the U-pipe)
• save the TSC count in the cached _TSC memory variable.
• pop registers

EndTSC:

• push registers
• stall pipeline with idiv (maybe not needed, but just to be sure)
• get the TSC register
• subtract overhead cycles
• subtract start value
• save count in _TSC memory variable.

It may look strange the way I've stalled the pipeline with an idiv. But the RDTSC instruction seems to pair with almost any other instruction. Note. two non-pairable instructions in a row would have worked as well (like cdq cdq).

The only problem I can see is with the push at the start of EndTSC. The overhead cycles I calculated assume a cache hit on the push. If you get a cache miss then the TSC count will be too high. This should only occur when you time LOTS of code that completely pushes the cached stack out of the cache. I hope this will be a very rare occasion. If anyone can suggest a fix for this I'd be happy to put it in.

[size="3"]Section 2 - MSR Timing Macros

These macros will program and read the MSR timers. StartProfile will time the overhead for the particular event, and subtract this at the end. For getting cycle counts this is completely useless, use StartTSC and EndTSC for that.

If the timing seems wrong, change the CPL at which these work. Under a normal system CPL0..2 is where you're code runs. But under other systems or windows, there's a good change it will run at CPL3.

To fix this, in the SetMSRTimers macro, make it AND the event with USER_CODE (CPL3 code) instead of SYS_CODE (CPL0..2 code).

The way it times the overhead isn't perfect, I know. I tested this with some of the events, and it hasn't failed yet. Subtracting the overhead gets better counts and allows both timers to get the same count on a particular event.

If anyone finds any particular event where these macros go completely wrong then let me know.

alterations I should make in the near future:

• stall the pipeline as in StartTSC/EndTSC
• cache the memory values at the start

Other than that these macros are pretty good.

They need several dword variables, these are:

Since we sub the overhead at the end, when timing the overhead code we need to do a dummy sub.

Mail me with any problems.