Path: utzoo!attcan!uunet!mcvax!hp4nl!philapd!ssp1!roelof From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom) Newsgroups: comp.arch Subject: Re: Compiling - RISC vs. CISC Message-ID: <151@ssp1.idca.tds.philips.nl> Date: 11 Jul 89 07:33:25 GMT References: <13976@lanl.gov> <25547@shemp.CS.UCLA.EDU> <26247@amdcad.AMD.COM> <25562@shemp.CS.UCLA.EDU> <26257@amdcad.AMD.COM> Organization: Philips Telecommunication and Data Systems, The Netherlands Lines: 51 In article <26257@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes: >In article <25562@shemp.CS.UCLA.EDU> frazier@cs.ucla.edu (Greg Frazier) writes: >| In article <26247@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes: >| >No, RISCs don't *require* very good optimizers; they just make it easier >| >to perform some optimizations. Very simple compilers can be used with >| >fairly good results. ^^^^^^^^^^^ > >I don't agree with this. Our experience with the early (PCC-based) >internal compiler for the Am29000 showed pretty good performance with ^^^^^^^^^^^ >little or no standard optimizations (no load scheduling, >common-subexpression elimination, dead-code elimination, live/dead >analysis for register allocation, etc.) The only things it performed >were those required by the architecture, i.e. delayed branches. Of Anybody care to quantify this? Just what sort of performance improvement can I expect from no-holds-barred optimization over only-what-I-have-to optimization.? > >If by "exposed pipeline" you mean that performance will be >enhanced by instruction scheduling, then I agree. However, I don't This term has been confusing me (too?). Is this the (an?) "accepted" definition of exposed pipeline? >agree that most RISCs will expose the pipeline to software like the i860 >-- most will provide hardware interlocks. > Well...who will and who won't? > -- Tim Olson > Advanced Micro Devices > (tim@amd.com) f i l l e r f o r r n -- Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof