🚀 go-pugleaf

[]
>In article <51951@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>In article <35647@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>>3) Exception-handling is always one of the most trouble-prone areas of
>>a design, and anything that makes it more complex slows down the design
>>process.
>
>Microcode is the way this problem is commonly dealt with.  Microcode
>turns an intractable hardware control mechanism into a part of the
>design that many a computer hardware or software person can
>understand, design, debug, etc. 

Well, you still need to be able to save the necessary info to unwind state,
which may mean keeping around a lot more info than a RISC, and you may have
to be very careful to do it in the right order, etc. Note that exception
handling on some RISCs (I860) is a complete bitch as well.

>>4) Finally, nothing will make the current CISC micro architectures
>>have more registers available at once [they might get register sets,
>>but the instruction encoding makes it pretty hard to increase the number
>>available to the compiler at once.]
>
>This issue keeps coming up.  You know, I have seen so many compiled
>routines that contain inner loops that only use 5 or 6 registers,
>inner loops that determine the performance of the program, that I
>really wonder how many registers are needed (Oh no not that again!)
>Global register allocation and all, who cares if you save and restore
>a half dozen registers outside of a loop that is going to execute 100
>times.  
>
>Having more registers really does help some of the time, and when
>the industry starts making new CISC architectures I'll bet you will
>see more, now that program size is not so constraining.

Yes and no. Mall's paper about link time register alloc. showed a 15%
increase with 52 regs. showed a 10-29% speedup. The high end was with
the Stanford benchmark, not a real workload. These are still relatively
small numbers compared to what waiting one year will bring. On the other
hand, lots of registers lets you perform optimizations (besides avoiding
register spills) which can't be done otherwise, notably loop unrolling.
(But, to counter the counter-argument, superscalar techniques might severly
lessen the advantages of unrolling, since the overhead which is being
saved might be done in parallel).

>The shoe is moving to the other foot, so to speak; in order to match
>vector machines, RISCs will need to go to super scalar execution
>(assuming they don't add the large register sets or the instructions
>to do vectors).  To do this they need to deal with variable length
>instructions (variability determined by register dependencies and
>stuff in the pipe, not to mention the surrounding instructions),
>register and opcode fields in variable places in the instruction word,
>complexity handling exceptions, and all the other CISC characteristics 
>RISCers love to bash.

You betcha. RISCs probably don't need to be quite as aggressive as CISCs
to take advantage of these techniques, but the complexity is going to be
worse than current day CISCs.


--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum