2 replies to this topic

[RhetoricalRuvim]

On an older processor, such as the Intel 8086, or the Intel 8088, things are not as slow and as featured as newer processors, such as Intel 386, or even Intel Pentium and higher. But when you get to Intel Pentium, and other processors made since then, it gets confusing, not only with the recently-introduced protected mode and its components, but also - even more confusing - with the out-of-order execution, and branch prediction.

So with this code:

mul ecx 

add eax, 4 

, since ADD is faster, would it get done before the MUL instruction completes? But then things won't be right, if that's the case. However, the processor still gets things done right, even with all this out-of-order weird stuff; I know that because I have written programs before, and they worked.

The processor does some sort of checking on dependent operands, before saying that an instruction is ready to be executed, but then it has to access memory to do that. Wouldn't it make sense for it to just do things in order, then?

And what about the instruction pointer (program counter)? Like for this code:

mov eax, [var1] 

div ecx 

mov ebx, [var2] 

mov [var3], eax 

, what if there's an interrupt right when it's done executing the third instruction, but not quite done executing the second? Or, even worse, what if ECX is 0, and it's already done executing the third instruction? Would it undo the third instruction and report, to the operating system exception handler for division by 0, the address of the second instruction?

What do you guys think about all this weird and confusing stuff?

[mebob]

You are somewhat mistaken on both matters:

Out-of-order execution doesn't quite work like that. It basically has a queue of instructions and when an instructions dependencies have been released by previous instructions, the current will run. It doesn't simply execute ALL instructions out-of-order or WHILE the other is executing. Normally it does it out of order if a previous one is waiting on input from memory or the like.

Interrupts don't work like that; they don't interrupt in the middle of an instruction. Plus, I may be mistaken, but I don't think the CPU would run that out-of-order (as I said earlier it is mainly for memory accesses or OUT/IN instructions, etc). Even if it did run it out-of-order, I'm pretty sure the CPU wouldn't handle the interrupt until after the DIV is done. I would think that in the condition of ECX being zero it wouldn't undo the next instruction, it would simply give the address of the DIV. I don't see why it would do anything more than that.

I couldn't give you any more details, because I don't know anymore lol. Today's CPUs are AMAZINGLY complicated, and very impressive, what with out-of-order execution and pipelining. Read about that stuff on Wikipedia, that may help :D

EDIT: Don't forget about register renaming ;)

[dargueta]

You both brought up good points. Out-of-order execution can work in multiple ways and is highly dependent on the way the processor pipelines instructions. Allow me to use an example from one of my textbooks:

Explaining Pipelining
Let's say you're at the laundromat and have four loads you need to do. You
1. Put a load into the washer, wait half an hour
2. Take it out and put it into the drier, wait another half hour,
3. Spend fifteen minutes sorting socks and stuff
4. Repeat 1-3 for each load.

That'll take five hours, and at each step two pieces of equipment (washer, drier, sorting table) aren't being used. Pretty inefficient, huh?

Now, if we stop considering one load of laundry as a single unit and instead divide it into steps - wash, dry, sort - then we can:
1. Put load A into the washer, wait half an hour
2. Put A into the drier, put load B into the washer
3. Put C into the washer, B into the drier, take A out and sort it
4. Repeat.

Now all equipment is being used at once, and you're done in only 2 hours and 45 minutes. The same can be done with processors; if you divide execution up into stages - load instruction, load registers, calculate, write back - instructions can be executed much more quickly.

Granted, there are times where maybe some stage gets backed up (memory accesses) and you have to hold everything back, but for the large part pipelining saves a lot of execution time, at the expense of design complexity.

Dependencies
Sometimes an instruction is dependent on the results of an instruction that came before it. Sometimes workarounds such as register forwarding and things can be used to avoid stalling, but this isn't always the case. This is where reordering comes in.

​(To be continued when I have more time)