home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cbmvax!bagate!dsinc!cs.widener.edu!eff!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!decwrl!access.usask.ca!kakwa.ucs.ualberta.ca!ami-cg!cg
- From: cg@ami-cg.UUCP (Chris Gray)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: SASC 6.0 (food for thought)
- Message-ID: <cg.0d3f@ami-cg.UUCP>
- Date: 29 Aug 92 19:18:34 GMT
- References: <BtLDsK.z9@unx.sas.com> <paulk.1a84@terapin.com>
- Distribution: world
- Organization: Not an Organization
- Lines: 29
-
- In article <paulk.1a84@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
-
- [SAS C results Dhrystone deleted]
-
- >Aztec 6.0 is a *long* way off. They aren't even working on any Amiga products
- >these days -- they don't have enough people. And when they do go back to the
- >Amiga stuff, the first thing they need to do is a major upgrade of their sourc
- >level debugger.
- >
- >But they say the 6.0 compiler will have cool optimizations like register
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- >tracking, full '040 support, and an intuitionized control interface.
- ^^^^^^^^
-
- I hope they have some real optimizations in mind as well, like common
- subexpression elimination, register colouring, loop unrolling, dead code
- elimination, strength reduction, etc. I put register tracking into my PD
- Draco compiler several years ago - it buys some speed, but not as much as
- some of the other techniques.
-
- Or perhaps you mean something different by that term than I'm used to? I
- use it to mean that the compiler keeps track of what is in the registers as
- it emits code, and can therefore avoid unnecessary loads of variables,
- constants, pointer dereferences, etc. An aspect of it that I never did is
- merging the information across flow merge points (two execution paths
- come together, like at the end of an 'if').
-
- --
- Chris Gray ualberta!ami-cg!cg or cg%ami-cg@kakwa.UCS.UAlberta.CA
-