🚀 go-pugleaf

in article <568092@vaxa.uwa.oz>, d_volaric@vaxa.uwa.oz says:

> Saying that RISC chips are optimised for any high level language sounds
> contradictory (sp?) to me. 

It really isn't.

> The idea is to provide very low level instructions that the raw hardware 
> finds easy to execute. 

That's only part of the story.  Certainly, if I only have a limited number
of instructions, lots of orthogonality, and few addressing modes, it makes
the hardware simpler.  This has it's own immediate benefits.  First of all,
it makes the chip easier to design.  Since the instruction set is simple, I
can hard wire it instead of microcoding, so each instruction can go much
faster since there's no micro execution phase.  And since the design is
simple, the chip comes out small.  So now I can do something cool with the
space I have left over.  You have your choice here.  Motorola decided to
put some FPU units, a deep pipeline, and register scoreboarding on their
88k RISC chip.  AMD decided they wanted beaucoup de registers (192 of 'em)
and a branch target cache (though it still doesn't work) on their 29K.  MIPS
put cache control logic, MMU, and a cool pipeline on their system chips.  Sun
decided to keep it simple, which let them build their first SPARC in a gate
array instead of full custom.  This approach is currently being used by TI
to put a decent 32 bit microprocessor in GaAs, long before their process
technology is ready for something on the order of a modern 68020 style CISC
processor.

Another idea behind RISC is that, while we've had 30 years or so of compiler
technology to get it right, compilers just plain can't take advantage of
complex instructions enough to make use of all the powerful instruction
sets on most CISC machines.  Maybe some future compiler can use an assembly
hacker's expert system to do this, but it just ain't here today.  So when
you assume that everyone is going to write in high level languages, you get
to throw out the instructions that only assembly hackers have a use for.  And
you can take it even further.  There are some things that compilers can do
very well that programmers can't, and you can take advantage of that.  Most
of the modern CPU architectures do this.  For example, many of them find
clever ways to hide bus cycles.  So you execute a load instruction, followed
by something else.  That load is still in progress when the following
instruction is executed, as long as that next instruction doesn't use the
register that's being loaded.  Or your branch instruction starts executing,
and the execution unit executes the instruction following it, regardless of
the branch taken or not.  Or you interleave integer and floating point 
operatings, knowing that your CPU's internal parallelism can execute both
at the same time.  The kind of architectures being designed today let a 
simple analysis of instruction interactions wring extra performance out of a
processor.  This kind of analysis is much easier for a machine to work out
than a human.  

> Darko Volaric,
> Dvorak Computer.
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession