Hi Stefan,

>> 1) Define some macros for math-related functions that will ensure the
>> function itself always uses double precision. Add configure checks for
>> these macros.
> 
> Do you know what the rationale behind the standard compiler behaviour is? 
> Because trying to outsmart the compiler is usually not a good idea.

The only time when I try to outsmart the compiler is the "volatile
return variable" trick - and volatile guarantees according to the C
standard the intended behaviour.

The main use of these macros is to correctly set a processor flag to a
certain value (either via other macros defined in system C headers or by
functions provided by the runtime of the OS - and as a fallback inline
assembly [1] if nothing of the above works). I don't actually want to
outsmart the compiler (the volatile trick is only necessary because some
GCC versions optimize at the wrong time) but simply make sure the FPU
environment is in a specifically defined state. Compilers typically
don't care about the FPU environment itself.

Anyway, I've spent quite a lot of time documenting different compiler
behaviours (with and without optimization) and I am extremely sure that
there are no more surprises on x86 platforms. (on other platforms, the
macros expand to /* NOP */ anyway)

If you want to take a look at my documentation, see:

http://www.christian-seiler.de/projekte/fpmath/

I believe I have been thorough enough in my research.

[1] Which is simple enough and glibc on Linux basically does the same
(just with a more generic approach). Also, I tested the inline assembly
with GCC and Sun's CC on OpenSolaris and GCC and Intel's CC on Linux and
those worked as expected.

Also, PHP already uses inline assembly for certain tasks - just look at
the ZEND_SIGNED_MULTIPLY_LONG definition in zend_multiply.h.

Finally, my configure checks test if inline assembly actually works (not
only if it compiles but actually does the expected).

Regards,
Christian



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to