Re: MicroBlaze floating point precision issues
- From: JD Newcomb <the.jd.in.space@xxxxxxxxx>
- Date: Sun, 6 Jan 2008 20:36:55 -0800 (PST)
Thank you, John, for the quick response.
On Jan 6, 10:29 pm, John Williams <jwilli...@xxxxxxxxxxxxxx> wrote:
Hi,
JD Newcomb wrote:
I'm having a heck of a time trying to figure out why my MicroBlaze
implementation is presenting *supposedly* single-precision floating
point values as double-precision values truncated to 32 bits.
Here's what I mean:
float test = 22; // for example
printf("test = 0x%08x\r\n",test); // prints "test = 0x40360000"
printf("test = %d\r\n",test); // prints "test = 1077280768"
printf("test = %f\r\n",test); // prints "test = 22.000000" or
some precision
22 in single-point floating point (hex) is 0x41B00000, and in double-
precision is 0x4036000000000000. So, truncate the double-precision
value and you have what's printed to the screen. I'm completely
baffled. Am I missing something? A gcc flag? How is this even possible
for a single-precision instruction set?
If that literally is your test code, GCC might be being a bit too clever
for you and effectively hard coding the literal '22' as the arg to the
printf statements.
Well, the above wasn't the code that got me investigating the problem
in the first place, but the results are the same.
Try using
float test = 22.0f;
as the initial assignment for starters. To force single precision
constants you need the 'f' suffix, otherwise you burn tragic number of
cycles doing wasteful double to float conversions.
I'm not using constants in my code that pertains to this particular
issue. I have a function that returns an int, and I typecast it to a
float and store it in the float variable:
float foo;
foo = (float) bar(&tmp); // tmp is some 32-bit ASCII-like value
that's converted to an integer value... don't worry about it.
bar() in this case would return 22 as an int, and printing the
variable foo results in the same printed statement as my test code
above.
Also, perhaps specify optimisation level -O0 to gcc, see if that gets
you anywhere.
Regards,
John
No optimizations also get me the same result. Any other ideas?
Compiler flags I'm not seeing? The other question is: is this even
wrong? I mean, I say it is because calculating the values out by hand
using the IEEE 754 standard shows that the results are wrong. But
using a value like 450.123f in the test code above printed as the 32-
bit truncated double-precision value as 0x40776000 (single-precision
is actually 0x43BB0000). Assuming that the truncation would reduce its
precision, the floating value printed out as 450.122986. [shrug] Maybe
it is right.
.
- References:
- MicroBlaze floating point precision issues
- From: JD Newcomb
- Re: MicroBlaze floating point precision issues
- From: John Williams
- MicroBlaze floating point precision issues
- Prev by Date: Viterbi Decoder
- Next by Date: Re: MicroBlaze floating point precision issues
- Previous by thread: Re: MicroBlaze floating point precision issues
- Next by thread: Re: MicroBlaze floating point precision issues
- Index(es):
Relevant Pages
|
