[iPAQ] GCC optimization settings

Hello,

after some initial setup difficulties (I should remember to read
instructions properly *blush*), Linux is now working great on my iPAQ.
Kudos to everyone!

I'm using the Debian/arm distribution on my iPAQ, and I noticed that the
default compiler settings are very conservative, generating code that
will run on all ARM processors. Among other things, this means that no
halfword (16-bit) memory access instructions are used - instead,
halfwords are assembled from bytes manually.

This, of course, means that the performance of any application that
heavily uses "short int" data will suffer badly. Because the framebuffer
of the iPAQ is 16 bits deep, this is likely to affect most programs doing
graphics - including X clients drawing into XImages.

The Linux kernel uses the switches "-march=armv4 -tune=strongarm110", and
I tried rebuilding an application with those settings. I haven't
benchmarked it yet, but it seems to run approximately twice as fast.
(Try using "gcc -S" and comparing the assembly output generated with
different optimization settings - it's quite interesting.)

Because I didn't want to manually add the switches, I set up a small
GCC/G++ wrapper:

        cd /usr/bin
        mv gcc gcc.bin
        mv g++ g++.bin

        cat >gcc
        #!/bin/sh
        exec gcc.bin -march=armv4 -mtune=strongarm1100 "$@"
        Ctrl-D
        cat >g++
        #!/bin/sh
        exec g++.bin -march=armv4 -mtune=strongarm1100 "$@"
        Ctrl-D

        chmod +x gcc g++

You could also add '-fomit-frame-pointer', but IIRC that will
make debugging with GCC more difficult.

What optimization settings was the X server in the distribution
built with? It might not make much of a difference (depending on
how it accesses memory), but it might be worth a try to rebuild
it if it was built with the default settings. For most other
applications, the performance difference is likely to be small enough to
make rebuilding them not worthwhile.

(I just tried rebuilding dvdview - the performance increased from
approximately 8.8 fps to 9.0 fps. Obviously memory access wasn't really
much of a bottleneck in this case...)

        Klaus
Received on Thu Oct 26 02:46:32 2000