Ricardo B (ricardo.b.delete@this.xxxxx.xx) on April 10, 2017 5:55 am wrote:
> RichardC (tich.delete@this.pobox.com) on April 8, 2017 3:44 pm wrote:
> > wumpus (lost.delete@this.in-a.cave.net) on April 8, 2017 9:49 am wrote:
> >
> > > I'm fairly surprised that the CISC half of the story is only written as a disaster to be
> > > "corrected" by RISC. First, I'm fairly sure that CISC was entirely coined by the RISC people.
> > > Had CISC had their way, they would have called it the "microcode revolution".
> >
> > I'm a big fan of early 80's RISC developments. But I don't see CISC in itself as a disaster
> > or a mistake. CISC'y ISAs were a rational response to a different set of constraints in
> > software and hardware technology, viz:
> >
> > 1) Software written either in assembler, or in not-very-high-level languages compiled by
> > not-very-sophisticated compilers (e.g. statement-at-a-time code generation, poor
> > register-allocation algorithms) themselves running on slow machines with small RAM.
> >
> > 2) Having a read-only memory storage technology which was faster and cheaper than the main-
> > memory technology, but of limited capacity - e.g. diode-matrix ROM, mask-programmable
> > semiconductor ROM. This encourages the use of a small fixed microcode-store to interpret
> > densely-encoded instructions in main-memory.
> >
> > 3) Cpu logic implemented as one or more boards of MSI/LSI chips which necessarily run at
> > relative low clock speed (due to slow inter-chip/inter-board wiring), but which allow
> > a fairly number of gate-equivalents.
> >
> > In that environment, you naturally design your ISA to make it easy for assembler programmers;
> > you don't provide large numbers of expensive registers which the compiler can't use effectively;
> > you have microcode or other complex control logic inside the cpu where it can run fast, in order
> > to use a dense instruction encoding occupying little as possible of your scarce expensive
> > main-memory.
> >
> > It all made perfect sense in the mid-1970s.
>
> While I agree with the conclusions, I somewhat disagree with the motivations.
> I think (1) and (2) were both irrelevant for ISA design.
>
> IMHO, CISC made perfect sense because
> (a) CPUs were not pipelined and there was a non-negligible overhead per instruction
> (b) CPUs lacked caches and had narrow bus, so time spent fetching instructions was also non-negligible
>
> Maximizing work per instruction and work/fetch bus cycle was the path to improve performance.
>
> Put simply, in a non-pipelined CPU:
>
> add r1, [r2 + 8]
>
>
> was a lot faster than:
>
> add r3, r2, 8
> load r4, [r3]
> add r1, r1, r4
>
>

Also when you still had to write that code yourself which one would you prefer? I guess it's obvious.
Don't forget that back then those extra register would not have been nearly as cheap.
I mean in this example you need literally twice as many. No one cares when you have 32, but with 4 (or even 8), 2 registers are kind of a big deal.