Subject: Re: shocking speed performance!
To: None <richard.earnshaw@arm.com>
From: None <kim@pvv.ntnu.no>
List: port-arm32
Date: 05/20/1999 11:02:23
> > You may do what I did:
> > Compile to assembler source code, and then examine it.
> > If you find stuff like: 
> > a <- b * c
> > a <- a + d
> > 
> > Then you have bad code.
> 
> Yes you have, the compiler would use mla!

Ah, but does it? It did definitely not use that in the example I supplied
some months ago.

> > Fast code should look something like:
> > a <- b * c
> > e <- Array[x]
> > a <- a + d
> 
> Bollocks.  you should get
> 
>   e = Array[x]
>   a = b * c + d
> 
> There's no interleaving in this case.

That is also a good way of doing it. If you want something more than my
current sloppy examples, just reread my very thorough post from a few
months back. It has real assempler code supplied. It was that which made
me finally buy a Intel PC.

> As for fixing it, I've never seen any patches from you, only complaints.  
> If you think your so good, why don't you get down off your high horse and 
> contribute, then we might all benefit from your obvious wisdom.

A couple of years ago, I used 3 months of evenings working on a very
fast floating point "library" for ARM32. I had the code, and it was fast.
The Idea was to implement the often used operators like +-/* as
macroes in GCC, and inline functions in Acorn C++. In Acorn C++ I got
very far, but was stopped some bug in it, probably too many overloadings
of standard functions. A friend of mine had the same problem with his
OpenGL implementation for RiscOS. As for GCC, I never got a working source,
and the advice I got did not work. I have wasted a lot of time on this.

I could also have contributed good sound systems. After all, it was I 
who wrote HiFi-Arch, the program tweaking NICAM quality sound from
original Archimedeses.

I have just burnt too much time on this ARM32 project.

> As for strongarm tuning.  A lot of tweeks have been put into the upcoming 
> egcs-1.2 releases, but you have to remember to tell the compiler what type 
> of cpu you have or it will try to generate a generic tune that isn't too 
> bad for any CPU.

That sounds very good. However, a lot of things have sounded very good,
without ever becoming real. I hope you are right this time.

Why is not environment variables or standard configuration files used
to make gcc/egcs use that as standard directives, like they do in other
systems?

Kim0