No subject

devices which must decode CISC type instructions such as X86 code.

Also for a true RISC device, the software (off chip generally)
is written to optimise the instruction sequence to replace or
optimise on conventional CISC type instructions then fed to
the RISC unit.

In fact in early RISC designs (such as HP9000 etc) unless the
compiler was written correctly, the final instruction sequence
could well cause race hazards on the die and corrupt execution
results, ie Under certain circumstances certain instruction
sequences of load/store were interleaved with NOPs...

Given the class of P? processors - I would say most computer
professionals at the chip level class the Pentium series
as true CISC type processors 'but' with the proviso that
these complex instructions may well be decoded in one cycle...

In the conventional parlance of RISC/CISC this does *not* make
any of the P? series a RISC under any circumstances.

>Due to the P4 having a more complex instruction pipeline, a similarly 
>clocked P3 will beat the P4 in terms of performance due to the P3 having to 
>do less on each cycle, but the P4 has the advantage of RDRAM and the ability 
>to have a much larger Mhz rating.

This has absolutely nothing to do with RISC/CISC issues, in fact if
it was *really* RISC it would not need (at all) a complex instruction
pipeline - a true RISC processor can happily do with simple pipeline.

>The new EPIC architecture tries to do a few things in tandem and therefore 
>takes a new approach to things.

All this is the issue of MIMD vs MISD type paralleling on silicon
which is somewhat tangential to issue of RISC/CISC delineation.

Fact is, the instructions (for legacy issues) are complex, multiple
byte instructions which do *not* bode well for compiler optimisations,
ie Don't latest P4 devices still execute native X86 instructions which
are the same as those for P1 and P2 devices - if so then they are CISC !

A true RISC (read harvard type to some degree) requires a relatively
small number of simple instructions where the compiler arranges them
to suit the best data flow requirements. Some of this out of order
compilation may well occur at the chip level *but* that does not
change the instructions from being inherently complex to simple
and hence "reduced set". For christs sake the "set" for X86 is
pretty big and complex !

There is an interesting story (somewhere) of an HP s/w engineer
who wrote an emulator which ran on the native machine but optimised
the sequence prior to non-native execution - funny thing is that
although one would expect it to run slower - for some 40% of
applications it ran faster - even though compilation occured
on the binary (ie post compiler level) implementation, rather
staggering I would have thought !

I understand HP are now looking at a class of such optimising
fault tolerant approaches so the CPU never has to execute native
compiled code from any user app - ever !

Rgds

Mike