Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!brutus.cs.uiuc.edu!apple!sun-barr!decwrl!amdcad!nucleus!tim
From: tim@nucleus.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: '040 vs. SPARC (was: Next computer...)
Message-ID: <29099@amdcad.AMD.COM>
Date: 8 Feb 90 23:32:07 GMT
References: <8905@portia.Stanford.EDU> <160@zds-ux.UUCP> <38415@apple.Apple.COM> <2101@crdos1.crd.ge.COM> <19233@dartvax.Dartmouth.EDU> <2105@crdos1.crd.ge.COM>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc., Austin, Texas
Lines: 30
Summary:
Expires:
Sender:
Followup-To:

In article <2105@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
|   As long as adding the instructions and addressing modes don't slow
| down other stuff, directly or by stealing gates, they can be a net win.
| Another compromise is in register scoreboarding. By using a complex
| instruction part of the execution may be overlapped with execution of
| following instructions. This rapidly gets into interactions between the
| compiler quality and features.

But the complex instruction typically binds many operations together,
*reducing* the ability to efficiently overlap subsequent operations.
However, if the complex instruction is split into its constituent
parts, there is much more opportunity for instruction scheduling.

|   Some address complexity, at least in the area of having autoincr on
| things is usually a win, but it may require a smart compiler or
| scoreboarding to make best use of it.

Either this will take an extra cycle to write back the incremented
address register (in which case an explicit add is just as fast), or
an extra register file port just to write the incremented address at
the same time the load data is written.  If more register file ports
are going to be added, I'd rather issue multiple, general-purpose
instructions, which have a much greater chance of being used than a
limited auto-increment mode.



	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)