🚀 go-pugleaf

>Second of all, I agree with you that data is a much harder problem. It is
>here that I have the most trouble with RISC. It appears to me that to solve
>the data bandwidth problem, one must give more information to the CPU. In
>particular, a well designed architecture should work to minimize the impact
>of data latency.  The basic premise of RISC is to not telll the CPU anything
>until the last moment. This strikes me as a funny way of optimizing throughput.

This strikes me as a funny way of interpreting RISC!!! :-)  There are
several "basic premises" of RISC, and as far as I know, none of them is "to
not tell the CPU anything until the last moment."  Conversely, as far as I
know, one of the basic premises of CISC is not "to tell the CPU everything as
early as possible."  RISC emphasises exposing hardware to the software (and
vice versa, I guess) so that as much work as possible is avoided.  CISC
emphasizes binding operations together.  This has the effect of doing more
work than is necessary, and taking more cycles therefore.

>To execute your 1.0 FLOP, the typical RISC will do about 1.5 memory access
>intructions, 1.5 address adjusting instructions, say 0.5 instructions for
>boundary condition checking and 0.5 jump instructions. This adds up to 5
>instructions to do 1 FLOP,. Many CISC machines can do a FLOP with only 2
>instructions.

Who cares about instructions?  How much of the work of the RISC instructions
can be reused (i.e., addressing calculations).  How much of the CISC work
is wasted?  Try an optimizing compiler....

>"Compilers can do optimizations", I hear the yelling. This is another
>interesting phenomenon - reduce the complexity in the CPU so that the 
>compiler must do all these other optimizations. I have also now seem any
>indications that a compiler can to anywhere close to an optimal job on
>scheduling code or pipelining. Even discounting the NP-completeness of
>just about everything, theoratical indications point the other way,
>especially when the compiler has to juggle so many conflicting constraints.

Well, I wasn't yelling, so much as muttering.  So, since the compiler can't
do an optimal job, it might as well not do anything.  Why bother.  I can
tell you that a compiler can do a whole lot better job than some microcode!
At leas the compiler has a view of the whole program!  (or at least a whole
procedure.)

>It would be interesting to speculate on total system complexity, is it
>higher for CISC or for RISC (with its attendent memory and compiler
>requirements).

Why speculate?  Design a CISC and then a RISC, of equal performance.  Or
look at existing implementations.  And don't confuse on-chip resources with
real complexity (the kind that makes it hard) like the editor of UNIX
<somethingorother> did in his comments on the i860.  He claimed it is the
CISCiest processor yet!

>As soon as flames start to show up, I will probably disown these
>opinions to save my skin, at which point, these opinions will no 
>longer represent anyone at all. Anyone wishing to be represented 
>by these opinions need only say so.

You are entitled to your opinion, of course.  This is not intended to
be a flame.  I'm just putting in my $0.02 too.