Subject: Re: shocking speed performance!
To: None <kim@pvv.ntnu.no>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm32
Date: 05/20/1999 14:27:09
> > How can the system library efficiently implement atod or printf if it 
> > doesn't understand the underlying format? 
> 
> Simple. Converting between text and floats is done by the math library,
> which is changed.

So you've moved the implementation of atof to a different library; this 
doesn't really solve anything.

> 
> > How can a compiler 
> > (particularly a cross compiler) optimise "double x = 1.0 + 33.5" if it 
> > doesn't know the rules for safe constant folding? 
> 
> That is the job of the + operator, which is changed.

No, the compiler also has to know.  A statement such as the one above may 
appear outside the scope of a function.  The compiler has to handle that 
correctly (unless you are going to introduce static constructors to C).  
It also has to handle overflow and exceptions.  What if the user has coded 
his constant as
	double x = 5.0 / 0.0;
because they want an infinity (yes, gcc supports this)?

> 
> > How can an assembler 
> > (again, particularly a cross-assembler) generate the object implementation 
> > for .double 5.0 if it doesn't know the binary representation?
> 
> By being told how.

How?  A library call?  Don't tell me that library is in assembly language, 
cos that won't port for cross compiling.

> 
> > In the end, something has to know what the translation between the binary 
> > and human formats are.  I accept that there are too many user programs 
> > that abuse this ability to know; but many system programs *need* to know 
> > this in order to function correctly.  There's no system call that will 
> > tell a compiler that the size of a double is 8, it just has to know this.
> 
> Which is why I worked on changing the compiler.

OK, so you've rebuilt the compiler, the assembler, the system libraries 
...; now you've broken binary compatibility with all the other binaries 
available for netbsd/arm32.  Was it really worth it?

I don't often recommend this, but I think you'd be better off defining a 
C++ class for your format.  You could then implement the  overloading 
operators for the class in assembler for efficiency whilst maintaining 
compatibility with existing binaries.