home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.dsp
- Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!elroy.jpl.nasa.gov!hanauma.jpl.nasa.gov!hyc
- From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
- Subject: Re: compilers for DSP processors
- Message-ID: <1992Dec24.100126.2811@elroy.jpl.nasa.gov>
- Sender: news@elroy.jpl.nasa.gov (Usenet)
- Nntp-Posting-Host: hanauma.jpl.nasa.gov
- Organization: SAR Systems Development & Processing, JPL
- References: <75774@apple.apple.COM> <FFV7VB1w164w@gmp.lonestar.org> <PHR.92Dec22191419@napa.telebit.com>
- Date: Thu, 24 Dec 1992 10:01:26 GMT
- Lines: 22
-
- In article <PHR.92Dec22191419@napa.telebit.com> phr@telebit.com (Paul Rubin) writes:
- > This speed increase was due to 1) using a machine instruction the
- > complier was clueless about, and 2) an optimization of the scaling
- > algorithmn that would have been not obvious at the compiler level.
- >
- >You should report the missing machine instruction to the maintainers
- >of your compiler (I'm not sure which of the several available 960
- >GCC ports you were using), or simply extend the compiler yourself
- >to know about the extra instruction. Having the compiler sources
- >is great.
-
- Heh. Judging from my experience on the i860 and m68k GCC ports, those
- "unknown" instructions were intentionally left unused, mainly because
- there's no way to express their usage in the compiler's RTL. Two little
- m68k gems that I throw in every now and then are exg and movep, neither
- of which can easily be described by the RTL, to say nothing of actual
- C code. C is cool, but there are still a lot of assembly operations one
- might want to do that can't be expressed in C (like, say, a rotate?)...
- --
- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
-
- There's a narrow border between genius and insanity, but I'm a dual citizen.
-