> I do still have a posting from you, from back in December.  If I recall, 
> it turned out that you were still using the old gcc 2.7 derived compiler 
> on netbsd-1.3.x, which had no support for strongarms (hardly surprising, 
> since that compiler version came out before the SA110 was released).

That might be the posting, if it contains assembler code.

> Fast floating point would be good, but only if it is IEEE compliant.  
> Anything else is going to cause problems for a lot of others.  Don't 
> forget that understanding of the IEEE data format is embedded deeply 
> within many programs and libraries (starting with, but not limited to 
> libc, gcc, gas, gdb ...)

As a programmer of numerical math, I say that programs depending on
the format of floating point numbers, are bad  And yes, there are a
lot of bad programs out there. I needed it for my own numerical work,
where speed is indeed much more important than compliance to some
irrelevant standard. Besides, I had planned on just letting floats
be fast, while doubles was to be IEEE.

> > I have just burnt too much time on this ARM32 project.
> 
> That seems to be the way of open-source type projects.  I hate to think 
> how much of my own time (and money) I've spent on projects of this type.

Sigh. Yes. But sometimes things go well, such as my audio projects.

> I've seen installations where the compiler looks at the machine its 
> running on and then generates code for that type of machine by default.  
> They suck.  It causes no end of support issues when you ship a binary to a 
> customer with a different configuration.

That is a good point. But most code compiled locally are used locally,
and people making software for shipping are usually competent enough
to specify a compatibility switch when compiling. That is why I think
optimizing for speed should be default. It is often possible to make
a compromize where one gets just a few percent loss in speed for a usable
large degree of portability.

Kim0