Re: What do we call non-pipelined designs?

On Sat, 14 Dec 2024 9:27:47 +0000, Marcus wrote:

On 2024-12-09 00:05, MitchAlsup1 wrote:

On Sun, 8 Dec 2024 22:10:15 +0000, Marcus wrote:
>

I usually (and simplistically) divide CPU designs (implementations) into
two main categories:
>
- Pipelined
- Non-pipelined
>
Of course, there is a sliding scale at play, but let's not get into that
debate.
>
My question is: What is the best name for non-pipelined designs?

>
If any portion of the design fetches the next instruction before the
last calculation of the previous instruction, then the design is
pipelined. CDC 6600 had a pipelined front end and serially reusable
calculation units. {{Also note under this definition 6800, 68000, and
8086 were (partially pipelined) architectures.

>
Yes, it's certainly a scale, where most implementations have *some*
pipelining and *some* unit reuse. I'm thinking about what to call the
two ends of that scale.

Is there a problem with calling one end Heavily pipelined, and then
to call the other end non-pipelined. At least the nomenclature will
not make the spectrum less visible.

>

I'm thinking about CPU:s that transition through several states (one
clock cycle after another) when executing a single instruction (e.g.
FETCH + DECODE + EXECUTE), and where instruction and data typically
share the same memory interface.

>
Given that one can take an off the shelf (rather cheap) FPGA and
implement a fully pipeline RISC ISA implementation::
>
Why, in this day and age, would anyone want to even consider doing
something less pipelined than that ?!?!?

>
My question is more about the nomenclature, not about merits of
different design choices.

We could invent some kind of metric such as transistor count divided
by Flip-Flop count. Quotients above 120 are pipelined; quotients
below 60 are unlikely to be pipelined; quotients above 240 are
deeply pipelined.

It's mostly about overall design, where on one end (e.g. the MIPS)
you focus on instruction throughput at the cost of resource duplication,
while on the other end (e.g. 6502) you focus on resource reuse at the
cost of lower performance.
>
/Marcus