Path: utzoo!utgpu!attcan!uunet!nuchat!texbell!bigtex!milano!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.arch
Subject: Re: register save/restore
Message-ID: <6326@june.cs.washington.edu>
Date: 3 Nov 88 18:25:49 GMT
References: <3300037@m.cs.uiuc.edu> <1988Oct30.013510.16861@utzoo.uucp> <10723@cup.portal.com>
Reply-To: pardo@cs.washington.edu (David Keppel)
Organization: U of Washington, Computer Science, Seattle
Lines: 26
Disorganization: U of Washington, Computer Science, Seattle

bcase@cup.portal.com (Brian bcase Case) writes:
>[ Amazing: DEC never gave instruction timings ]
>[ How are you supposed to write a good compiler? ]

In both defend DEC and support of RISC designers, most CISCs have
great variability in timing *for a given instruction*.  Some relevent
considerations:

* Addressing modes
* Current state of the pipeline
* Cache hit/miss for instruction & memory operands
* State of the cache (if it is busy handling coherency it
  will respond slower on a hit)

Note, for example, that based on subtle variations on usage a single
80386 instruction may execute a factor of 3 faster/slower according to
the manual.  That doesn't count pipeline stalls and the '386 doesn't
have any 3-memory-operand instructions.

One reason compiler-writers like RISCs is that you can *use* the
machine description meaningfully.

	;-D on  ( Anybody got a 7-operand instruction? )  Pardo
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo