[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6502, 65816 = RISC ?



nathan@visi.com (Nathan Mates) wrote:

>   The only pipelining that Lichty & Eyes (p. 40, by the way) report
>the 65xx capable of doing is "performing two different but overlapping
>phases of _a_ task within a single cycle" (emphasis mine) and gives
>the following example for say 'ADC #val'

>1: Fetch instruction byte
>2: Interpret instruction to be "ADC #"
>3: Fetch value
>4: Do the math
>5: Store result back in accum

>   Lichty & Eyes notes that steps 2&3, 4&5 are combined into one
>cycle each. This is a speedup of 2 cycles from a non "pipelined"
>design. (Once again, this is still _1_ instruction at a time, not
>multiple stages of various instructions at once, as pipelining has
>come to mean on modern processors)

	It's said that there are three types of people: those who can
do math, and those who can't.  And the above is a perfect example:

	1: Fetch instruction byte
	2&3: Interpret instruction to be ADC # and fetch value [1]
	4&5: Do the math and store result back in accum

	Hmmm... 3 cycles.  Isn't ADC #n is a 2 cycle instruction?
Answer: no, it's a 3 cycle instruction.  But when the final cycle 
does not require a memory access, the 6502 goes ahead and fetches 
the next instruction at the same time as it complete the final 
cycle of the current instruction: in other words, a single-stage, 
one-cycle pipeline.  True, you can't have any *less* pipelining and 
still have a pipeline, but the 6502 actually does execute different 
stages of two consecutive instructions in parallel.

[1] Note: BTW, the way the 6502 combines the "interpret instruction 
and fetch the value" stages is pretty simple: it has "fetch the 
next byte" built into the instruction interpretation.  That's why 
the 6502 can't get quicker than 2 cycle instructions, even for CLC, 
etc. that don't need the second byte: it fetches the extra byte 
anyway, and ignores it when it finds out its dealing with a single 
byte instruction.

-- 
Virtually,

Bruce R. McFarling, Newcastle, NSW
ecbm@cc.newcastle.edu.au