On the 8080 and 8085 microprocessors, a LDA instruction took 13 timing(or T) states to execute. This could be solved by using a ring counter that could generate said 13 T states,as well as having variable instruction length in the control unit that is generally guaranteed in microprocessors. So if this method is so efficient and not very taxing on hardware, why did they switch to having multiple machine cycles per instruction? That sounds like it would require massive amounts of hardware to back it up, much more than having a larger ring counter. So why did they make the switch, and is the hardware to back up multiple machine cycles simpler than I thought?
5
-
5I'm not sure I understand your question. What would a ring counter solve? How is "variable instruction length in the control unit [...] generally guaranteed in microprocessors"? The "hardware to back up multiple machine cycles" is usually some sort of sequencer executing simple microcode.– Michael GrafMay 2, 2020 at 18:04
-
@Wilson: en.wikipedia.org/wiki/Ring_counter– Michael GrafMay 2, 2020 at 18:05
-
A ring counter is a section of the control unit that updates every clock cycle and controls the fetch/execute cycle of the CPU using the timing states I described.– Nip DipMay 2, 2020 at 18:33
-
5Even long before the 8080, CPU's were microprogrammed, because it takes less hardware to do it that way. And they didn't use ring counters, just an internal "PC" for the microprogram or cycle in the instruction. The instruction decoder is actually simpler if you put in the cycle number in binary, instead of in unary from a ring counter...– dirktMay 2, 2020 at 18:57
-
3"This could be solved by using a ring counter that could generate said 13 T states" - exactly what would that 'solve'?– Bruce AbbottMay 2, 2020 at 19:11
Add a comment
|
2 Answers
In the 6502, there are principally three reasons for taking more than one clock cycle per instruction. The 6502 (in common with 65xx and 68xx family CPUs) can transfer one byte on the memory bus per cycle, which is generally better than "80 family" CPUs in which the bus protocol is more complex.
The first reason is that more than one byte may need to be transferred on the bus. For LDA absolute, four bytes are needed - three instruction bytes (opcode, address low, address high) and the actual data byte.
The second reason is that there is limited execution hardware and register space inside the 6502, which was designed to a price point of $25 in 1975, several times lower than its nearest competitors. So for a few instructions and addressing modes, an extra cycle or two is taken to wait for some data to get out of the way before putting another value in its place.
The third reason is that in a couple of cases, complex microcode was reused with some parts suppressed, which resulted in seemingly unnecessary cycles taken by comparatively rare instructions. This includes the "instruction" executed in response to a Reset signal, which reuses the microcode for taking interrupts and executing the BRK opcode, as does JSR. RTS and RTI also share microcode, the latter performing an extra operation in a "dead cycle" of RTS.
You will find similar reasons in the design of other early CPUs. Some of these will have an additional reason - that executing an instruction inherently takes several sequential steps with the hardware provided. This is normally true of multiply and divide operations, which use a shift-add type implementation to avoid the need to implement a very large and expensive piece of logic.
-
I know that instructions will take more than 1 clock cycle, but I'm talking about machine cycles.– Nip DipMay 2, 2020 at 19:24
-
@NipDip There is no difference between a clock cycle and a machine cycle. Sometimes a transaction on the data bus takes more than one cycle; I think the 80-family CPUs are oriented around the extra steps needed to access DRAM compared to SRAM. May 2, 2020 at 19:30
-
The delays on the 6502 aren't generally a result of "microcode", but rather the fact that the only way the chip can use a value received from the data bus on the following cycle is by copying it to the top or bottom half of the address bus. When processing "ADC $14FF,x", the 6502 can compute the LSB of the address while it's fetching the MSB, but the only possible value the 6502 would be able to use for the MSB on the next cycle would be the $14 that it had just fetched. There really aren't very many "unnecessary" cycles if one thinks about the things the 6502 has to actually do.– supercatMay 2, 2020 at 23:22
-
-
@Chromatix: I don't think I'd describe that as "waiting for data to get out of the way". The only situation I can think of where that would be a good description would be on processors that can add an idle bus cycle following an access to a slow memory device so as to avoid contention with devices that are slow to release the bus.– supercatMay 2, 2020 at 23:55
Many early microprocessors take multiple cycles per memory operation not because they are microcoded, but because they have limited ALU resources, and because they can't start computing something until they've received the values to be computed. The Z80 has a 16-bit increment/decrement unit and a 4-bit general-purpose ALU. The 6502 has a program-counter increment and an 8-bit ALU. The CDP 1802 has an increment-decrement unit that operates on 16-bit registers (it might operate two bits at a time; I'm not sure) and a 1-bit general-purpose ALU.
The 6502, for example, has one 8-bit ALU, and requires that on every memory operation, each half of the address bus has either be determined based upon information that was available before the start of the previous cycle, or else be directly copied from the value received on the data bus during the last cycle. When the CPU is fetching an opcode, it has no way of knowing whether it might need anything other than the byte immediately following it, so it may as well start fetching the next byte. When the 6502 executes a branch, it won't have the information needed to compute the branch target until the end of the second cycle. Since the branch target won't be available at the start of the third cycle, the CPU won't be able to fetch code from there. If the 6502 had a 16-bit ALU, it could consistently fetch the instruction following a taken branch with only one wasted cycle, but the 8-bit ALU makes it necessary to compute the LSB during the third cycle, and then compute either PC MSB+1 or PC MSB-1 during the cycle after that while it fetches a byte using the old MSB and computed LSB. If it turned out that the branch didn't cross a page, the fetched byte can become the new opcode. Otherwise the fetched byte will be discarded and another byte fetched using the re-computed MSB.
