Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!news.cs.indiana.edu!rsg1.er.usgs.gov!ukma!seismo!dimacs.rutgers.edu!rutgers!mcnc!rti!dg-rtp!matrix!hassey
From: hassey@matrix.rtp.dg.com (John Hassey)
Newsgroups: comp.arch
Subject: Re: RISCizing a CISC processor
Message-ID: <1990Dec11.150919.23640@dg-rtp.dg.com>
Date: 11 Dec 90 15:09:19 GMT
References: <9012070105.AA02416@hcrlgw.crl.hitachi.co.jp> <1200@dg.dg.com> <1311@inews.intel.com>
Sender: hassey@dg-rtp.dg.com
Followup-To: comp.arch
Distribution: na
Organization: Data General Corporation, RTP, NC.
Lines: 46

In article <1311@inews.intel.com> dlau@mipos2.UUCP (Dan Lau) writes:
>In article <1200@dg.dg.com> uunet!dg!lewine writes:
>>In article <9012070105.AA02416@hcrlgw.crl.hitachi.co.jp>, joe@hcrlgw.crl.hitachi.co.JP (Dwight Joe) writes:
>>	***HOWEVER***, the advantage of RISC is moving work from 
>>    runtime to compile time.  The big speedup comes from compiler
>>    work not hardware. At Data General we have modified some of
>>    the compilers for our CISC MV-series to compile simple code
>>    instead of using instructions like WEDIT.  This has produced
>>    major performance enhancements because a compiler can generate
>>    special case code. 
>
>I don't understand the comment above about the MV-series compilers.
>Are you saying that after DG changed the MV-series compilers to generate
>simple code, there was a major performance improvement (over the complex
>code)?  Or are you saying that "because a compiler can generate special
>case code" (i.e., very complex instructions like WEDIT), there was a
>major performance enhancement over the simple code?
>
>I am confused, can you please clarify the above.  Thanks.
>	Dan Lau
>

    While not the original poster, I think I can clarify the above
    statement.

    The DG Eclipse MV series has quite a few very complex instructions to
    handle things like Cobol data types (packed decimal etc...). WEDIT
    is used to do an "edited" store of a decimal number.  It takes a
    source and destination pointer and the addres of an "edit" subprogram.

    Most of these instructions have a fairly high startup cost, and a
    per-byte cost equivalent to a load/store,  when they were implemented
    in micro-code.  However, the commercial instruction set used up alot
    of micro-code space and did nothing to improve the typical Fortran
    benchmarks, and so they were often emulated by taking an instruction
    trap (making them very slow).

    By making the compilers smarter, and detecting special cases, it is
    possible to avoid the use of these expensive instructions (especially
    when emulated) and generate code that is quite a bit faster.

    When implemented in micro-code these instructions weren't all that bad
    and they sure made building the Cobol compiler easier.

    john hassey
    hassey@dg-rtp.dg.com