2

The machine code for the JMP instruction comprises of: opcode - 11CCC010 (where CCC is the state of the flag bit used to set the condition) 8 bits and address for the jump - let's say a 16 bit address.

First there is a fetch operation of the opcode so it needs 1 machine cycle. The state of the flag bit is checked. If condition satisfies then the address is read else it is not. Checking whether the condition satisfies should not take any significant clock cycles since it is determined from the state of the flag bits.

i - Now if condition satisfies: no. of machine cycles needed = 1 (for fetch) + 2 (for reading the address which is 16 bits) = 3

ii. if condition doesn't satisfy: there should be no read cycles (after the fetch cycle) and so the number of machine cycles needed must be 1 ie the fetch cycle only.

But the material I am refering to to learn microprocessors says it will need 2 machine cycles but doesn't tell why and hence my confusion. Should it be 1 machine cycle or 2 machine cycles?

In case there is some confusion over machine cycle and clock cycle, please feel free to answer in any.

aste123
  • 1,223
  • 4
  • 20
  • 40
  • @lurker sorry but those sildes don't seem to have any information on the number of clock cycles needed for any instruction (leave apart the JMP instruction). It just shows what an instruction does. I beg your pardon if I left out anything but slidesshows are really difficult to follow without an index or content page which most other documents posses. – aste123 May 23 '14 at 19:08

1 Answers1

1

Although its counterintuitive to those of us used to the 8080 or z80, checking this documentation confirms your belief. JC takes two machine cycles and seven clock cycles if the condition isn't met but it takes three machine cycles and ten clock cycles if it is. Compare and contrast with the z80 where it's always three machine cycles and ten clock cycles, whether taken or not.

However, I think your confusion is because you imagine that not reading the address is somehow free but there's still the PC to increment.

Both branches of the processor family have a baseline two-cycle cost. That'll account for decoding and making the decision and, because they're pipelined, the read of the first byte of the target address will have begun elsewhere.

At that point I'd imagine the 8085 is smart enough that if the branch isn't going to be taken it can decline to read the second byte of the the target address and just increment the PC again. The 8080 and z80 have probably allowed the second byte read to begin, and quite probably can't increment the PC without reading from it in general, so they follow through on that and then discard the entire target address.

So, in short: it doesn't wait for a decision to start reading the target address; once the read of the low byte is in progress it lets that finish. The alternatives would have been an instruction that takes longer if the branch is taken, and the need to be able to do a double increment without read of the PC, which probably doesn't otherwise come up.

All speculation, of course. Does anybody have an actual 8085 and a logic analyser? They could check whether a first access cycle occurs even if the jump isn't taken.

Tommy
  • 99,986
  • 12
  • 185
  • 204
  • Sorry I didn't understand what this means `that not reading the address is somehow free but there's still the PC to increment.` I didn't know 8085 had piplining. That could explain why it is one machine state more than what I expected. – aste123 May 23 '14 at 19:22
  • Suppose it just read the `JC` and decided not to take it. Then to get to the next instruction it needs to do `PC' = PC + 2`. There is no other time, no other place where the PC needs to be incremented twice. It'd be very unlikely that they'd be able to reroute the PC to the ALU so probably they'd just need to ask for two increments in succession. Even if it can avoid any memory reads of the target address, that's unlikely to have no effect. – Tommy May 23 '14 at 19:31
  • sorry, this is confusing. If piplining comes into play and the lower order byte is already being read elsewhere then the PC is already up by 1 and is currently pointing to the higher order byte (second part) of the target address. PC will increment again when the second part of the address is read/fetched; so to skip that we need to increase the PC by +1 instead of +2 (I hope I'm correct). Also by your recent comment, do you mean to say incrementing the PC deliberately (in an unnatural way) is causing a side effect and taking extra clock cycles? (Sorry, my first language isn't English) – aste123 May 23 '14 at 21:17
  • @aste123 yes. I'm speculating that either the second cycle is because the low part of the address is being fetched or, if it isn't being fetched, it's because there's no other way to achieve a double increment. They're alternatives. – Tommy May 23 '14 at 21:57
  • http://stackoverflow.com/questions/23838410/interrupts-instruction-pointer-and-instruction-queue-in-8086 – Patt Mehta May 24 '14 at 04:02
  • Note that the 6502 would also be slower if taking a branch: 2 cycles when not taking it, and 3 cycles if taking it. Also if the branch was over two pages (a branch was 2 bytes, one byte at 0xFF of the previous page, and the next byte at 0x00 of the next page) then you wasted one more cycle. – Alexis Wilke May 24 '14 at 06:26
  • 1
    @AlexisWilke but isn't that because 6502 conditional branches are relative, so there's an arithmetic cost to taking one? – Tommy May 24 '14 at 12:55
  • Indeed. 8 bits signed integer added to IP from after reading the instruction. – Alexis Wilke May 25 '14 at 03:57