Re: [AD] ftofix optimisation

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Erik Sandberg <erik.sandberg@xxxxxxxxxx> writes:
> I have optimised a float to fix conversion routine for another project, and
> I thought you might be interested. It's about 5-10 times faster than the
> original ftofix (on a K6).

That sounds good!

> It is done for the float type used in DJGPP (1 bit sign + 8 bits exp + 23 
> bits mantissa), if float is composed in any other way it won't work. So it 
> should be within some kind of #ifdefs.

The IEEE floating point encoding is pretty standard these days, and this 
method will work regardless of endianess, so in practice this code is 
probably very portable. Certainly it's ok for all DOS and Windows versions, 
but what about Unix? We need some way to check for the specific float 
encoding in use, which I can't see any mention of in the standard autoconf 
macros, and would have no idea how to tackle myself. Any ideas, anyone?

> Oops, this one converts from float, not double. The code for double would
> look similar, but not identical. Is there any interest for a double
> version? In ithat case I can convert this one.

The ftofix() function is prototyped as taking a double, so I think that's 
probably a good idea (classic C always promotes float arguments to double 
before passing them on the stack in any case). What sort of performance 
implications would this change have? You could always just copy the double 
parameter to a local float before munging it into a fixed, but that would 
lose some precision, which I think can make a difference: for large values, 
a 16.16 fixed encoding actually has more significant bits than a 23 bit 
floating point mantissa (not totally sure about that one, though: am I right 
here?). But to access the full contents of a double would require using 
either 64 bit integer types (not portable), or pointer arithmetic to read 
two separate 32 bit values (which raises endianess issues). So I'm not sure 
about this one: I do think it would be a problem to switch to any method 
less accurate than the present one, but is it possible to make a double 
version of this work efficiently enough to be a gain?


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."