faster double to 32.32 fixed?

[Gernot Frisch]

I have a platform that does not store IEEE doubles, but swaps
upper/lower 4 bytes in comparison to x86. Anyway, I solved the problem
by converting my double to 32.32 fixed point like this:

inline sll dbl2sll(double dbl)
{
return (sll)(dbl * (double)(1LL<<32LL));
}

which, however is quite expensive, since the platform has no floating
point processor. Is there any faster way of doing this?

--
-Gernot
int main(int argc, char** argv) {printf
("%silto%c%cf%cgl%ssic%ccom%c", "ma", 58, 'g', 64, "ba", 46, 10);}

[Thad Smith]

Gernot Frisch wrote:

I have a platform that does not store IEEE doubles, but swaps
upper/lower 4 bytes in comparison to x86. Anyway, I solved the problem
by converting my double to 32.32 fixed point like this:

inline sll dbl2sll(double dbl)
{
return (sll)(dbl * (double)(1LL<<32LL));
}

which, however is quite expensive, since the platform has no floating
point processor. Is there any faster way of doing this?

You can write platform specific code by making a union contains the
double and a structure containing unsigned characters and probably other
integer types to allow you access to the binary representation. You
will probably do some masking and shifting based on the exponent.

--
Thad

[Gernot Frisch]

"Thad Smith" <Th*******@acm.orgschrieb im Newsbeitrag
news:45***********************@auth.newsreader.oct anews.com...

Gernot Frisch wrote:

>I have a platform that does not store IEEE doubles, but swaps
upper/lower 4 bytes in comparison to x86. Anyway, I solved the
problem by converting my double to 32.32 fixed point like this:

inline sll dbl2sll(double dbl)
{
return (sll)(dbl * (double)(1LL<<32LL));
}

which, however is quite expensive, since the platform has no
floating point processor. Is there any faster way of doing this?

You can write platform specific code by making a union contains the
double and a structure containing unsigned characters and probably
other integer types to allow you access to the binary
representation. You will probably do some masking and shifting
based on the exponent.

is there any way to determine the float layout at compile time?

[Eric Sosman]

Gernot Frisch wrote On 02/14/07 08:31,:

"Thad Smith" <Th*******@acm.orgschrieb im Newsbeitrag
news:45***********************@auth.newsreader.oct anews.com...

>>Gernot Frisch wrote:

>>>I have a platform that does not store IEEE doubles, but swaps
upper/lower 4 bytes in comparison to x86. Anyway, I solved the
problem by converting my double to 32.32 fixed point like this:

inline sll dbl2sll(double dbl)
{
return (sll)(dbl * (double)(1LL<<32LL));
}

which, however is quite expensive, since the platform has no
floating point processor. Is there any faster way of doing this?

You can write platform specific code by making a union contains the
double and a structure containing unsigned characters and probably
other integer types to allow you access to the binary
representation. You will probably do some masking and shifting
based on the exponent.

is there any way to determine the float layout at compile time?

To the best of my knowledge, no.

If the macro __STDC_IEC_559__ is defined, the compiler claims
to use IEEE floating-point. But that's not of much help to you
because it still doesn't tell you what the various bits of a
float or double or long double signify when you manipulate them
as an array of unsigned char, for example.

Your best bet is to study the various platforms of interest
and #define a platform-specific macro for each, indicating what
you've learned about the floating-point formats. Then test those
macros inside dbl2sll() and similar functions. You could probably
write a "helper" program that would study what some selected
floating-point values look like when viewed as unsigned char[]
and then output the appropriate set of #define lines; you'd
run this program ahead of time and direct its output to a .h file
to be #include'd in the "real" build.

--
Er*********@sun.com

[Gernot Frisch]

"Eric Sosman" <Er*********@sun.comschrieb im Newsbeitrag
news:1171467206.32458@news1nwk...

You could probably
write a "helper" program that would study what some selected
floating-point values look like when viewed as unsigned char[]
and then output the appropriate set of #define lines; you'd
run this program ahead of time and direct its output to a .h file
to be #include'd in the "real" build.

Great idea. I'll do that.