On Fri, Oct 01, 1999 at 06:41:34PM -0700, [EMAIL PROTECTED] wrote: > On Fri, 1 Oct 1999, Mark Brown wrote: > > On Thu, Sep 30, 1999 at 10:21:29PM -0700, [EMAIL PROTECTED] wrote:
> > > I recently updated one of my testing machines to Potato, and the patched
> > > gcc seems to be working fine. Unfortunately, the Potato gcc source package
> > > requires the Potato debhelper, which won't compile without versioned perl,
> > > and the slink egcs package doesn't patch with any pgcc patch files. :/
> > You can probably convince it to build without too much hacking at the
> > dependancies, or you could just upgrade perl (which works now). Or just
> > carry on using your existing package.
> So I could upgrade my Slink system to Potato's perl? Or..? I'm
> semi-clueless on this subject at the moment. Brain fried when my server's
> power supply and boot/root hard drive burned out.
Sorry, I don't understand what you're trying to achive. If you want to
use your slink machine to build for potato, then glibc2.0 is binary
compatible with glibc2.1 so there shouldn't be any problem.
> > > And how could I verify that the patched compiler is actually producing
> > > optimised code? (In my case for AMD K6 with MMX)
> > Benchmarking. Even if the compiler thinks it is generating code
> > optimised for your processor, there's no guarantee that it will
> > actually run any faster.
> Oookie. What I had in mind actually was checking the produced executable
> for MMX instructions. :> I'm not too sure what to look for or how, aside
> from possibly loading it up in gdb and disassembling.
Or just use the -S option to generate assembler output.
From the PGCC FAQ (ignore the wierd markup language - it should be
intelligible).
\begin{quote}
Q:#(mmx)Can PGCC use the MMX features of my CPU?
A: Recent snapshots support MMX so long as you are using binutils-2.9.1
or later. You can include MMX instructions in inline assemlber, or
enable the compiler optimizations by using the _kbd(-mmx) option (use
_kbd(-mmx-only) if your code <EM>never</EM> uses the FPU). These
optimizations are unlikely produce much improvement without special
fine-tuning of the code to take advantage of them.
_par
This probably won't result in any improvement on Pentiums - their MMX
unit is not particularly fast, so the code must be specially structured
to take advantage of the MMX. The implementation of MMX in the Pentium
II is somewhat better, so more improvements may be seen there.
\end{quote}
Actually, that FAQ entry looks like I haven't rewritten it properly
yet...
What I mean when I say "unlikely to produce much improvement witoout
special fine-tuning" is that MMX is highly specialised and PGCC is not
particularly good at finding chances to use it, so you'll probably need
to tweak your code before PGCC will do much MMX-specific stuff with it.
On a related note, I saw on the gcc mailing list today that someone is
just finishing off a bunch of work to add MMX/3Dnow! support to mainline
GCC sources. Possibly this will do better than the existing PGCC code -
I know that the main PGCC author isn't terribly impressed with MMX.
--
Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFS http://www.eusa.ed.ac.uk/societies/filmsoc/
pgpIWRNJ8MPWf.pgp
Description: PGP signature
