I saw that other CPUs from that time, like the Z80, were pipelined. Nobody told me if the original 6502 was pipelined.

Only in a very limited sense, in that sometimes the fetch of the next opcode is overlapped with the final part of the previous instruction.

Also, I'm fairly sure the original Z80 wasn't pipelined either, at least not the ones from the 1970s.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

It seems really just an overlapping too ... http://www.z80.info/z80arki.htm

But Jeek, that's what pipelining is, overlapping instructions.

In this case it's not normally called pipelining because (as far as I know) there is no processing involved - just a fetch. When you read about pipelining it's suggested that at least the decoding stage is performed concurrently with the execution of the previous instruction(s).

It's slightly less limited than that. Note that two things happen in the cycle after the opcode fetch. The opcode is decoded and the byte following the opcode is fetched. This saves a cycle except in cases where the entire instruction is only one byte.

Both examples (mine and the one Alarm Siren cited) qualify as pipelining, I'd say, so I'm using the word differently than Tor would. Not saying he's wrong, though.

Anyone interested in Z80 internal operation should have a look at Ken Shirriff's Z80 articles, such as this eyeopener The Z-80 has a 4-bit ALU. Here's how it works.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

A true execution pipeline would cause all kind of problems that the CPU designer would have to deal with. In a case where the result of the previous operation would be needed in a following instruction (operand or address generation) this pipeline stage must be kept waiting or the result must be bypassed into the following stage. Most of the time both methods apply to keep the wait as short as possible. This would also lead to inconsistent cycle times which the 6502 does not have. Another pain would be to detect that self modifying code has already entered the pipe.

As others already said, there is a limited instruction fetch pipeline. A full ifetch pipe for example would fetch the target of a branch and the next sequential instruction at the same time discarding one or the other after the decision wether to branch or not becomes known.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I'll just add that I don't actually have much of a personal opinion in the matter, only passing along my subjective conclusion about how the terms are mainly used. Pipelining obviously includes overlapping, but overlapping doesn't necessarily include pipelining - presumably there wouldn't be a need for two terms if they were 100% equivalent.

The 6502 was pipelined and the Z80 as well. Pipelining used to refer to the fact that instruction were performed piecemeal in a number of stages requiring multiple clock cycles as opposed to performing the entire instruction in one very long clock cycle. I think most people these days think of overlapped pipelines when pipelining is referred to. The 6502 was advanced in that it has a partially overlapped pipeline. It also has a very efficient bus access combined with the pipelining.

_________________
http://www.finitron.ca

It seems the term 'pipelined' is not as binary as one might think. Perhaps I'd say yes, the 6502 is pipelined, but not very much. Not nearly as much as a CPU you'd happily describe as pipelined.

It's interesting to see that the (low) degree of pipelining is about the same for the 6502 and the slightly later and rather more complex Z80. Both machines have relatively complex instruction sets which don't fit well with modern ideas of pipelining. Looks like Zuse's Z3 from 1941 also took care to overlap a little.

One notable point about the 6502: it will always read the location following an instruction, but if the instruction was a single byte it will then read that location a second time. That shows, from the outside, what is clear from the inside: there's no separate fetching mechanism or queue of fetched instructions.