Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!pyramid!voder!apple!baum
From: baum@apple.UUCP (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: Proposed architecture characterization survey form
Message-ID: <7547@apple.UUCP>
Date: 20 Apr 88 16:36:07 GMT
References: <2048@gumby.mips.COM> <49983@sun.uucp> <1468@pt.cs.cmu.edu>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 69

--------
[]
>In article <1468@pt.cs.cmu.edu> butcher@G.GP.CS.CMU.EDU (Lawrence Butcher) writes:
>When is a RISC not a RISC?  Today I got copies of the 80960KB Programmer's
>and Hardware Designer's reference manuals.
> 32 AND 64 bit instructions.
> Enthusiastic addressing modes.
	Well, I might agree with you there. They are not as bad as, say,
        Clipper, but I'm not sure I'd use that as an argument why something
        was or wasn't RISC.
> Multiple-cycle instructions.
        You mean like HP Spectrum, or IBM RT/PC? Not much of an argument?
> Confused call/return instructions.
        I'm not sure that calling the variations on call/return 'confused'
        is terribly technical. They allow choices of their full 'call', with
        argument passing, etc., when they need it, and an optimised version
        for when you don't. They are covering all their bases
> Decimal data type.
        Their decimal instructions will add or subtract a single decimal
        digit. This doesn't seem to be a horrendous amount of support.
        HP Spectrum has decimal support as well.
> Trig functions in microcode instead of manufacturer-sanctioned subroutines.
        I'm not sure if the microcode gives some advantages over using the
        built-in floating point add/sub/mul/div, but I seem to recall that
        they are both faster and more accurate. Intel has had Prof. Kahan
        (of IEEE standards fame) on their consulting list since weill before
        the IEEE standard. If they believe that high performance, accurate
	trig routines are important for their embedded market, I'd say that
	this was probably a good choice. Besides, they can always trap on the
	opcodes if they don't want to implement them.
> No delayed branching.
	You mean like Ridge or CRISP or Clipper? Based on conversations I've
	had with Ridge and CRISP people, I'm now mostly satisfied that a
	software branch prediction bit can perform about as well as delayed
	branching, depending on the success rate of filling branch holes.
	If you can fill holes better than you can predict, then delayed
	branching is better. Papers I've seen from Berkeley show an 80%
	correct branch prediction rate can be achieved. Its not clear that
	you can maintain 80% of branch holes being filled, especially if
	you also have to fill load holes.
>Zero-cycle branches anyway by making other instructions SO SLOW that the
>branch is finished before the previous instruction is done.
	Like SPARC? This is implementatino, not architecture. You can be sure
	 that the next implementation won't be so (dare I say it?) wimpy.
> Multiplexed address/data bus.
	What does this have to do with RISC? You may as well complain about
	using the address bus twice a cycle, ala MIPS.
> No memory management.  No support for page faults.
	The -MC models have all the memory management you would want. An
	embedded controller is not so dependent on an MMU, so they left it
	out of SOME versions of the chip.
>Maximum instruction time 75878 clocks +- 40%. (probably typo :-)
	Maybe not a typo. It's for the Remainder Real instruction. The trig
	and log functions take 104-441 cycles otherwise, and are interruptible.


>Let me point out an article that might be interesting to readers.  The
>Volume 16 Number 1 March 1988 issue of Computer Architecture News has an
>article by Wm. A. Wulf on "The WM Computer Architecture".  Wulf has a
>background in compiler-design and has a very good idea of what instruction
>sequences occur in real code.  He describes a RISC instruction set with
>32-bit instructions which name 3 source registers and 2 alu operations
>per instruction.  He argues that the compiler can juggle ALU ops so that
>the second operation frequently does useful work.

	This sounds a lot like the original Stanford MIPS. They gave
it up as a bad idea. I'll look for the article, though. 

--
{decwrl,hplabs,ihnp4}!nsc!apple!baum		(408)973-3385