[cairo] Speeding up _cairo_fixed_from_double

[Carl Worth]

On Thu, 26 Oct 2006 13:26:55 -0700, "Daniel Amelang" wrote:
> [Seems that this little function deserves its own thread]

And thank you for the very thorough review.

> 1) It assumes that the platform uses a IEEE754 double representation.
> I don't know of any platforms that we care about that doesn't.

I don't _know_ of any either. I was really just talking from a general
stance of not wanting to reduce cairo's portability by replacing
working, portable code with "platform specific" code.

If there are reasonable authorities to say that something is
"universally available" then I'm happy to depend on it.

> should be OK here. The autoconf doesn't even propose a flag/check for
> this (they say it's safe to assume this on modern systems). I,
> personally don't think that we need any type of check for this, but
> Carl disagrees, so I guess a quick configure-time random sample (i.e.
> just check one double value) is probably good enough. So we can
> introduce a new flag (DOUBLES_ARE_IEEE754 or something?) and a compile
> time test and we'll have overcome this issue.

I didn't mean to disagree with something like the autoconf
manual. That sounds like a pretty authoritative statement of universal
availability.

If I'm wrong about something like the need for a portability check, I
hope people will stand up and tell me I'm wrong.

That said, the hack is pretty deep magic, so even if it _does_ work
"everywhere" there is some part of me that would feel better if the
hack actually got tried once and was verified at compile time. But we
can ignore that part of me if it is unreasonable.

> It's important to note that IEEE754 conformance is the _only_ check
> necessary to know if this trick works. I get the impression from
> previous discussions that Carl (and others?) thought that this trick
> depended on more than that, and thus needed a configure-time check.

No. I didn't think there was any other dependency.

> If you're interested, there's a ad-hoc way of detecting IEEE754 from
> other defined symbols (or by using a C99 symbol) found here:
> http://sourceware.org/ml/automake/2003-05/msg00046.html

Thanks. So if we're really talking just "IBM mainframes and Cray",
then I don't care about those.

> 2) It needs to be _word_ endian aware. You'd think that a
> WORDS_BIGENDIAN check would be enough to solve this one, but I'd like
> to raise a warning flag before this is considered solved.
> WORDS_BIGENDIAN (according to the docs) refers to the byte order,
> _not_ the word order. The magic number approach needs to take word
> order into consideration, not byte order. And unfortunately, on some
> platforms (including ARM), the word ordering can be different than the
> byte ordering. I think we need something like the
> __IEEE_BIG_ENDIAN/__IEEE_LITTLE_ENDIAN flags found in newlib's
> ieeefp.h. So we need a new flag/check in cairo to pick this up.

Thanks for raising another issue. The advantage of actual _running_ a
check rather than just coding up some test is that we would hopefully
catch this or any other similar unportability in the trick.

> Am I missing anything else that is blocking this patch?

Nope. Please let's finish it.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061026/025d57ca/attachment.pgp