Re: About the format of floating point...

["slayer" <slayer at ccl dot itri dot org dot tw>]

Here is our current situation:

If compiler generate .float directive, then assembler can
handle both single- and double-float well in IEEE format.

If compiler generate constants for the use in RTL file, then
the single-float format is wrong and the (S, E, F) is (1, 11, 20).
The correct IEEE format is (1, 8, 23) for (S, E, F). It's really
a strange format. (1, 11, 20) is the high 32 bits for IEEE double,
so our compiler can do well if we handle only double-precision.
We also checked the float format setting such as IEEE_FLOAT_FORMAT
where we need to declare our float format. For an example:

float i = 1.0;
main()
{
    float j = 1.0;
}

[After the compilation] ===>

The global constan float for i is represented as 
    .float 0f1.00000000000000000000e0   (this is correct !)
this constant will pass to assembler to deal with and the 
assembler do well while in processing float or double.

The local constant for j is translated to 0x3FF00000,
but the correct constant value should be 0x3F800000.
After some simply test, we found that our compiler handle
the single-precision float with (1, 11, 20) for its (S, E, F).
The situation I mentioned is the failed of our compiler.

Could it possibly wrong since we miss some definitions
or declarations? 

==================
Kuo-Yu Slayer Chuang
Computer & Communications Research Laboratories
Software Engineer
Industrial Technology Research Institute, Taiwan.
E-mail: slayer@itri.org.tw
==================
----- Original Message ----- 
From: Toshiyasu Morita <tm@netcom.com>
To: slayer <slayer@ccl.itri.org.tw>
Cc: <gcc@gcc.gnu.org>
Sent: Wednesday, March 01, 2000 1:54 PM
Subject: Re: About the format of floating point...



You need to define "failed". 

This could mean any number of things:

1) The compiler failed to generate an arithmetic operation, 
   such as add, subtract, multiply, etc. This is probably not
   precision related.

2) The compiler generated floating-point constants using the ".float"
   directive, but the assembler mangled them because your single
   precision format is nonstandard. This is not a compile problem
   per se. It is an assembler problem.

3) The generated code doesn't print floating point properly.
   This could be a problem with floatconv.c, which needs
   to be modified to handle your nonstandard floats.

It could be any number of other problems, but simply saying
"it failed" without any details does not help track down a bug
somewhere in over 100,000 lines of code.

Toshi