🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #1630

Re: RISC is NOT micro-code (was Re: Compiling - RISC vs. CISC

#1630
From: John Mashey
Date: Sat, 22 Jul 1989 01:14
49 lines
3008 bytes
In article <4356@tekcrl.LABS.TEK.COM> stevev@tekchips.LABS.TEK.COM (Steve Vegdahl) writes:
>In article <13995@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> ...
>> (C)   Code ordering
> ...
>> Any one of the above is fairly easy to do in isolation.  Any two of the
>> above are difficult to do because they interfere with each other.  Only
>> CISC archetectures even have to consider (A) since, in a RISC, this
>> step is _very_ simple.  I claim that CISC compilers must do all three
>> of the above in order to be competitive.  Hence, my claim that CISC is
>> harder to compile for than RISC.
>
>On the other hand, (C) is generally much more difficult for a RISC
>architcture, due to architectural features such as delayed branches and
>exposed memory latency.  These features tend not pose difficult problems
>when treated in isolation---as was done in the early RISC compiler work---but
>cause additional compications when combined with other phases.

1) As I recall, our first reorganizer was written and debugged by 1 person
(Larry Weber) in a week.  Admittedly he'd written several before.
It certainly has been improved and rewritten since, but it lasted a good while.

2) It is clear that code reordering varies in usefulness from architecture
to architecture, BUT the boundary is not RISC-vs-CISC, but determined
by presence or absence of various features and the ways compilers use them.
In general, any machine with nontrivial pipelines and/or separate
functional units may well benefit.  Note that CDCs did all this years ago.  
Also, I heard long ago that people were able to get >5% improvement
on S/370-architecture systems by code-reordering.  Maybe somebody has
a reference.  Also, maybe somebody from Amdahl or IBM would care to
offer some inforomation on what the pipelines and functional units
look like on their current products, because I'd suspect there are places
where code rearrangement is usable.
I'd strongly suspect that most machines that could execute:
	load	reg1,a
	load	reg2,b
	add	reg1,20
	sub	reg2,30
are better off doing it that way than the following:
	load	reg1,a
	add	reg1,20
	load	reg2,b
	sub	reg2,30
because most machines will stall on the add/sub more on the second case.
-- 
-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: <23802@winchester.mips.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!vsi1!wyse!mips!mash
References: <BRUCE.89Jul18181114@heather.pooh.com> <13995@lanl.gov> <4356@tekcrl.LABS.TEK.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!vsi1!wyse!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: RISC is NOT micro-code (was Re: Compiling - RISC vs. CISC
Message-ID: <23802@winchester.mips.COM>
Date: 22 Jul 89 01:14:18 GMT
References: <BRUCE.89Jul18181114@heather.pooh.com> <13995@lanl.gov> <4356@tekcrl.LABS.TEK.COM>
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 49