Are the next two instructions dependent?
If they are dependent they will block out of order execution
If they block out of order execution they can't execute for one clock
Hence, the next two instructions can't execute for one clock if
they are dependent!
What is your opinion?

Example:


Align 16 ;
Loop: ;
inc eax ; D0 p01 1 mops here we write EFLAG register
jnz Loop ; D1 p1 1 mops here we read EFLAG register


-> from A.Fog
"All general purpose registers, stack pointer,flags, floating point registers, MMX registers, XMM registers and segment registers can be renamed."

"There is no practical limit to the number of renamings. The RAT can rename three registers per clock cycle, and it can even rename the same register three times in one clock cycle. "

"For example the INC EAX instruction above uses one temporary register for input and another temporary register for output. This does not remove any dependency, of course, but it has some significance for subsequent register reads as I will explain later."

Regards,
Lingo
Posted on 2002-12-14 19:07:41 by lingo12
lingo12,

I may have missed something but I don't see a dependency problem with the instruction order apart from the loop is so small that INC EAX will have to wait for the last INC EAX to finish because of the use of the same register.

Its just the INC and JNZ will fit into the pipelines a number of times so you will get dependency because the loop is very short.

inc eax
jnz label
inc eax ; this instruction will have to wait
jnz label ; etc ....

is the effective instruction sequence.

The disassembly looks like this and the size is small enough to fit into the pipeline.


00401652 loc_00401652:
00401652 40 inc eax
00401653 75FD jnz loc_00401652

From memory Intel recommend against loops this short and it is probably for this type of reason.

Regards,

hutch@movsd.com
Posted on 2002-12-15 01:56:15 by hutch--
Thanks Hutch,
I don't ask about decoding stage and
I will try to explain my question better:

"Are the next two instructions dependent?
If they are dependent they will block out of order execution
If they block out of order execution they can't execute for one clock
Hence, the next two instructions can't execute for one clock if
they are dependent!"

So, if our two mops are in the reorder buffer (ROB).
"A mop stays in the reservation station until the operands it needs are available
The mops that are ready for execution are sent to the
execution units, which are clustered
around five ports:"-> A.Fog

In our case the second mop is not ready because
IT DEPENDS from result of the first mop
or in other words, the first mop will go to execution port 0 and
second mop will wait 1 clock to go to port 1 rather then to
"know" the result from port 0 and to go to port 1 in the same
clock. Am I wrong here?

Hence, our two instructions can't execute for one clock
What is your opinion about the clocks?

Example:



Align 16
Loop:
inc eax ; D0 p01 1 mops here we write EFLAG register
jnz Loop ; D1 p1 1 mops here we read EFLAG register


"For example the INC EAX instruction above uses one temporary register for input and another temporary register for output. This does not remove any dependency, of course, but it has some significance for subsequent register reads as I will explain later."->A.Fog

Regards,
Lingo
Posted on 2002-12-15 20:09:45 by lingo12
lingo12, branches are much more complex than simple cycle counting, but initially the processor assumes the direction the branch will take. So, the condition is not so important until later - the processor keeps working. Only if the condition does not match the prediction will the processor throw away all the work it has done after the branch. Predicted branches are very cheap and you can assume the two instructions are done in the same cycle. The cost for this savings is unpredicted branches are costly!
Posted on 2002-12-15 22:54:30 by bitRAKE
Thanks bitRAKE,

but I don't ask about branch prediction,
branch target buffer (BTB) and
how costly are unpredicted branches

From other hand you wrote:
"..you can assume the two instructions are done in the same cycle"
Can you proof it for our case or not?
Have you more info what happen with our two mops
in the reorder buffer (ROB)?


Regards,
Lingo
Posted on 2002-12-16 00:14:50 by lingo12

Can you proof it for our case or not?
Have you more info what happen with our two mops
in the reorder buffer (ROB)?
Sorry, I can not.
Posted on 2002-12-16 00:53:04 by bitRAKE
bitRAKE,

Thank you again for your candidness,
but my hope was in your technical archive..

Regards,
Lingo
Posted on 2002-12-16 01:17:07 by lingo12
lingo12,

As best as I can tell, the pair of instructions will continue to be dependent for each iteration of the loop because,

1. The combined byte length will fit into the pipeline more than once.

2. The same register is used by the following pair of identical instructions and the following pair must wait until the first change to EAX is retired.

I don't see that there are enough instructions to effect the out of order buffer so there is little chance of getting out of order execution.

I take Rickey's point that the branch prediction will be a problem but only for the first few iterations of the loop, then it should be properly predicted but a loop of this length is a sequential dependency chain that will have to wait for each increment to be retired which will make it slow for its instruction count.

Depending on the processor, the pipeline length varies so you may get some slight changes as the pipeline fills up with repeat instructions.

The way I would test the problem is to loop through a big enough count and time it and then work out how many instructions were executed in that time. This is easy enough to do because you know the clock speed of the processor. Its rough but it will give you some idea of how fast it is and my guess is that it will be reasonably slow because of the repeated delays.

Where I have bothered to work on algos at this range, I have found it difficult to get the micro-op count down low enough because there are enough other variables to make the result a bit unpredictable.

Regards,

hutch@movsd.com

Regards,

hutch@movsd.com
Posted on 2002-12-16 03:53:44 by hutch--