IEEE 754 Compliance

["D.Venkatasubramanian, Noida" <dvenkat at noida dot hcltech dot com>]

Hi all,

	According to IEEE 754 Specifications :

	Two basic floating-point formats: single and double.

	The IEEE single format has a significand precision of 24 bits and
occupies 32 bits
	overall. The IEEE double format has a significand precision of 53
bits and
	occupies 64 bits overall.

	Two classes of extended floating-point formats: single extended and
double extended.
	The standard does not prescribe the exact precision and size of
these formats, but
	it does specify the minimum precision and size. For example, an IEEE
double
	extended format must have a significand precision of at least 64
bits and occupy
	at least 79 bits overall.

Shouldn't GCC atleast follow these specifications for all targets.

Test Case no. gcc.c-torture/execute/ieee/20010226-1.c execution

I ran make-check for h8300-elf target cross-compiler built on an x86 host
platform.
I found the test case failing.

On investigation, I found out that the sizeof double or long double on h8300
is 4 bytes. Obviously, the test case fails. On an x86 target, the size was 8
and 12 bytes respectively.

The size of long double on h8300 targets is 4 bytes in contrast to 12 for
x86 targets.

h8300-elf-gcc -mh
Running on a simulator
Size of data types
Int          : 2
Long Int     : 4
Float        : 4
Double       : 4
Long Double  : 4

I do think, that h8 being a 16 bit microprocessor or microcontroller, would
slow down any program considerably if it uses double with 64 bits, requiring
many memory accesses. But somehow, shouldn't GCC move towards, fixed sizes
for data types (except the pointer sizes, of course), such as Java does. And
maybe, release an advisory that GCC may slow down for certain data types on
certain machines. There is always a float to do the same job of a double in
H8. I don't say, the present GCC violates any C Standards, its just that,
wouldn't fixed sizes go a long way in making programs more portable. 

Any thoughts on the same.

Thanx and regards,

Venky

________________________________________________________________