Re: pgcc compiler for slink?
On Fri, Oct 01, 1999 at 10:26:57PM -0700, [EMAIL PROTECTED] wrote: Okay, I was wanting to compile the gcc source package from potato under slink. My suggestion is that unless you really *need* the packaged version you shouldn't bother - it's not even the standard version of any Debian package to start with, and you're going to have to hack it further for Slink. Just install in /usr/local. Even if you do need packaging, I'd consider either something that manages /usr/local (like opt_depot or GNU stow) or your own hand-rolled package that has nothing to do with the Debian EGCS packages. Oh yeah, I'm not terribly impressed with MMX either. : Give me a CPU with multiple FP and vector units. ; Can we say specialised hack? -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpZtOXlKhWVn.pgp Description: PGP signature
Re: pgcc compiler for slink?
On Fri, 1 Oct 1999, Mark Brown wrote: On Thu, Sep 30, 1999 at 10:21:29PM -0700, [EMAIL PROTECTED] wrote: [suggestion to build stock egcs/pgcc in /usr/local] Okay, might do that. 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. Maybe installing into /usr/local would be the best way to go for slink.. 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.
Re: pgcc compiler for slink?
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 EMnever/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/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
pgpIWRNJ8MPWf.pgp
Description: PGP signature
pgcc compiler for slink?
Has anyone successfully patched and compiled a pgcc/egcs package for Slink? I was able to patch for Potato using the gcc source package and a slightly older gcc source tarball patched with the pgcc patches. 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. :/ Is there any documentation on compiling for glibc 2.0 on a glibc 2.1 system? And how could I verify that the patched compiler is actually producing optimised code? (In my case for AMD K6 with MMX) -- Ferret no baka
Re: pgcc compiler for slink?
On Thu, Sep 30, 1999 at 10:21:29PM -0700, [EMAIL PROTECTED] wrote: Has anyone successfully patched and compiled a pgcc/egcs package for Slink? I was able to patch for Potato using the gcc source package and a slightly older gcc source tarball patched with the pgcc patches. I've not built packages, but I've built it in /usr/local. If anyone has any packages avalible could they please tell me about them so I can put them in the PGCC FAQ? If you don't have any space to upload them I can provide some. Last time I asked the Debian gcc maintainers, the main reason for its absence appeared to be a lack of people willing and able to do the job rather than anything else. 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. Is there any documentation on compiling for glibc 2.0 on a glibc 2.1 system? It's not supported that I'm aware of. Note that the two versions are (bugs in the user package aside) source compatible, so if all you want to do is build a new version of the package there shouldn't be any problems. It's only a problem if you want to run glibc2.1 binaries on a glibc2.0 system. 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. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpGDBZdMOj1L.pgp Description: PGP signature
