Re: floating-point abuse in 2.1.113

Richard B. Johnson (root@chaos.analogic.com)
Wed, 5 Aug 1998 09:05:34 -0400 (EDT)


On Tue, 4 Aug 1998, Albert D. Cahalan wrote:

> >>> - v.rangelow=(int)(87.9*16);
> >>> - v.rangehigh=(int)(107.8*16);
> >>> + v.rangelow=(879*16)/10;
> >>> + v.rangehigh=(1078*16)/10;
> >>
> >> How can that be a problem? Shouldn't the multiplication and cast
> >> be evaluated at compile time, leaving only an int?
> >
> > The problem is the "." in 88.9, etc. This means "float".
>
> Yes, of course. You have a literal float multiplied by a literal int.
> The compiler should promote the int and multiply. After that, the compiler
> should convert the result to an int, eliminating the cast. Then the compiler
> should store that int value in the object file. Why not?
>
> If this has anything to do with IEEE rounding modes, gross!
> In that case, gcc needs a -flinux-kernel option. Maybe one of the
> existing flags will make gcc optimize away the floating point math.
> How about -ffast-math?
>

This is what most would like to have happen. I don't know the "rules"
about this. I have found that DOS 'C' compilers (m$ abd b$) will not
touch real numbers. They resolve them at run-time. I just logged into
one of my old VAXen and find that VAXC makes integers by truncation
when the compiler sees real number constants, the result of which
are used as integers.

The version of gcc I use, makes an integer, then performs FP operations
upon it!!

#include <stdio.h>

main()
{
float foo;

foo = 1.0 * 1.0 * 1.0;
printf("%f\n", foo);

}

.file "aaa.c"
.version "01.01"
gcc2_compiled.:
.section .rodata
.LC0:
.string "%f\n"
.text
.align 16
.globl main
.type main,@function
main:
pushl %ebp
movl %esp,%ebp
subl $4,%esp
movl $1065353216,-4(%ebp)
flds -4(%ebp) ; Put above into the FP unit stack
subl $8,%esp ; Make room for 8 bytes on the stack
fstpl (%esp) ; Transfer FP TOS contents to above
pushl $.LC0
call printf
addl $12,%esp
.L1:
movl %ebp,%esp
popl %ebp
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 2.7.2"

So....... The best bet is; "Don't use real numbers in the kernel". Looks
like compilers can do whatever they want with them.

Cheers,
Dick Johnson
***** FILE SYSTEM MODIFIED *****
Penguin : Linux version 2.1.113 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html