From the book Code, it says that:
The 8080 instruction requires anywhere from 4 to 18 clock cycles".
Why would there be such a fluctuation between the number of clock cycles to execute an instruction. What would be an example of an instruction that would take so long to execute? i.e., would would the assembly instruction(s) be that would take that many cycles?
With these older processors you can usually just look at the instruction and count the clock cycles yourself. And don't be confused because modern processors in no way shape or form perform instructions in one clock it takes many and the number varies, it is just pipelined such that you have the illusion that it is one clock for long stretches of non-branching code. When you look at the outside of a car production facility, if a car comes out every 5 minutes that doesn't mean it takes 5 minutes to build a car, and some come out with two doors and some with four. It could take an hour to make one car, they just start a new one every five minutes and finish one every five minutes and the production line is such that the rate is kept up. that doesn't mean each station has to do their thing in five minutes, you might have a 10 minute step you just need to parallelize that step so that you average 5 minutes in and out for all the vehicles. Multiplication in modern processors can be done in one clock with an exponential amount of logic, do it in two and it is much less, four, much less than that, so some will do it in multiple clocks and have idle states waiting for the multiplier to finish.
So maybe you have a one byte instruction that says add some gpr to the accumulator. So you may need one clock to fetch the gpr, one to do the add. And maybe the fetch of the one byte instruction was prefetched, so a freebie-ish.
But maybe its an add of a GPR with a memory location (CISC) with the result going to the memory location. So a clock to get the memory location value, a clock to do the add, and a clock to write it back.
I am more familiar with say the 6502 than the 8080 and with the 6502 docs the clock count was quite obvious.
You might have a compare and branch if zero, and the spec may say add one clock if the branch is taken. That extra clock being the fetch of the next instruction at the branch destination, had you not branched the next instruction was already fetched.
With CISC where you can have a number of steps per instruction just think through the elementary steps and think about which ones that can/might be done in the same clock and things that probably are/were not. RISC has steps too for some instructions, the idea is to reduce it so that each instruction is less complicated and easier to implement, faster, and you can arrange the instructions in combinations to perform the same overall tasks. put a constant in a gpr, read from memory, read from the gpr, add the two values read, store the result in a gpr, store the gpr value to memory.
Just break it down into individual steps and that will get you a long way, but at the same time specific implementation can vary. In some you can perform an alu operation and store the result in the same clock in others that store/writeback may take a separate clock. Did you have some specific instructions in mind?