Article View: comp.arch
Article #2951Re: 80-20
From: John Mashey
Date: Sat, 11 Nov 1989 22:34
Date: Sat, 11 Nov 1989 22:34
49 lines
2784 bytes
2784 bytes
In article <1925@atanasoff.cs.iastate.edu> hascall@atanasoff.UUCP (John Hascall) writes:
...
>}If DEC would document exactly what's in that 80%, then VAX compiler
>}writers could FINALLY settle the subject of choosing between
>}different instruction sequences.
> How hard can it be to figure out? Write a simple loop:
>
> MOVL #BIGNUM,R0
> 10$:
> <i-u-t> ; repeat instruction under test,
> . ; say, 100 times
> :
> <i-u-t>
> SOBGTR R0,10$
.......
1) Note that one must be careful with such a thing, because many of the
more aggressive machines have all kinds of stalls or other pipeline
effects that will NOT be revealed by such a test. It may be sufficient
to reveal whether or not it's single-cycle-issue inthe normal case,
or it might not.
2) It is hard for compiler writers to EVER figure out the optimal
code sequences, in any evolving family of computers. This is nothing
new. About 20 years ago, I was torturing myself to write Really Good S/360
BAL code, having carefully studied the timings for 360/50, 360/67,
360/75, and then 370/1xxs. In any broad computer line, there is seldom
code that is optimal for everything. Note that optimal code for 286,
386, 486 are all different, as was code for 68000, 68010, and 68020, at
least, and the 2-cycle bus interface of the 68030 changed some of
the tradeoffs.
3) It certainly isthe case, that a plausible strategy in a product line
is to worry about the machines with:
the longest pipelines, and usually longest latencies
the most parallel units
in that you might put in optimizations that make little difference to
the simpler machines, they won't usually hurt them much, if at all, while
they noticably help the more complex ones.
Along this line, I've heard of compiler speedups on S/360 machines
(like code scheduling, to spread loads and usage of the loaded data apart),
which dn't bother the old simpel machines, but help ones with more
aggressive pipelines, because some of the stalls are then eliminated.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Technical Details
Message-ID:
<31229@winchester.mips.COM>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!mips!mashReferences:
<6927@pt.cs.cmu.edu> <1925@atanasoff.cs.iastate.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: 80-20 Message-ID: <31229@winchester.mips.COM> Date: 11 Nov 89 22:34:15 GMT References: <6927@pt.cs.cmu.edu> <1925@atanasoff.cs.iastate.edu> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 49