Re: [AD] ftofix optimisation

[Erik S. <eri...@eu...>]

>I can't see any existing 
>header or autoconf method that will reliably tell us the floating point 
>encoding format, so we'd have to write a test program to discover this, 
>which I would have no idea how to do (I suppose try reading lots of 
>floating point constants as binary patterns, and check that they really 
>are all in IEEE format, but I'd be very nervous that we might get it wrong 
>and misdetect some other similar format).

Well, it should be possible to assume that the floating point number
consists of base+mantissa+sign bit, and then test bit by bit. If e.g.

I2F(0x80F00000) == -I2F(0x00F00000)

, then the sign bit is the first one. (where I2F does a bitwise conversion
from int to float).

Similar tests could be done with all the other bits (e.g., enabling bit 30
should make the number about 2^128 times bigger). This will show whether
every bit is IEEE compliant in the way we bother about.

>Urgh,

Agreed.

>you are right! I've never looked at the generated code for FPU 
>routines much before, but this is appalling. Surely it would be more 
>sensible to at least just clear the rounding flag once at program startup, 
>rather than pushing the FPU flags, changing it, doing the calculation, and 
>then popping them again, once per routine that uses the FPU?

It would not have been possible to do that, since all OS level routines and
all assembler assume that the FPU is rounding.

>An asm version sounds ok to me, but I'm also happy with your manual 
>conversion method if you prefer that. Whatever you like: you obviously 
>know more about this than I do. Doing it in asm does restrict the 
>portability somewhat,

You could see the int version as usable only on 387 anyways: There are
probably too many ifs in it to be optimal on systems with proper FP
hardware. Only the boundary checking should be done with int code, and that
is a minor part of it anyways.

Using pure assembler seems like the cleanest way to do it: it would not
require any dirty IEEE detections, it would be fairly portable, and it
would not slow it down any system. The code would be fairly compact too
(usually around 8 executed instns)

>(I can certainly make a Watcom version, and probably MSVC 
>as well although I don't understand the MSVC system so well as the others).

[slightly OT] Have you ever discussed switching to NASM for the assembler
files? That is portable to all known i386 platforms AFAIK. It doesn't
handle inline asm though. With NASM, the non-Intel assemblers would not
have to be converted all the time. The main drawback is that it requires
all Allegro users who want assembler to download NASM.

Erik