Re: CISC vs RISC concepts -- from an assembly view

HellsRaison wrote:
Now this question just popped out of my head. I'm viewing this as a C
program to an x86 assembly output.

CISC CPU speed is relied on microprocessor optimizations (like 3DNow!
and MMX, SSE2, SSE3 extensions/optimizations) which are enabled by the
compiler.

And RISC CPUs rely their speed on _compiler_ optimizations (converting
the least amount of operations done with what the user is trying
accomplish.

So if this is true, shouldn't everyone be using RISC processors and
just use really smart compilers to create their executable. Because
that way the RISC can go extremely fast (1:1 ratio of CPU Cycles :
Operations -- or at least close to this), and all of the advanced math
stuff (that Intel uses -- SSE2, SSE3) would be embedded within the
executable output.

Am I thinking clearly and realistically?

I recommend Hennessy & Patterson, "Computer Architecture: A
Quantitative Approach," for a survey of the topic:
http://dogbert.abebooks.com/servlet/SearchResults?sts=t&an=hennessy&tn=architecture

.

Relevant Pages

  • CISC vs RISC concepts -- from an assembly view
    ... program to an x86 assembly output. ... CISC CPU speed is relied on microprocessor optimizations (like 3DNow! ... And RISC CPUs rely their speed on _compiler_ optimizations (converting ...
    (comp.lang.asm.x86)
  • Re: [OT] Re: Whats the name for this?
    ... With a small instruction set the CPU can be designed to run ... Contemporary RISC is no longer a matter of a small instruction set. ... present a CISC instruction set to the programmer decode it to RISC ...
    (comp.programming)
  • Re: CISC vs RISC concepts -- from an assembly view
    ... CISC CPU speed is relied on microprocessor optimizations (like 3DNow! ... And RISC CPUs rely their speed on _compiler_ optimizations (converting ... In fairness, the instruction decoders are complex, ...
    (comp.lang.asm.x86)
  • Re: What kind of cpu is suit for me?
    ... > Now I want to design a RISC cpu for study the cpu architecture, ... > And I wonder whether I should introduce the pipeline and superscalar ...
    (comp.arch.fpga)