What does "issue or start an instruction" mean?
In the context of what's written, it should mean the amount of time between when the CPU can start the process of handling one instruction and when it can do the same for the one that follows. If that explanation sounds vague, the reason is that it's going to vary a lot by architecture.
Say you have some instructions to run on a fictional CPU with numbered registers where fetch and decode (F&D) always takes three units of time and execution takes ten:
ADD R1, R2 ; R1 ← R1 + R2
LOAD R3, 0 ; R3 ← 0
LSR R4, 3 ; R4 ← R4 shifted 3 bits to the right
On a simplistic design that doesn't parallelize anything, the total time to run this snippet of code is 39 units: 3+10 (F&D plus execute) for the
ADD, 3+10 for the
LOAD and 3+10 for the
At some point, CPU designers noticed their chips had hardware that sat idle while instructions executed and figured out that nothing was stopping from from using it to execute later instructions that weren't dependent on the outcome of those that came before. In the example above, none of the instructions have anything in common with the others. All of the registers involved are unique, as are what the instructions do. (For the sake of simplicity, let's say
LSR all use different hardware to execute.) This means they can all go through the execution phase in parallel without producing the wrong results.
Three instructions executing in perfect, not-of-this-world parallel would take a total of 13 units of time, a 66% time savings over the non-parallelized CPU. That's quite an improvement until the real world intrudes and you realize that you can't do all of the F&D phase in parallel because you'd have no idea if the
LOAD instruction is going to use the same registers as the
ADD above it. To prevent that, F&D must be done serially. Once you've determined that it doesn't depend on anything prior, you can send it off for execution and go F&D the next one.
The first instruction takes three units for F&D and then is sent somewhere else in the processor to be executed. Then the second F&D can go ahead for another three time units and then the third for the same. At that point, we've spent nine units of time on F&D. Because the third instruction was the last to be decoded, we have to wait another ten units after that for it to execute. That means the last instruction will finish executing 19 time units after F&D starts on the first one. That's still a not-too-shabby savings of 51% over doing everything serially.
When you're able to execute a lot of instructions in parallel, how long the instructions take to execute becomes a bit less relevant than how long it takes to start (issue) them. Start time has become more critical because every unit of time spent evaluating whether or not an instruction can be executed is time the execution hardware won't be busy. If the designers of our fictitious CPU find a way to cut a time unit out of that phase, the total time for the three instructions in the example drops from 19 to 16, which is nothing to sneeze at. Chop out one more and you're down to 13.
Does "execute an instruction" mean only step 6 in the fetch-decode-execute cycle ?
For the purposes of this discussion, it would be reasonable to say it means using the hardware in the CPU to carry out the instruction's wishes.